[ This bug is one of the recommendations in the W3C's "Common User Agent Problems" document, URL above. One bug has been filed on each recommendation, for deciding whether we do it and, if not, whether we should. ] 1.14 Only advertise an encoding in Accept-encoding that you really accept. A number of web sites suffer from bandwidth overload. By altering the server side scripting engine to support encoding compression or by inserting a compressing proxy, it is possible to dramatically reduce the operating costs. The down side is that a number of user agents advertise that they can handle gzip or deflate when they really are unable to do it. References: * For more information on content negotiation, see section 12 of the HTTP/1.1 specification, [RFC2616]. * For more information about the HTTP Accept-Encoding header, see section 14.4 of the HTTP/1.1 specification, [RFC2616].

Gerv, as far as I'm aware we do support all the encodings we advertise... (though recently there have been suggestions that "compress" is ambiguous and can stand for one of two _different_ encodings of which we support only one).

-> HTTP

bz: unless you can find a webserver which sends the wrong one when we advertise "compress", then I think we are OK in practice :-) Normally, W3C CUAP items are "aimed" at particular browsers, like the one about not moving the viewport for non-existent anchors was aimed at NS 4.x. Who is this aimed at? Gerv

> unless you can find a webserver Bug 160755 ;) Not sure about who it's aimed at; I've heard varied reports about Opera and KHTML in this area and I trust none of them. The question is, is there a mozilla bug here? ;)

Deflate and compress issues have been resolved.