Edit report at http://bugs.php.net/bug.php?id=44164&edit=1
ID: 44164
User updated by: mplomer at gmx dot de
Reported by: mplomer at gmx dot de
Summary: Handle "Content-Length" HTTP header when
zlib.output_compression active
Status: Assigned
Type: Feature/Change Request
Package: *General Issues
Operating System: *
PHP Version: 5.2.5
Assigned To: cataphract
Block user comment: N
New Comment:
In the meantime we do output-compression only via apache. But back to
the problem:
First I thought it would be better to remove the header if present
(buffering output is not an option of course), but it is also an idea to
disable output compression completely, when this header is set (which is
a rare case in our environment, and INHO most php users, too).
Our problem was that Varnish Reverse Proxy was confused by this
inconsistent headers. Both solutions would solve this.
Previous Comments:
------------------------------------------------------------------------
[2010-10-23 15:04:29] cataphr...@php.net
I've just been hit by this problem and I'm thinking a better option
would be to disable zlib.output_compression if the Content-Length header
is set. What do you think?
Buffering everything and then calculating the actual length is not
really an option, the output could be several hundred megabytes.
------------------------------------------------------------------------
[2008-02-19 11:04:24] mplomer at gmx dot de
Another idea is:
IF the Content-Length header IS set from the script,
THEN buffer the complete output and calculate the correct compressed
Content-Length.
ELSE do nothing (do not add any Content-Length header)
So ob_flush(), flush() will still work if compression is active. (Which
will not work, if we use apache's mod_deflate. This is why
"zlib.output_compression" is required.)
------------------------------------------------------------------------
[2008-02-19 10:48:09] mplomer at gmx dot de
Description:
------------
If you have a big project, where "Content-Length" header is set on many
places, and then you turn on "zlib.output_compression", you will have a
problem, because the original header is still passed through, but it is
invalid now, because it contains the length of the uncompressed data
instead of the compressed data.
This would confuse some HTTP clients, that rely on the
"Content-Length".
I think, "zlib.output_compression" should be completely transparent, so
this issue should be handled in php core.
One solution is, to remove the "Content-Length" header (if set) in
ob_gzhandler() in ext/zlib/zlib.c:882 (where "Content-Encoding: gzip"
header is set). If you see a good way to set the Content-Length to the
compressed length, this would be, of course, the best solution, but this
is IMHO only possible, if the entire data is buffered before (or is this
done by ob_gzhandler anyway?).
This would make the various workarounds irrelevant that have to be done
if "zlib.output_compression" is active and is completely backward
compatible.
Reproduce code:
---------------
In php.ini:
zlib.output_compression = On
<?php
$output = str_repeat('A', 8192);
header('Content-Length: ' . strlen($output));
?>
Expected result:
----------------
Correct "Content-Length" header or removed "Content-Length" header in
response, because the old length is always wrong. Better send no
"Content-Length" instead a wrong length.
Actual result:
--------------
The old "Content-Length" header is sent.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/bug.php?id=44164&edit=1
