| Raymond | |
| Oct 15 2008, 3:22 PM |
| F5107: wp-msie-documenttype_dump_jha.zip | |
| Nov 21 2014, 10:18 PM |
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:
Mabe Squid related?
Version: unspecified
Severity: normal
addicks wrote:
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.
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?
addicks wrote:
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