- From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
- Date: Tue, 18 Nov 1997 17:33:31 -0800
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
As our messages fly past each other on the net ...
In message <9711190116.AA01262@acetes.pa.dec.com>, Jeffrey Mogul writes:
>I expect to get flamed for this message, but I sort of promised someone
>that I would make the attempt.
No flames, but here is some gasoline for ya.
>Some of the potentially-useful transfer-coding algorithms are
>inherently parameterizable. For example, "gzip" has 9 different
>compression levels (trading off compression ratio for speed).
>"compress" has a range of possible settings (I'm not quite sure how
>many). In both cases, once the sender has chosen a setting, the
>recipient should be able to decompress the result, but HTTP provides no
>mechanism for the client to suggest the preferred setting.
Yes. The same thing can be (IMHO) more easily accomplished as
Connection: deflate
Deflate: --best
(or whatever options might be desired). The sender would still be in
control, of course, but this is far more informative than a qvalue.
BTW, "compress" is a dead encoding -- it has no reliable definition
other than "that thing you get when you run compress on Unix."
Likewise, "deflate" obsoletes "gzip". In fact, it would probably
be sensible to go back and remove "gzip" and "compress" and simply
standardize on "deflate", "x-gzip", and "x-compress" (plus whatever
new encodings come out down the road).
BTW BTW, the reason for this rapid-fire set of responses today is
that I am about to go off-line for a while so that I can get some
real work done. Two conference deadlines on Dec 1 and a UCI
research dealine on Dec 12 can't coexist with standards discussions.
....Roy
Received on Tuesday, 18 November 1997 17:54:22 UTC