CHUNKEDTRAILERS, attempted fix 2

Henrik and I sat down and discussed the various options and meaning
behind the existing sections.  As a result, here is a proposed fix
that better fits current practice and allows for future improvements.

Much of the confusion of TE is in the use of "chunked" to indicate
that trailers are okay (it serves no other purpose in TE).  If we
replace that token with "trailers", much of the confusion goes away
and we can ensure that the client sending it does fully understand
what it is saying when it says it agrees to accept trailers.

The other part is we both agree that the use of 406 is wrong.
Since it is only used when identity;q=0 is present, and there
has yet to be any real need for that with transfer codings, the
easiest solution is to just remove it instead of replacing it
with a new 5xx code.

So, here is another proposed solution:

In section 3.6.1 (Chunked Transfer Coding), change this paragraph:

        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 TE
        field (section 14.39). The Authentication-Info header is
        defined by RFC 2069 [32] or its successor [43].

to read

    A server using chunked transfer-coding in a response MUST NOT
    use the trailer for any header fields unless at least one of 
    the following is true:

       a) the request included a TE header field that indicates
          "trailers" is acceptable in the transfer-coding of the
          response, as described in section 14.39; or,

       b) the server grants the recipient(s) the right and ability to
          discard those trailer fields without forwarding them to any
          downstream recipient of the remaining message.  This is
          only possible if the trailer fields consist entirely of
          optional metadata that is not necessary for the recipient
          to understand in order to use the message.

    The above requirement exists to avoid an interoperabilty paradox
    when the message is being received by an HTTP/1.1 (or later) proxy
    and forwarded to an HTTP/1.0 recipient.  It avoids a situation
    where compliance with the protocol would have necessitated an
    infinite buffer on the proxy.

In section 14.40 (Trailer), change this paragraph

    If no Trailer header field is present, the trailer SHOULD NOT
    include any header fields other 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 TE field.

to    

    If no Trailer header field is present, the trailer SHOULD NOT
    include any header fields.  See section 3.6.1 for restrictions
    on the use of trailer fields in a "chunked" transfer-coding.

In section 3.6, replace

    Whenever a transfer-coding other than "identity" is applied to a
    message-body, the set of transfer-codings MUST include "chunked", unless
    the message is terminated by closing the connection. When the "chunked"
    transfer-coding is used, it MUST be the last transfer-coding applied to
    the message-body. The "chunked" transfer-coding MUST NOT be applied more
    than once to a message-body. These rules allow the recipient to
    determine the transfer-length of the message (section 4.4).

with

    Whenever a transfer-coding is applied to a message-body, the set of
    transfer-codings MUST include "chunked", unless the message is
    terminated by closing the connection. When the "chunked"
    transfer-coding is used, it MUST be the last transfer-coding applied to
    the message-body. The "chunked" transfer-coding MUST NOT be applied more
    than once to a message-body. These rules allow the recipient to
    determine the transfer-length of the message (section 4.4).

Delete section 3.6.2:

    3.6.2 Identity Transfer-Coding

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

In section 14.39 (TE), replace as follows:

    14.39 TE

    The TE request-header field indicates what extension transfer-codings
    it is willing to accept in the response and whether or not it is
    willing to accept trailer fields in a chunked transfer-coding.
    Its value may consist of the keyword "trailers" and/or a
    comma-separated list of extension transfer-coding names with
    optional accept parameters (as described in section 3.9).

           TE         = "TE" ":" #( t-codings )
           t-codings  = "trailers" | ( transfer-extension [ accept-params ] )

    The presence of the keyword "trailers" indicates that the client is
    willing to accept trailer fields in a chunked transfer-coding, as
    defined in section 3.9.1.  This keyword is reserved for use with
    transfer-coding values even though it does not itself represent a
    transfer-coding.

    Examples of the use of the TE field:
    
           TE: deflate
           TE:
           TE: trailers, deflate;q=0.5

    The TE header field only applies to the immediate connection. Therefore,
    the keyword MUST be supplied within a Connection header field (section
    14.10) whenever TE is present in an HTTP/1.1 message.

    A server tests whether a transfer-coding is acceptable, according to a
    TE field, using these rules:

      1. The "chunked" transfer-coding is always acceptable.  If the keyword
         "trailers" is listed, the client indicates that it is willing to
         accept trailer fields in the chunked response on behalf of itself
         and any downstream clients.  The implication is that, if given, the
         client is stating that either all downstream clients are willing
         to accept trailer fields in the forwarded response, or that it
         will attempt to buffer the response on behalf of downstream
         recipients.

         Note: HTTP/1.1 does not define any means to limit the size of
         a chunked response such that a client can be assured of buffering
         the entire response.

      2. If the transfer-coding being tested is one of the transfer-codings
         listed in the TE field, then it is acceptable unless it is
         accompanied by a qvalue of 0. (As defined in section 3.9, a
         qvalue of 0 means "not acceptable.")

      3. If multiple transfer-codings are acceptable, then the acceptable
         transfer-coding with the highest non-zero qvalue is preferred.
         The "chunked" transfer-coding always has a qvalue of 1.

      4. If the TE field-value is empty or if no TE field is present, the
         only transfer-coding is "chunked".  A message with no
         transfer-coding is always acceptable.

[end of section]

In 19.6.3 (Changes from RFC 2068), delete

    A content-coding of "identity" was introduced, to solve problems
    discovered in caching. (section 3.5)

In 19.7.1 (Transfer-coding Values), replace

    This document defines a new class of registry for its transfer-coding
    values as part of the solution to solve problems discovered in RFC 2068
    with the caching of transfer encoded documents. Initially, the registry
    should contain the following tokens: "chunked" (section 3.6.1),
    "identity" (section 3.6.2), "gzip" (section 3.5), "compress" (section
    3.5), and "deflate" (section 3.5). ...

with

    This document defines a new class of registry for its transfer-coding
    values as part of the solution to solve problems discovered in RFC 2068
    with the caching of transfer encoded documents. Initially, the registry
    should contain the following tokens: "chunked" (section 3.6.1),
    "gzip" (section 3.5), "compress" (section 3.5), "deflate" (section 3.5),
    and the special keyword "trailers" (section 14.39). ...


....Roy and Henrik

Received on Wednesday, 26 August 1998 15:03:16 UTC