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

Re: Any objections to "Accept-encoding: gzip, *;q=0"?

From: Joel N. Weber II <devnull@gnu.ai.mit.edu>
Date: Tue, 22 Jul 1997 17:41:24 -0400
Message-Id: <199707222141.RAA12983@mescaline.gnu.ai.mit.edu>
To: koen@win.tue.nl
Cc: mogul@pa.dec.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3858
   From: koen@win.tue.nl (Koen Holtman)
   Date: Tue, 22 Jul 1997 09:39:19 +0200 (MET DST)

   Jeffrey Mogul:
   >  (a)	Accept-Encoding: gzip, compress, no-identity
   >		/* an explicit "no identity-encoding wanted" token */

   I like (a) best.  The trouble with adding q values to this header is
   that it makes selecting the `best' encoding much more complicated
   (decoding short floats and finding the highest one is too complicated
   to do in a simple shell script, for example), and this would
   discourage the deployment of servers which know about encodings.

I think it can be done in a shell script.  Noah Friedman is a sysadmin
I know who is very good at writing shell scripts.  I'm sure he could
write an adaquate script within a few hours.

Furthurmore, I think there are a lot of deployed servers which know
about q values for content-types.  If the code can't be recycled,
then the people who wrote it don't know what they're doing.

   I think that the knowledge that `gzip is better than compress is
   better than identity' can just as well be implemented at the server
   side, and implementing it there will be much cheaper.

Probably true.

However, there will be cases where identity is better than any
compressed setting, if you are on a very fast link, and the server
or client has a relatively slow processor.  These are very few;
for a modem connection, even with a 386 I'd want compression.

So I think that encoding that knowlege in the server is reasonable.
Received on Tuesday, 22 July 1997 14:46:59 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:03 UTC