Edit report at http://bugs.php.net/bug.php?id=51579&edit=1
ID: 51579
Comment by: roan dot kattouw at gmail dot com
Reported by: boris at povolnam dot ru
Summary: ob_gzhandler/header("304") incompatibility
Status: Open
Type: Feature/Change Request
Package: Unknown/Other Function
Operating System: irrelevant
PHP Version: 5.2.13
Block user comment: N
Private report: N
New Comment:
Clarification: the HTTP spec requires 304 responses be empty, and
Firefox is very particular about that. But ob_gzhandler gzips even empty
responses, and gzipping the empty string does not return the empty
string (GZIP header, at least).
Proposed solution: if there was no output (empty buffer), do not
compress and do not send Content-Encoding:gzip
Previous Comments:
------------------------------------------------------------------------
[2010-04-17 01:22:02] boris at povolnam dot ru
Description:
------------
test script below will produce a response with not empty body (it will
contain gzip stream header) which breaks the W3C standart that requires
304 response to have empty body.
The idea was to speed up things with compression and leveraging client
side caching, but end up firefox (v.3.6.3) prepending with that body
some of conseqent responces (css file in my case, which broken styles
rendering - that was really really hard to find - i just coudn't
understand why my server returns corrupted file and only to firefox)
Test script:
---------------
<?php
ob_start("ob_gzhandler");
header('HTTP/1.1 304 Not Modified');
ob_end_flush();
?>
Expected result:
----------------
ob_gzhandler() to look into response headers and wipe out buffer and
disable compression if 304 is set. Cause it's a subtle thing about 304
header, its body and the way ob_gzhandler() works and others can run
into same problem while trying to speed up website as compression and
client-side caching are 2 main things to do.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/bug.php?id=51579&edit=1
