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

go to bug id or search bugs for

Bug #36514 ob_gzhandler() issue
Submitted: 2006-02-24 14:31 UTC Modified: 2012-03-16 09:27 UTC
Votes:10
Avg. Score:2.9 ± 0.7
Reproduced:6 of 7 (85.7%)
Same Version:1 (16.7%)
Same OS:1 (16.7%)
From: lunter at interia dot pl Assigned: mike (profile)
Status: No Feedback Package: Output Control
PHP Version: 5.1.2 OS: winXP
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: lunter at interia dot pl
New email:
PHP Version: OS:

 

 [2006-02-24 14:31 UTC] lunter at interia dot pl 
Description:
------------
ob_gzhandler() issue

Reproduce code:
---------------
// script 1
<?
 ob_start('ob_gzhandler');
 print(str_repeat('a',5));
 ob_clean();
 print(str_repeat('b',5));
 ob_end_flush();
?>

// script 2
<?
 ob_start();
 print(str_repeat('a',5));
 ob_clean();
 print(str_repeat('b',5));
 ob_end_flush();
?>

Expected result:
----------------
Script 1 (using compression) output from buffer to browser: "bbbbb" like Script 2 output from buffer to browser: "bbbbb"

Actual result:
--------------
Script 1 (using compression) output from buffer to browser incorect data...

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-02-24 14:35 UTC] lunter at interia dot pl 
PS. Please note that ob_clean() function does not destroy the output buffer, but only clean (erase) the output buffer.
http://pl2.php.net/manual/en/function.ob-clean.php
 [2006-02-25 23:04 UTC] mike@php.net 
ob_clean() restarts the gz handler.
 [2006-02-26 17:22 UTC] mike@php.net 
Ok, seems to be as follows:

ob_clean() discards the gzip header bytes, but doesn't cause the gz handler to restart.
 [2006-05-24 11:51 UTC] mike@php.net 
Cannot be fixed with current Output Control code.
 [2009-08-18 14:56 UTC] jani@php.net 
Need to investigate if this is a) fixed in HEAD by the new output code (or fix it if not) and b) if it's actually fixable somehow in 5.* branches.
 [2010-06-18 22:43 UTC] jani@php.net
-Assigned To: jani +Assigned To: mike
 [2010-06-18 22:43 UTC] jani@php.net 
Assigned to someone who cares.
 [2010-12-10 16:46 UTC] roan dot kattouw at gmail dot com 
I've analyzed the output of a similar test case (ob_clean() before any output, to clear any warnings) in a hex editor and compared it to gzip -c 's output for the same input. It's quite clear that the ob_gzhandler output is missing the gzip header but is otherwise similar (identical except for the occasional 4-byte block, I'm guessing those are checksums or something). So Mark would seem to be right that the GZIP header gets thrown out by ob_clean() and doesn't come back.
 [2011-09-19 14:40 UTC] mike@php.net
-Status: Assigned +Status: Feedback
 [2011-09-19 14:40 UTC] mike@php.net 
Please try using this snapshot:

  http://snaps.php.net/php5.4-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/
 [2012-03-16 09:27 UTC] mike@php.net
-Status: Feedback +Status: No Feedback
 [2012-03-16 09:27 UTC] mike@php.net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
 [2020-02-16 23:20 UTC] john dot nicholls at eagleeye dot com 
The test cases already provided remain valid.

Using PHP 5.6.40 on CentOS Linux release 7.7.1908 (Core), we experience the same issue.

It has proven possible however, to work around the bug by using a second level of output buffering:

// script 3
<?
 ob_start('ob_gzhandler');
 ob_start();
 print(str_repeat('a',5));
 ob_end_clean();
 print(str_repeat('b',5));
 ob_end_flush();
?>
 
PHP Copyright © 2001-2026 The PHP Group
All rights reserved. 		Last updated: Fri Feb 06 03:00:02 2026 UTC