#21139 [Com]: zlib.output_compression + windows failure

ID: 21139 Comment by: selfman at netax dot sk Reported By: helly@php.net Status: Closed Bug Type: Output Control Operating System: Windows PHP Version: 4.3.0RC4 New Comment: I can confirm the output_compression=on bug. The strange stuff is hat it reappeared in PHP 4.3.3 an 4.3.4RC2. I had the same problem by using IIS5 and Apache 1.3.29 on Windows 2000 Server. Behaviour: - page request sent - answer from server arrived - browser discarded old content - blank page and nothing more after reload, the content appeared. I've tried that several times on the site. Same results. Headers sent, zipped content is there but nothing is displayed. Must be a problem with headers. By turning of the output_compression=off everything works. Regards SelfMan Previous Comments: ------------------------------------------------------------------------ [2002-12-26 07:42:05] edink@php.net This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. ZLIB extension is now built in on Windows which solves this problem. ------------------------------------------------------------------------ [2002-12-23 07:48:12] alexws at hotmail dot ru I confirm the presence of this bug since PHP 4.3.0RC2. PHP 4.3.0RC1 works! It is appearing either when zlib compression is toggled in php.ini or .htaccess. Looks like header problem, 'cause returned file can really be decoded. OS tested: Windows 98, Windows 2000, Windows XP PHP tested: PHP 4.3.0 RC2, RC3, RC4 Server software tested: IIS 4.0, IIS 5.0, Apache 1.3, Apache 2.0 All of the tests confirm buggy behavior. Please investigate. ------------------------------------------------------------------------ [2002-12-22 18:41:58] moriyoshi@php.net During investigation, I found another odd behaviour when zlib.output_compression is toggled up by .htaccess. HTTP response headers which are automatically appended by Apache, such as ETag, Accept-Ranges, and Content-Length are supposed to be removed on sapi activation, and they are actually removed in the very first request to the server, but from the second request they persistently appear again. ------------------------------------------------------------------------ [2002-12-22 12:14:53] moriyoshi@php.net Verified on Windows, with Apache or Apache2. -- HTTP response dump of the following script -- <?php echo "abcde"; ?> -- Apache_1.3.27 -- HTTP/1.1 200 OK Date: Sun, 22 Dec 2002 18:06:53 GMT Server: Apache/1.3.27 (Win32) PHP/4.4.0-dev X-Powered-By: PHP/4.4.0-dev Connection: close Content-Type: text/html (correctly gzip-encoded content) -- Apache_2.0.43 -- HTTP/1.1 200 OK Date: Sun, 22 Dec 2002 18:06:15 GMT Server: Apache/2.0.43 (Win32) PHP/4.4.0-dev Last-Modified: Sun, 22 Dec 2002 17:59:26 GMT ETag: "45a2-1b-e744bab1" Accept-Ranges: bytes Content-Length: 27 Connection: close Content-Type: application/x-httpd-php <br /> <b>Warning</b>: (null)() [<a href='http://www.php.net/ref.outcontrol'>ref.outcontrol</a>]: Cannot change zlib.output_compression - headers already sent in <b>Unknown</b> on line <b>0</b><br /> abcde ------------------------------------------------------------------------ [2002-12-21 19:27:53] edink@php.net I can confirm this bug on Windows + Apache + zlib.output_compression in .htaccess. If zlib.output_compression is set to on from php.ini it works. It only doesn't work if set from .htaccess. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/21139 -- Edit this bug report at http://bugs.php.net/?id=21139&edit=1