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 back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
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-2025 The PHP Group
All rights reserved. 		Last updated: Mon Oct 27 04:00:02 2025 UTC