- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Thu, 24 Jul 97 11:46:31 MDT
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
- Cc: mogul@pa.dec.com
>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. -Jeff
Received on Thursday, 24 July 1997 12:00:49 UTC