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

   Date: Mon, 21 Jul 97 15:59:25 MDT
   From: Jeffrey Mogul <mogul@pa.dec.com>

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

     (b)	Accept-Encoding: gzip, compress, strict
		   /* "strict" means "this set, or nothing" */

Note that any older server will ignore the `strict' or the `no-identity',
so you still might get uncompressed content.

     (c)	Accept-Encoding: gzip, compress, identity;q=0.0
		   /* allow qvalues here */

     (d)	Accept-Encoding-Strict: gzip, compress
		   /* define new header to avoid compatibility questions */

This breaks existing servers to some extent, and I really think it's
ugly and really don't like it.

     (e)	Accept-Encoding: gzip, compress, *;q=0

   I.e., the "coding"
	   *;q=0
   is semantically equivalent to the "strict" token in (b) above,
   but somewhat closer to the form of the other Accept-* headers.

   My own preference is for one of these two approaches:

     (c)	Accept-Encoding: gzip, compress, identity;q=0.0
     (e)	Accept-Encoding: gzip, compress, *;q=0

I like (c) and (e), though I wouldn't be able to agree that they are
good if any server will choke on them.

Of course, I don't quite see why I would need to reject the identity
encoding.

   P.S.: We may have to include a Note to client implementors that
   sending a qvalue for a content-coding from the set {"compress",
   "gzip", "x-compress", "x-gzip"} might be misinterpreted by older
   servers, and so is not recommended.  At least, the one older server
   source that I looked at (Apache_1.1b3) looks like it will treat
	   Accept-encoding: gzip;q=1.0
   as a request for a content-coding that it doesn't know about.

Sad.  I'd like E-scape to advertise that it can handle compress, but
prefers gzip (because patents mean that a compress implementation
can't be free from fear of lawsuits unless royalties are paid;
whereas gzip doesn't seem to have this problem).

Received on Monday, 21 July 1997 17:14:29 UTC