Last modified: 2012-07-19 18:26:48 UTC
The latest updates to Safari in Mac OS X 10.4.4 seem to have broken loading of pages that have a ".gz" extension when they're sent with gzip encoding. The browser downloads the gzipped text to a file instead of displaying it inline. This is clearly a bug in either Safari itself or WebKit; I'll investigate and file bugs/patches to Apple. In the meantime, we might consider as a workaround sending pages whose URLs end in '.gz' without compression. Yucky hack, but seems to work in my testing. (Possibly refile this under Wikimedia, if we don't want such a hack polluting the main software. An if() in CommonSettings will do the job.)
Added hack in CommonSettings.php like this: # Safari bug with URLs ending in ".gz" and gzip encoding # http://bugzilla.wikimedia.org/show_bug.cgi?id=4635 $hatesSafari = isset( $_SERVER['PATH_INFO'] ) && strtolower( substr( $_SERVER['PATH_INFO'], -3 ) ) == '.gz'; then check that var before adding the buffering handler. Marking this FIXED since I've worked around it, still investigating to make sure it's reported back to Apple.
Haven't found the source of the problem in WebKit source yet, but can confirm that I can't correctly visit pages which would exhibit this bug in Safari in a quickie WebKit-based Xcode project. So it doesn't seem to be the Safari front-end code, but lower-level where I might be able to locate it...
Alas, it seems to be even lower-level than WebKit/WebCore, so out of my reach again. :) As recommended by the folks in #webkit, I've filed a bug with Apple. Radar problem ID 4410917.
Do we still need this hack in our settings? Is 6 years enough time to hope everyone is running a newer version? I guess in the Apple world that's even more likely... http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm
It's probably safe to ditch this, but test first. :)
