HTTP/1.1 ISSUE: TRAILER_FIELDS - Proposed Resolution

I don't see the point of the trailer field at all.
Why not just say, as suggested:

Only put fileds in the trailer that can be safely ignored by the
client (e.g., Last-Modified).  Content-Length is expressly forbidden in
the trailer and if found MUST be ignored.

** Reply to note from Henrik Frystyk Nielsen <frystyk@w3.org> Mon, 17 Nov 1997 18:37:48 -0500
>   
>   
> 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)
>   
> Henrik
>   
> [1] http://www.w3.org/Protocols/HTTP/Issues/#TRAILER_FIELDS
>   
> ****************************************************************************
>   
> Changes:
>   
> 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
> connection.
>   
>        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
> transport.
>   
> 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
>                         last-chunk
>                         trailer
>                         CRLF
>        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
> 19.4.6.
>   
> 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
> understand.
>   
> 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
> header.
>   
> ****************************************************************************
>   
> Also add the Description of Trailer Header Field as a new header:
>   
> Trailer
>   
> The Trailer general field value indicates that the given set of header
> fields are present in the trailer of a message encoded with chunked
> transfer-coding.
>   
>        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.
>   
> ****************************************************************************
>   
> Henrik
>   
> 
 

Richard L. Gray
will code for chocolate

cc: Henrik Frystyk Nielsen <frystyk@w3.org>

Received on Wednesday, 19 November 1997 11:06:22 UTC