Fwd: Analysis of "chunking, trailers, and buffering" problem (CHUNKEDTRAILERS)

Here is the proposed resolution to this issue for the general mailing list,
per the discussion at the working group meeting.  I'll update the issues list
with a pointer to this mail when I get a chance...
			- Jim


From: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Date: Fri, 21 Aug 1998 16:36:12 -0700
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: Larry Masinter <masinter@parc.xerox.com>,
        Paul Leach <paulle@microsoft.com>, jg@w3.org, frystyk@w3.org,
        josh@microsoft.com, luotonen@netscape.com,
        Scott Lawrence <lawrence@agranat.com>,
        Richard Gray <rlgray@us.ibm.com>
Subject: Re: Analysis of "chunking, trailers, and buffering" problem
-----
I really really really dislike the continuing use of TE to indicate
anything about trailers.  In order for trailers to be usable, the
entire response path must be willing to forward them or be willing
to buffer the entire message or be allowed to discard them.  TE cannot
indicate that because it is a hop-by-hop field, so we'd be better off
removing the exception entirely and leaving that functionality to
be specified properly in the future.

Likewise, making specific exceptions for Content-MD5 and Authentication-Info
is unnecessary if we just make a general statement for the condition
where trailer fields can be included if it is permissible to ignore them.

In other words, I believe the following is substantially better:

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 are true:

       a) there is no Via header field (indicating a connection without
          intermediary proxies);

       b) all of the protocols listed in the Via header field are
          HTTP/1.1 or later; or,

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

....Roy