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

go to bug id or search bugs for

Bug #23753 ob_gzhandler and IE problem
Submitted: 2003-05-22 09:11 UTC Modified: 2003-05-27 14:51 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: admin at sportsandbytes dot de Assigned:
Status: Not a bug Package: Zlib related
PHP Version: 4.3.3-dev OS: redhat linux 7.2
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: admin at sportsandbytes dot de
New email:
PHP Version: OS:

 

 [2003-05-22 09:11 UTC] admin at sportsandbytes dot de 
Following Problem: 
 
After upgrading from apache1.3.26/php4.2.2 to apache1.3.27/php4.3.1 
we noticed a problem with 2 of our pages. 
 
Background: 
We use ob_gzhandler to compress pages, wich before the upgrade 
worked fine. After the upgrade 2 of several 100 pages didnt display in 
IE/win anymore. Problem disappears of ob_gzhandler is not used. 
Other Browsers (mozilla/konqui/ie on mac/safari) didnt show this 
problem. Subsequent downgrade made problem dissapear. 
 
switching to zlib_output_compression = on with set_ini() calls 
adjusting zlib.output_compression_level from within the script works 
fine too. 
 
the code in question goes like this 
               
	       . 
               . 
               . 
               //build $this->pageSource 
               . 
               . 
               . 
               ob_start("ob_gzhandler"); 
               echo $this->pageSource; 
               ob_end_flush(); 
 
 
Getting the afflicted pages with wget sending appropriate headers and 
such gives me a nicely compressed page. 
Uncompressing the downloaded page with gzip shows gzip 
complaining about 'trailing grabage' wich it ignores. 
The uncompressed page afterwards looks just like expected in IE. 
 
This leads me to the assumption that the 'trailing garbage' is the 
problem and does not in fact get ignored by IE

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-05-22 12:55 UTC] camarcos at ache dot com dot br 
Hello, my problem is equal....

Help-me too....

Marcos Chibly
camarcos@ache.com.br
 [2003-05-22 16:16 UTC] sniper@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
 [2003-05-23 09:17 UTC] admin at sportsandbytes dot de 
With http://snaps.php.net/php4-STABLE-latest.tar.gz 
instead of 4.3.1 Problem is not resolved 
 
additionally the 'workaround' of using 
zlib_output_compression via alter_ini() for 
zlib.output_compression_level from inside script doesent work 
anymore either
 [2003-05-23 09:23 UTC] admin at sportsandbytes dot de 
Correction 
 
problem not fixed, 
 
BUT the zlib.output_compression_level thing of course still 
works 
must have messed up checking the first time around
 [2003-05-23 09:45 UTC] admin at sportsandbytes dot de 
Additional Info: 
getting the affected page via wget again and unzipping with 
gunzip shows no problem with 'trailing garbage' anymore, but 
still IE/win does not display page when ob_gzhandler is used
 [2003-05-23 10:29 UTC] sniper@php.net 
This works fine with any other browser?
What IE version is it? Have you tried older ones?
Are you absolutely sure that with older PHP but with the exactly same IE version this worked?
 [2003-05-26 09:59 UTC] admin at sportsandbytes dot de 
Yes, it works fine with konqueror3.1, safari, mozilla, phoenix, ie/mac 
but not with ie/win 5.5 and 6, unfortunatly i dont have acess to 
anything older than 5.5 
 
it works fine with php4.2.2/apache1.3.26 but not with either 
1.3.27/4.3.1 or 1.3.27/4.3.3-dev 
 
while with 4.3.1 a affected page got with wget make gunzip complain 
about trailing grabage this does not happen with 4.3.3-dev 
but in both cases IE will not display the affected pages. 
 
if you like i can set up an affected instance on a public IP for you to 
look at
 [2003-05-27 03:15 UTC] sniper@php.net 
Please put that page up somewhere..
 [2003-05-27 14:51 UTC] sniper@php.net 
This is really an IE bug, see for example this:

http://lists.over.net/pipermail/mod_gzip/2002-October/006587.html

Also, zlib.output_compression is the preferred way to handle
this in PHP anyway..
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Oct 24 02:00:01 2025 UTC