Edit report at http://bugs.php.net/bug.php?id=44164&edit=1
ID: 44164
Updated by: cataphr...@php.net
Reported by: mplomer at gmx dot de
-Summary: Handle "Content-Length" HTTP header when
zlib.output_compression active
+Summary: Crash when using unserialized DatePeriod instance
Status: Assigned
-Type: Feature/Change Request
+Type: Bug
-Package: *General Issues
+Package: Date/time related
-Operating System: *
+Operating System: Windows XP SP3
-PHP Version: 5.2.5
+PHP Version: 5.3.3
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.
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.
Previous Comments:
------------------------------------------------------------------------
[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] 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.
------------------------------------------------------------------------
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
