W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1998

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

From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
Date: Wed, 26 Aug 1998 12:09:19 -0700
To: Henrik Frystyk Nielsen <frystyk@w3.org>
Cc: Jim Gettys <jg@pa.dec.com>, http-wg@hplb.hpl.hp.com
Message-Id: <9808261209.aa02185@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/355
>A "TE: chunked" header field means for any particular hop that "I accept
>full featured chunked encoding with trailers and not just the boiled down
>version without trailers". This was a compromise necessary to do was
>existing implementations only support non-trailered chunked encoding.

It does not say that in the definition of TE in the spec, nor should
it say such a thing.  Creating a special-case definition within an
unimplemented header field is not an appropriate design.  TE was
added to the spec to fix one and only one bug -- the desire to add
deflate as a transfer coding without breaking deployed systems.
If that is not its purpose, then I want TE removed from the spec right now.

There are multiple bugs in the definition of the TE header field.

The current definition says that:

   If an TE field is present in a request, and if a server cannot send a
   response which is acceptable according to the TE header field, then the
   server SHOULD send an error response with the 406 (Not Acceptable)
   status code.

which is wrong because the 406 response code indicates a failure
in content negotiation on the origin server, not an unacceptable
transfer coding at any particular hop.  If you want that functionality
it must be defined as a new 5xx status code.  Furthermore, the above
adds a requirement to HTTP/1.1 that is not implemented in deployed
systems and is not necessary for interoperability.

The reality, however, is that no server worth deploying will ever
obey such a requirement.  From the server's point of view, assuming that
the client is broken is preferable to dealing with user complaints
about the inability to get anything but errors with no body content.
TE should not be able to change the acceptability of the identity and
chunked encodings.

There are multiple ways that we could design an EXTENSION to HTTP/1.1
that provided a hop-by-hop method of allowing a maximum buffer size
for chunked content that includes a trailer.  It is not necessary for
us to do it with TE, nor is it appropriate to do so as a last minute
change before moving to draft standard.

Received on Wednesday, 26 August 1998 12:29:13 UTC

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