PHP 4.3.4 omits content-encoding gzip header with zlib.output_compression on (xs4)

Hi there everyone, since upgrading to 4.3.4, I have a problem with the zlib.output_compression feature in PHP. In effect, I cannot use this feature as I get binary output in my browser (tested with both Mozilla and IE6). It seems the only way I can let PHP generate gzip encoded output is using the ob_gzhandler in php.ini. The scripts I use do not contain ob_start() functions, etc. The problem also occurs with the standard phpinfo() 'script'. From phpinfo(), I can see my php.ini file is read correctly (yes, I checked the FAQ). Starting point for my php.ini file is the php 4.3.4 php.ini-recommended settings file. More system information is included at the bottom of this message. When I try the following setup in php.ini: output_handler = zlib.output_compression = on zlib.output_handler = I get garbled, binary data in my browser. Inspecting the HTTP headers (in Mozilla), I see both the "Vary: Content-encoding" and "Content-encoding: gzip" headers are not present. Experience with other gzip modules (such as apache's mod_gzip) suggests these headers should be present. I suspect PHP correctly generates gzip-encoded output, yet does not include the correct headers. In older PHP versions (4.3.2, 4.3.3) I had no such trouble. The problem occurs on both Apache 1.3.29 and 2.0.48 starting with PHP version 4.3.4. As a workaround, I now use the following setup in php.ini: output_handler = ob_gzhandler zlib.output_compression = off zlib.output_handler = This works correctly, sending gzip-encoded output using the correct headers. Compression is active (and effective, clearly visible checking the page size for phpinfo()). My only problem with this workaround, is that I now have several scripts that no longer correctly generate CSV and/or PDF files for IE clients. As crappy as some may find IE, I'm afraid I cannot work arround that browser, which is why I would like to use the former setup. I know the CSV/PDF generating scripts should never trust the site-wide output handlers, but this seems to be a problem of PHP as well. Can anyone reproduce this to see whether this is a setup problem or worthy of a bug report? Thanks in advance, Rogier Krieger Tested systems: Apache 1.3.29 as well as 2.0.48 NetBSD 1.6.1 as well as FreeBSD 4.8 PHP 4.3.4 with modules: + zlib, gettext, gd, domxml, xslt, pdflib, + openssl, mcrypt, mhash, + sockets, snmp, ftp, imap, + pgsql, mysql and ldap PHP configurations are similar on all 3 machines. My php.ini for NetBSD/apache2: [ http://www.iverdahl.net/pub/php.ini ]