Edit report at http://bugs.php.net/bug.php?id=44164&edit=1
ID: 44164
Updated by: cataphract@php.net
Reported by: mplomer at gmx dot de
Summary: Handle "Content-Length" HTTP header when
zlib.output_compression active
Status: Assigned
Type: Bug
Package: *General Issues
Operating System: *
PHP Version: 5.2.5
Assigned To: cataphract
Block user comment: N
Private report: N
New Comment:
Sorry for the mess; I was betrayed by the browser's autocomplete.
Previous Comments:
------------------------------------------------------------------------
[2010-12-14 04:58:30] cataphract@php.net
> Our projects make heavy use of Content-Length. Disabling it
unnecessarily is
> costly on networks with large RTT.
The problem is not the existence of a Content-length header, it's the
fact that you're setting a content-length header indicating a size you
cannot possibly know. A wrong Content-length header is worse than none.
Apache already adds a Content-length header when it can (i.e. for small
responses), it's not necessary PHP does this; sending it on every
compressed response is unpractical because it would require buffering
the entire response. If you need this, I suppose you can always
explicitly start the zlib output handler and call ob_get_length.
------------------------------------------------------------------------
[2010-12-14 04:57:52] cataphract@php.net
> Our projects make heavy use of Content-Length. Disabling it
unnecessarily is
> costly on networks with large RTT.
The problem is not the existence of a Content-length header, it's the
fact that you're setting a content-length header indicating a size you
cannot possibly know. A wrong Content-length header is worse than none.
Apache already adds a Content-length header when it can (i.e. for small
responses), it's not necessary PHP does this; sending it on every
compressed response is unpractical because it would require buffering
the entire response. If you need this, I suppose you can always
explicitly start the zlib output handler and call ob_get_length.
------------------------------------------------------------------------
[2010-12-13 17:45:21] panczel dot levente at groware dot hu
Our projects make heavy use of Content-Length. Disabling it
unnecessarily is costly on networks with large RTT.
I also do not agree that manipulating Content-Length is a bad thing to
do for output handlers. To give a correct Content-Length (whenever
possible) is the task of the handler just as setting the
"Content-Encoding: gzip" is.
I'd vote for a solution where zlib output generates a correct
Content-Length whenever it has the opportunity (regarding the current
settings). The most straightforward solution I can imagine is that the
output compression module waits until the first buffer flush and then
right before writing to its output it checks whether the input has
finished [i.e. the whole page is buffered] and that the
compressed+encoded length is known; then it sets the correct
Content-Length. If, but _only_ if any of the above requirements are not
met (input still pending, compressed size is unknown for compression
cannot complete without flushing first) then clear Content-Length and
flush (so it cannot be set anymore).
I think this would maintain correctness, does not need additional
resources (like extra buffering), but keeps the benefits of sending
Content-Length whenever possible. (This last one I find to be a huge
benefit with pages that include many generated CSS-parts or for pages
that dynamically load many files, like dojo.)
------------------------------------------------------------------------
[2010-11-18 05:09:04] cataphract@php.net
Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&revision=305481
Log: - Reversed implementation of FR #44164, pending further
consideration.
See rev #304903.
------------------------------------------------------------------------
[2010-10-30 18:32:34] cataphract@php.net
I'm reopening as the general opinion seems to be that the content-length
header should be suppressed instead of disabling compression.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=44164--
Edit this bug report at http://bugs.php.net/bug.php?id=44164&edit=1