W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

HTTP/1.1 ISSUE: TRAILER_FIELDS - Proposed Resolution

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Mon, 17 Nov 1997 18:37:48 -0500
Message-Id: <>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4708

In response to the TRAILER_FIELDS issue [1], here is a proposal for a new
general Trailer header field that indicates which header fields the
recipient can expect in the trailer of a message encoded using chunked
transfer-encoding. The Trailer header field is modelled after the Vary
header field.

This change requires the Accept-Transfer header field defined in an earlier
mail (not in the archives at this point)


[1] http://www.w3.org/Protocols/HTTP/Issues/#TRAILER_FIELDS



Replace section 3.6 with the following:

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. Therefore, transfer codings only apply to the immediate

       transfer-coding         = token

All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer
coding values in the Accept-Transfer header field (section Y) and the
Transfer-Encoding header field (section 14.40).

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

The Internet Assigned Numbers Authority (IANA) acts as a registry for
transfer-coding value tokens. Initially, the registry contains the
following tokens: "chunked" (section 3.6.1) and "identity" (section 3.6.2).

The registration of new transfer-codings are done as for content-codings.

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.

3.6.1 Chunked Transfer Coding

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
       chunk          = chunk-size [ chunk-extension ] CRLF
                        chunk-data CRLF
       chunk-size     = 1*HEX 
       last-chunk     = 1*("0") [ chunk-extension ] CRLF

       chunk-extension= *( ";" 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 chunk-size field is a string of hex digits indicating the size of the
chunk. The chunked encoding is ended by any chunk whose size is zero,
followed by the trailer, which is terminated by an empty line.

The trailer allows the sender to include additional HTTP header fields at
the end of the message. The Trailer header field can be used to indicate
which header fields are included in a trailer (see section X).

A server using chunked transfer-coding in a response MUST NOT use the
trailer for other header fields than Content-MD5 and Authentication-Info
unless the "chunked" transfer-coding is present in the request as an
accepted transfer-coding in the Accept-Transfer field.

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

All HTTP/1.1 applications MUST be able to receive and decode the "chunked"
transfer coding, and MUST ignore chunk-extension extensions they do not

3.6.2 Identity Transfer Coding

The identity transfer-encoding is the default (identity) encoding; the use
of no transformation whatsoever.  This transfer-coding is used only in the
Accept-Transfer header, and SHOULD NOT be used in any Transfer-Encoding


Also add the Description of Trailer Header Field as a new header:


The Trailer general field value indicates that the given set of header
fields are present in the trailer of a message encoded with chunked

       Trailer  = "Trailer" ":" 1#field-name

An HTTP/1.1 sender MAY include a Trailer header field in a message using
chunked transfer-coding with a non-empty trailer. Doing so allows the
recipient to know which header fields to expect in the trailer.

If no Trailer header field is present, the trailer SHOULD NOT include any
other header fields than Content-MD5 and Authentication-Info.

A server MUST NOT include any other header fields unless the "chunked"
transfer-coding is present in the request as an accepted transfer-coding in
the Accept-Transfer field.

Message headers listed in the Trailer header field MUST NOT include the
Transfer-Encoding and the Trailer header field.


Received on Monday, 17 November 1997 15:38:45 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC