W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

CHUNKED: draft changes

From: Paul Leach <paulle@microsoft.com>
Date: Sun, 31 Mar 1996 16:52:38 -0800
Message-Id: <c=US%a=_%p=msft%l=RED-77-MSG-960401005238Z-1105@red-07-imc.itg.microsoft.com>
To: "'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Following is draft wording changes to section 3.6 of the draft HTTP 1.1
spec to allow future extensions to chunked transfer encoding, such as
digital signatures, etc. Changes are marked with change bars (manually
generated, so 100% guarantees can not be made...)

If there are objections, please let me know; otherwise, we will conclude
that sufficient consensus exists to close out this issue.
>--------
>
>3.6  Transfer Codings
>
>   Transfer coding values are used to indicate an encoding 
>   transformation that has been, can be, or may need to be applied to 
>   an Entity-Body in order to ensure safe transport through the 
>   network. This differs from a content coding in that the transfer 
>   coding is a property of the message, not of the original resource.
>
>|      transfer-coding         = "chunked" | transfer-extension
>|      transfer-extension      = token
>
>   All transfer-coding values are case-insensitive. HTTP/1.1 uses 
>   transfer coding values in the Transfer-Encoding header field 
>   (Section 10.39).
>
>   Transfer codings are analogous to the Content-Transfer-Encoding 
>   values of MIME [7], which were designed to enable safe transport of 
>   binary data over a 7-bit transport service. However, "safe 
>   transport" has a different focus for an 8bit-clean transfer 
>   protocol. In HTTP, the only unsafe characteristic of message bodies 
>   is the difficulty in determining the exact body length 
>   (Section 7.2.2), or the desire to encrypt data over a shared 
>   transport.
>
> | All HTTP/1.1 applications must be able to receive and decode the 
> | "chunked" transfer coding, and ignore chunked extensions they do
> | not understand. The chunked encoding modifies the body 
>   of a message in order to transfer it as a series of chunks, each 
>   with its own size indicator, followed by an optional footer 
>   containing entity-header fields. This allows dynamically-produced 
>   content to be transferred along with the information necessary for 
>   the recipient to verify that it has received the full message.
>
>       Chunked-Body   = *chunk
>                        "0" CRLF
>                        footer
>                        CRLF
>
>|      chunk          = chunk-size [ chunk-ext ] CRLF
>                        chunk-data CRLF
>
>       chunk-size     = hex-no-zero *HEX
>|      chunk-ext      = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )
>|      chunk-ext-name = token
>|      chunk-ext-val  = token | quoted-string
>       chunk-data     = chunk-size(OCTET)
>
>   |      footer         = *<Content-MD5 and future headers that
>specify
>|                         they are allowed in footer>
>
>       hex-no-zero    = <HEX excluding "0">
>
>   Note that the chunks are ended by a zero-sized chunk, followed by 
>   the footer and terminated by an empty line. An example process for 
>   decoding a Chunked-Body is presented in Appendix C.5.

----------------------------------------------------
Paul J. Leach            Email: paulle@microsoft.com
Microsoft                Phone: 1-206-882-8080
1 Microsoft Way          Fax:   1-206-936-7329
Redmond, WA 98052
Received on Monday, 1 April 1996 02:09:11 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:49 EDT