CHUNKED: closed

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
>
>

Received on Wednesday, 3 April 1996 15:42:49 UTC