Last modified: 2009-03-18 21:27:13 UTC
Created attachment 5824 [details] Fixes bug When PHP has zlib.output_compression enabled, it compresses all pages output, regardless of their HTTP status code. Even empty pages get a ~13 byte empty gzipped file tacked as their response. Unfortunately, for HTTP status code 304, this is in direct violation of the specification; furthermore, if SSL and Keep-Alive are enabled, Firefox gets sufficiently confused such as to post a download page for the page immediately after the 304 with extra information afterwards (it mixes up the packets). I've attached a patch that fixes this bug by manually turning off zlib.output_compression when a 304 is being sent. I am also coordinating with PHP's maintainers to get this fixed upstream. Relevant links: https://bugzilla.mozilla.org/show_bug.cgi?id=363109 (bug for Firefox getting confused by data after 304) http://bugs.php.net/bug.php?id=42362 (bug for PHP not turning of zlib.output_compression when there is empty output)
I think I've seen problems when the Content-encoding on the 304 doesn't match the cached data before; can you double-check that behavior is still consistent in this behavior mode?
No problems on Firefox, using this test script: <?php if (isset($_SERVER['HTTP_IF_MODIFIED_SINCE'])) { ini_set('zlib.output_compression', 0); header('HTTP/1.1 304 Not Modified'); header('Last-Modified: Tue, 17 Feb 2009 22:18:25 GMT'); } else { header('Cache-Control=private, s-maxage=0, max-age=0, must-revalidate'); header('Last-Modified: Tue, 17 Feb 2009 22:18:25 GMT'); var_dump($_SERVER); ?><a href="">asdf</a><?php }
By request of Brion on IRC, it works fine on IE/Mac. :-)
Created attachment 5829 [details] Fixes bug Fix minor typo in patch
Some further research has found it is possible to tickle this bug in Firefox without SSL, but much more difficult.
Applied in r48540
