CHUNKED: closed
Paul Leach (paulle@microsoft.com)
Wed, 3 Apr 1996 15:39:38 -0800
It appears that all questions on this issue have been answered without
requiring any changes, so this issue is hereby declared closed for the
upcoming draft.
>----------
>From: Paul Leach
>Sent: Sunday, March 31, 1996 4:53 PM
>To: 'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'
>Subject: CHUNKED: draft changes
>
>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
>
>