|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: xuefer at 21cn dot com
New email:
PHP Version: OS:


 [2005-08-24 21:05 UTC] xuefer at 21cn dot com
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:
echo 1;
echo 2;

Expected result:

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


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2005-08-24 21:14 UTC]
Can you replicate in any other SAPI, I don't have fastcgi sapi  installed anywhere.
 [2005-08-30 13:23 UTC]
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

HTTP_ACCEPT_ENCODING=gzip php-cgi test.php |md5sum
826a819e34f7d57597d890de4176c265  -
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
$8 = 10
(gdb) p buffer[]
$9 = 50 '2'
(gdb) step
724     *p_buffer = buffer;
(gdb) p buffer[]
$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:
 [2005-09-01 03:00 UTC]
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]
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
Thank you for the report, and for helping us make PHP better.

PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Jul 13 08:01:29 2024 UTC