Last modified: 2008-10-16 14:27:07 UTC
In the past weeks and more in the past days the Germann OTRS support team get some complains every day that the browser is offering a download of a gzipped file instead of showing the page. It's hard to isolate the circumstances but it seems: * Anons only with * Internet Explorer Mabe Squid related?
Created attachment 5437 [details] tcpdump and screendump of problem.
Have look at the type3-crew, dealing with the same problem and solving it: http://bugs.typo3.org/view.php?id=4623 they link as explanation http://blogs.msdn.com/wndp/archive/2006/08/21/Content-Encoding-not-equal-Content-Type.aspx where you find as 2nd comment a response of microsoft on the issue, why they consider, MSIE not to be broken, behaving like it does.
*** This bug has been marked as a duplicate of bug 15149 ***
Summary on the attachment: IE7 on XP SP3 There's a caching layer by machine 'Mozilla-X11', which seem to be Privoxy/3.0.6 The tcpdump capture contain: Google on-type suggestions Google desktop connection The google search using Google toolbar Two petitions for the wikipedia page returning a 304 Not Modified. A pity it doesn't contain the actual broken response.
(In reply to comment #2) The MSIE problem is with pages having a Content-Encoding: x-gzip header. Mediawiki does not send that, not even if you explicitely only accept x-gzip (some servers state a x-gzip content-encoding when x-gzip has been requested, the problem on the typo3 bug was because the page was cached by a proxy).
The captures show the browser is not sending an Accept-Encoding header. The capture from DECT do provide the wikipedia answer, which look fine (uncompressed content). The files DECT and HDTV (the queried downloads) ungzip correctly. Is the proxy requesting compression by themself and passing the compressed content? Is it doing user-agent sniffing instead of checking for Accept-Encoding header?
I added a second dump (hopefully with no "cache hit - not modified" instead of actual data) here: https://bugzilla.wikimedia.org/attachment.cgi?id=5442
