Last modified: 2014-07-28 15:25:00 UTC
Created attachment 15923 [details] Screenshot of Safari network debugger panel for broken styles The styles as loaded from my freshly installed mediawiki-vagrant: http://localhost:8080/w/load.php?debug=false&lang=en&modules=mediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.skinning.interface%7Cmediawiki.ui.button%7Cskins.vector.styles&only=styles&skin=vector&* somehow ends up delivering raw gzipped data in Safari, while I see the expected decompressed CSS text in Chrome and Firefox. This of course means an unstyled site which is not very usable. :D I can actually save the garbled file to disk and gunzip it from there... Doesn't seem to be browser cache, I can repro it on a second machine or by changing URL. Sometimes clears up if I manually remove or rearrange some modules from the query string, but other times it gives me a different, but still extra-zipped, data set. Safari's debugger indicates the file is marked as gzipped, so it seems to be double-gzipped rather than missing the header. Interestingly, Content-Encoding header says "gzip, gzip". Hmmm.
Chrome and Firefox show the same "Content-Encoding: gzip, gzip" ... I think Chrome & Firefox are actually applying decompression twice, while Safari is not. Is something intermittently adding a second layer of gripping? HTTP 1.1 spec seems to indicate that multiple content-encodings are legit, but I wouldn't recommend relying on it. :)
Change 145771 had a related patch set uploaded by Ori.livneh: hhvm: set GzipCompressionLevel = 0 to avoid double-gzip https://gerrit.wikimedia.org/r/145771
Change 145771 merged by jenkins-bot: hhvm: set GzipCompressionLevel = 0 to avoid double-gzip https://gerrit.wikimedia.org/r/145771
Confirmed that ori's patch fixes the double gzipping for me. Yay!
The same double gzip occurs on beta bug 68720
