Last modified: 2009-07-02 00:05:32 UTC
I have a custom client that does not want to receive gzipped data. It specifies so in the HTTP request header as such: Accept-Encoding: identity;q=1.0, gzip;q=0, *;q=0 When requesting http://en.wikipedia.org/wiki/Benzatropine, I still receive a gzip encoded page. The client is using Apache's HttpClient java library. Perhaps this is some kind of caching issue? Here is the full request and response headers. GET /wiki/Benzatropine HTTP/1.1 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 Accept-Encoding: identity;q=1.0, gzip;q=0, *;q=0 Host: en.wikipedia.org HTTP/1.0 200 OK Date: Tue, 30 Jun 2009 14:04:55 GMT Server: Apache X-Powered-By: PHP/5.2.4-2ubuntu5wm1 Cache-Control: private, s-maxage=0, max-age=0, must-revalidate Content-Language: en Vary: Accept-Encoding,Cookie X-Vary-Options: Accept-Encoding;list-contains=gzip,Cookie;string-contains=enwikiToken;string-contains=enwikiLoggedOut;string-contains=enwiki_session;string-contains=centralauth_Token;string-contains=centralauth_Session;string-contains=centralauth_LoggedOut Last-Modified: Tue, 30 Jun 2009 13:54:32 GMT Content-Encoding: gzip Content-Length: 18123 Content-Type: text/html; charset=utf-8 Age: 86264 X-Cache: HIT from sq25.wikimedia.org X-Cache-Lookup: HIT from sq25.wikimedia.org:3128 X-Cache: MISS from sq36.wikimedia.org X-Cache-Lookup: MISS from sq36.wikimedia.org:80 Via: 1.1 sq25.wikimedia.org:3128 (squid/2.7.STABLE6), 1.0 sq36.wikimedia.org:80 (squid/2.7.STABLE6) Connection: close The same problem happens when gzip is simply omitted from the Accept-Encoding as follows: Accept-Encoding: identity I specified gzip as q=0 in the above header in an attempt to be more explicit about what encoding I wanted. This did not make a difference.
Switching component to Mediawiki and updating summary, not a WMF issue. Mediawiki should respect specific requests to not send gzip'd data.
What happens if you simply send this? Accept-Encoding: The spec specifically covers this case, which makes me feel it might be better-supported: If the Accept-Encoding field-value is empty, then only the "identity" encoding is acceptable.
I get the same results with both Accept-Encoding: and with no Accept-Encoding: field sent at all.
*** This bug has been marked as a duplicate of bug 7098 ***
