Bug #44164 [Asn]: Handle "Content-Length" HTTP header when zlib.output_compression active

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: Crash when using unserialized DatePeriod instance +Summary: Handle "Content-Length" HTTP header when zlib.output_compression active Status: Assigned Type: Bug -Package: Date/time related +Package: *General Issues -Operating System: Windows XP SP3 +Operating System: * -PHP Version: 5.3.3 +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. 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-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. ------------------------------------------------------------------------ [2010-10-26 04:16:23] cataphract@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. ------------------------------------------------------------------------ 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