W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Re: Accept-Transfer header field (was HTTP/1.1 Issues:

From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
Date: Wed, 19 Nov 1997 16:21:28 -0800
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9711191635.aa14032@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4754
>    Connection: deflate
>    Deflate: --best
>This has some things to recommend it, but unfortunately it
>won't quite work.  The most significant problem is that it
>doesn't work with multiple transfer-codings on the same message.

I was talking about the other side of the information exchange, i.e.,
what the sender would like to see in the response, not what has
been applied to the response.  The former is not subject to hierarchy.

My impression was that all transfer encodings would be self-descriptive
(i.e., that any applied parameters that might be needed by the decoder
would be contained at the beginning of the coded body).  Granted, you
could easily define an encoding for which that is not the case, but
I see no reason why we should.  Even so, you would only need ordered
parameters in the Transfer-Encoding syntax, whereas my proposal is a
replacement for only the Accept-TE stuff that Henrik proposed.

BTW, I *really* *really* dislike Accept-TE, both in terms of syntax
and in the mistake of associating it with end-to-end content negotiation.
It is possible to make this feature so complex that nobody will implement
it at all, regardless of the potential benefits of compressed transfers.
It is also possible to introduce so many optional parameterizations of
the "requesting encoding" side of the equation that the actual
implementation becomes less optimal (i.e., reusable) than no encoding.
In this case, keep it simple really means keep it simple or not at all.

I also agree with Larry in that none of these proposals belong in rev-01.

Received on Wednesday, 19 November 1997 16:43:22 UTC

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