AUTH-CHUNKED proposed resolution

JG> Could you update your draft in the mailing list (at
JG> http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q2/0063.html) to deal
JG> with these comments and resend to the list, so we can last call it?

  I've appended all of section '3.6 Transfer Codings' with the
  proposed changes below.

  In addition, replace the word 'footer' with 'trailer' in the second
  bullet item in section 8.2 (which discusses a client aborting the
  in-progress transmission of a request body when an error is received
  from the server).

  The resolution also says to move Content-Length from the
  entity-header list in section 7.1 to general-header in section 4.5.

--
Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/


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

          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
   14.40).

   Transfer codings are analogous to the Content-Transfer-Encoding
   values of MIME , 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.

   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 trailer 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
                         last-chunk
                         trailer
                         CRLF

        chunk          = chunk-size [ chunk-ext ] CRLF
                         chunk-data CRLF

        chunk-size     = 1*HEX

        last-chunk     = 1*("0") [ chunk-ext ] CRLF

        chunk-ext      = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )
        chunk-ext-name = token
        chunk-ext-val  = token | quoted-string
        chunk-data     = chunk-size(OCTET)

        trailer         = *entity-header

   The chunked encoding is ended by any chunk whose size is zero,
   followed by the trailer, which is terminated by an empty line.  The
   purpose of the trailer is to provide an efficient way to supply
   information about an entity that is generated dynamically.
   Applications MUST NOT send header fields in the trailer which are not
   explicitly defined as being appropriate for the trailer.

   The Content-MD5 header (section 14.16) is appropriate for the trailer.

   The Authentication-Info header defined by RFC 2069 (An Extension to
   HTTP: Digest Access Authentication), or its successor is appropriate
   for the trailer.

   An example process for decoding a Chunked-Body is presented in
   appendix 19.4.6.

   All HTTP/1.1 applications MUST be able to receive and decode the
   "chunked" transfer coding, and MUST ignore transfer coding extensions
   they do not understand. A server which receives an entity-body with a
   transfer-coding it does not understand SHOULD return 501
   (Unimplemented), and close the connection. A server MUST NOT send
   transfer-codings to an HTTP/1.0 client.

Received on Monday, 28 July 1997 13:06:50 UTC