php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #34240 zlib.output_compression=on responsing corrupted data
Submitted: 2005-08-24 21:05 UTC Modified: 2005-09-02 19:25 UTC
From: xuefer at 21cn dot com Assigned: iliaa (profile)
Status: Closed Package: Zlib related
PHP Version: 5CVS, 6CVS, 4CVS (2005-08-25) OS: *
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: xuefer at 21cn dot com
New email:
PHP Version: OS:

 

 [2005-08-24 21:05 UTC] xuefer at 21cn dot com 
Description:
------------
fix to bugs@34191 broken 2 echos
sapi: fastcgi
zlib.output_compression = On
turn off=no problem
revert the fix=no problem too

can llia please look into it?

Reproduce code:
---------------
<?php
echo 1;
echo 2;
?>


Expected result:
----------------
12

Actual result:
--------------
empty page in browser (corrupted gzip data)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-08-24 21:14 UTC] iliaa@php.net 
Can you replicate in any other SAPI, I don't have fastcgi sapi  installed anywhere.
 [2005-08-30 13:23 UTC] sniper@php.net 
It doesn't make any difference with/without the patch for bug    #34191 (so I don't think it really broke anything)

Try with the shortest possible configure line:
# ./configure --disable-all --disable-cli --with-zlib
 [2005-08-31 14:39 UTC] xuefer at 21cn dot com 
confirmed with ./configure --disable-all --disable-cli --with-zlib
both with cgi and fastcgi

good:
HTTP_ACCEPT_ENCODING=gzip php-cgi test.php |md5sum
826a819e34f7d57597d890de4176c265  -
bad:
HTTP_ACCEPT_ENCODING=gzip php-cgi test.php |md5sum
2e7dc64cd654b82f712b47b790dcbc12  -


(gdb) br 720
Breakpoint 2 at 0x805d6e5: file /home/xuefer/src/php4/ext/zlib/zlib.c, line 720.
(gdb) r
#0  php_do_deflate (str_length=2, p_buffer=0xbffff028, p_buffer_len=0xbffff02c, do_start=1 '\001', do_end=1 '\001')
    at /home/xuefer/src/php4/ext/zlib/zlib.c:720
(gdb) p outlen-zlib_globals.stream.avail_out
$8 = 10
(gdb) p buffer[outlen-zlib_globals.stream.avail_out]
$9 = 50 '2'
(gdb) step
724     *p_buffer = buffer;
(gdb) p buffer[outlen-zlib_globals.stream.avail_out]
$10 = 0 '\0'

the 2 is exactly what i see in httpwatch that get "lost" with the patch applied

test result by php->lighttpd->httpwatch is at:
ftp://211.92.88.40/pub/phpbug/test.php.response.txt
ftp://211.92.88.40/pub/phpbug/test.php.response-corrupted.txt
 [2005-09-01 03:00 UTC] iliaa@php.net 
I've tried to replicate the bug using given methodology and removing the \0 line has absolutely no affect (md5 is the same) on the generated output.
 [2005-09-01 06:23 UTC] xuefer at 21cn dot com 
i'd guess the "start_offset" is to avoid an extra erealloc. 
this bug should only happen when both do_start do_end is true (do_end=true && start_offset!=0)

 /* {{{ php_do_deflate
@@ -717,7 +718,7 @@
 
    if (do_end) {
        err = deflate(&ZLIBG(stream), Z_FINISH);
-       buffer[outlen - ZLIBG(stream).avail_out] = '\0';
+       buffer[outlen + start_offset - ZLIBG(stream).avail_out] = '\0';
    }
 [2005-09-02 19:25 UTC] iliaa@php.net 
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Mon Dec 30 14:01:28 2024 UTC