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

At 08:55 26/08/1998 -0700, Jim Gettys wrote:
>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.

Regardless of the solution chosen, I would like to point out that TE indeed
can be used for this and indeed it was (at least by me, intended) for this
purpose.

Trailers must be dealt with on a hop-by-hop basis by all the parties down
the chain. That is, it is a "repeated hop-by-hop" because each step has to
agree and not only the "end".

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.

If a client is willing to accept data in the trailer, it indicates this
using the "TE: chunked" header field.

This works in all cases - regardless of whether there are HTTP/1.0 proxies,
existing limited HTTP/1.1 chunking proxies or HTTP/1.1 chunking proxies
that understand trailers. For example, if a proxy doesn't see this in a
request then it can either say:

	1) I don't want to risk having to buffer so I don't send TE: chunked
	2) I don't mind buffering and include a TE: chunked.

and if it sees it and understands trailers then it can just repeat the "TE:
chunked" in its request to the next server.

The other part of TE was Trailer which the server uses to indicate which
header fields are included in the response or not. This makes it very easy
for a proxy to see up front whether it has to buffer or not (if it
indicated that it was willing to buffer).

This also works for arbitrary header fields *except* content-md5 and
authentication-info which were already in the spec at the time, TE was
introduced. *Removing* the special case for these two header fields will
solve the problem and does not require any additional checks in the server
like looking for the via field.

Henrik
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Wednesday, 26 August 1998 09:26:28 UTC