ID:               21139
 Comment by:       selfman at netax dot sk
 Reported By:      [EMAIL PROTECTED]
 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] [EMAIL PROTECTED]

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] [EMAIL PROTECTED]

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] [EMAIL PROTECTED]

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] [EMAIL PROTECTED]

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

Reply via email to