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

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

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Thu, 24 Jul 97 11:46:31 MDT
Message-Id: <9707241846.AA13229@acetes.pa.dec.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Cc: mogul@pa.dec.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3905
    >As I said in my previous message, introducing qvalues for
    >Accept-Encoding won't work "if any existing servers or proxies would
    >choke on a qvalue in an Accept-Encoding header."
    >But (so far) nobody has asserted than this is an actual problem.
    I feel that the burden of proof that adding q values does *not*
    introduce new problems is entirely on your side.  You need to show
    that this does not break or disable existing implementations.

As stated, this would be a clearly infeasible burden of proof for ANY
change to the protocol, since nobody has an exhaustive list of
existing implementations.  One could just as easily argue that
the same requirement should apply to your proposed (and accepted)
change to Accept-Charset, draft-holtman-http-wildcards-00.txt,
which changes the RFC2068 syntax to allow wildcards.  You do make
a plausible argument that implementations of RFC2068 would ignore
"*" in Accept-Charset, but I don't recall seeing the results
of exhaustive testing.

I repeat my request: if anyone has specific information that this
is an actual problem, I would certainly withdraw the proposal.

At any rate, I have looked at the source code of a number of
servers (including Apache), and tried a few experiments
(including via an existing commercial proxy implementation).
It looks like if Accept-Encoding includes a content-coding
with a qvalue, it's simply ignored.  (The fact of the matter
is that almost NO clients actually send Accept-Encoding today;
Henrik thought that there were none in actual use, but I found
a few uses in our proxy traces, all from Lynx users.)

By the same logic as you used in draft-holtman-http-wildcards-00.txt,
where you said it was OK to define "*" in Accept-Charset because
RFC2068 servers would simply ignore it, it should be OK to introduce
qvalues in Accept-Encoding if the servers also would simply ignore
the associated content-coding.

However, it might be a good idea to include this note for
client implementors:

	Note: use of a qvalue with a content-coding defined
	in RFC2068 ("compress" or "gzip") may cause an
	RFC2068-compliant implementation to ignore the
	content-coding value.

Received on Thursday, 24 July 1997 12:00:49 UTC

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