ID: 42362
User updated by: ob dot php at daevel dot net
-Summary: Contents after "zlib.output_compression" and a 304
page
Reported By: ob dot php at daevel dot net
-Status: No Feedback
+Status: Open
Bug Type: HTTP related
Operating System: Debian Etch
PHP Version: 5.2.3
New Comment:
The RFC say :
"The 304 response MUST NOT contain a message-body, and thus is always
terminated by the first empty line after the header fields."
Source : http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
(cf 10.3.5 "304 Not Modified" )
Actually PHP sent the "GZIP Magic Header" (I'm not talking about the
HTTP headers, but the start of a gzip compressed data).
Previous Comments:
------------------------------------------------------------------------
[2007-09-04 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
------------------------------------------------------------------------
[2007-08-27 11:07:01] [EMAIL PROTECTED]
How is this a bug when you tell in your request that you accept gzipped
data? Of course you get that header then.
------------------------------------------------------------------------
[2007-08-21 15:13:31] ob dot php at daevel dot net
I add : there is exactly 26 bytes between the 2 requests :
1f 8b 80 00 00 00 00 00 00 30 20 00 00 00 ff ff
30 00 00 00 00 00 00 00 00 00
So it seems to be the "gzip header".
------------------------------------------------------------------------
[2007-08-21 14:51:30] ob dot php at daevel dot net
Description:
------------
Hello,
when zlib.output_compression is enabled and the script stop without any
contents (case of a 304 page), after all PHP sends contents.
So, if the client use keep-alive, the next request could be
"corrupted".
I use php as an Apache 2 module. I reproduced it under PHP 4.4.X too.
Note : if I disable "zlib.output_compression" and use "ob_start(
'gz_handler' )" there is not this problem.
Reproduce code:
---------------
A minimal 304 page :
<?php
header( 'Date: '.gmdate('D, d M Y H:i:s').' GMT' );
header( 'Not Modified', true, 304 );
exit;
?>
A minimal client simulation :
<?php
$sk = fsockopen( 'your-domain.tld', 80 );
$headers = array(
'GET /test_304.php HTTP/1.1',
'Host: your-domain.tld',
'Accept-Encoding: gzip,deflate',
'Keep-Alive: 300',
'Connection: keep-alive',
'If-Modified-Since: Tue, 21 Aug 2007 13:00:54 GMT',
);
function sock_send( &$sk, $line )
{
echo '> ', $line, PHP_EOL;
fputs( $sk, $line . "\r\n" );
}
function sock_gets( &$sk )
{
$line = fgets( $sk, 4096 );
echo '< ', rtrim($line), PHP_EOL;
return $line;
}
for( $i = 1; $i <=2 ; $i++ )
{
echo "Sending request ", $i, PHP_EOL;
foreach( $headers as $h )
sock_send( $sk, $h );
sock_send( $sk, '' );
echo "Reading headers only (no contents should be send)", PHP_EOL;
while( !feof( $sk ) )
{
$line = trim(sock_gets( $sk ));
if( $line === '' )
{
break;
}
}
}
fclose( $sk );
?>
Expected result:
----------------
Response headers for the second request should be the same as the
first.
In my example :
< HTTP/1.1 304 Not Modified
< Date: Tue, 21 Aug 2007 14:45:40 GMT
< Server: Apache/2.2.3 (Debian) PHP/4.4.4-8+etch4
< Connection: Keep-Alive
< Keep-Alive: timeout=60, max=100
< Vary: Accept-Encoding
Actual result:
--------------
Actually there is some "chars" (I suppose the end of compressed data,
like checksum ?)
< ▼ ♥☻ ♥ HTTP/1.1 304 Not
Modified
< Date: Tue, 21 Aug 2007 14:45:40 GMT
< Server: Apache/2.2.3 (Debian) PHP/4.4.4-8+etch4
< Connection: Keep-Alive
< Keep-Alive: timeout=60, max=99
< Vary: Accept-Encoding
<
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=42362&edit=1
