Edit report at http://bugs.php.net/bug.php?id=44164&edit=1
ID: 44164
Comment by: panczel dot levente at groware dot hu
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
Private report: N
New Comment:
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.)
Previous Comments:
------------------------------------------------------------------------
[2010-11-18 05:09:04] cataphr...@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] cataphr...@php.net
I'm reopening as the general opinion seems to be that the content-length
header should be suppressed instead of disabling compression.
------------------------------------------------------------------------
[2010-10-26 04:16:23] cataphr...@php.net
Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&revision=304903
Log: - Implemented request #44164, zlib.output_compression is now
implicitly
disabled when the header "Content-length" is set.
#One could argue that any output handler could change the size of the
#response, so this exception for zlib.output_compression is an
#inconsistency. However, zlib.output_compression is presented as a
#performance setting, whose value should have no effect on the
#correctness of the scripts. This was not the case. Setting the
#header "content-length" and enabling zlib.output_compression
was
#a recipe for infringing section 4.4 of RFC 2616.
------------------------------------------------------------------------
[2010-10-23 16:49:53] mplomer at gmx dot de
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.
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
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
