Bug #34071 [Com]: buffering is destroyed when using ob_gzhandler and ob_clean
Edit report at http://bugs.php.net/bug.php?id=34071&edit=1 ID: 34071 Comment by: arvenil at klecza dot pl Reported by:dennis at nocertainty dot com Summary:buffering is destroyed when using ob_gzhandler and ob_clean Status: No Feedback Type: Bug Package:Output Control Operating System: Windows XP SP2 PHP Version:5CVS-2005-08-10 (dev) Block user comment: N Private report: N New Comment: You can't change your mind about compression in half way however you can still kill that buffer and send other. Previous Comments: [2006-01-27 16:32:58] greg at xdissent dot com this appears to be ob_gzhandler's fault. it seems to send the content-encoding: gzip header even if ob_end_clean or similar is called which produces no output. that means that if you use ob_gzhandler and then change your mind about compression and need to kill that buffer, you're out of luck. in the following small example, "output" WILL be printed in plaintext but will be misinterpreted by the browser as gzipped content. you can use telnet to better view the situation because it will almost always result in a white browser window. as others have pointed out, you have to use the accept-encoding to trigger ob_gzhandler's compression: $ telnet localhost 80 GET /ob_test.php HTTP/1.1 Host: localhost Accept-Encoding: gzip,deflate now, should ob_gzhandler really be sending the header if the buffer is ended without outputting anything? should it maybe check the length of the buffer when it is closed to determine whether or not the content-encoding header should be sent? [2005-08-19 01:00:06] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-08-14 23:10:12] dehstil at gmail dot com I've reproduced the bug. I've been wondering why my script wouldn't run until I saw this bug. I'm using apache server on win xp with php 4 as a module. The above code produced the bug: With further debuging this doesn't work either: I noticed that the content-length in my headers was non-zero so I tried this and lo and behold: I realized the bug is sending bad gz binary but for some reason the following code did work...: To my surprise, this didn't, thus confusing me: I'll be looking for the source on cvs and report back to ya! [2005-08-11 23:12:45] sni...@php.net 1) Check your php.ini settings (how they differ to whatever you used as base for your php.ini, -dist or -recommended) 2) Set error_reporting to E_ALL and try again.. [2005-08-11 20:54:56] dennis at nocertainty dot com I found someone else who has the same problem as me: http://www.sitepoint.com/forums/showpost.php?p=2093119&postcount=5 However, I can't find any specific information. I looked through my Apache error log, and the only thing I found was: [Wed Aug 10 18:59:56 2005] [error] [client 127.0.0.1] request failed: erroneous characters after protocol string: \\xff\\xfb\\x1f\\xff\\xfb \\xff\\xfb\\x18\\xff\\xfb'\\xff\\xfd\\x01\\xff\\xfb\\x03\\xff\\xfd\\x03GET /gzip2.php HTTP/1.0 [Wed Aug 10 19:00:21 2005] [error] [client 127.0.0.1] request failed: erroneous characters after protocol string: \\xff\\xfb\\x1f\\xff\\xfb \\xff\\xfb\\x18\\xff\\xfb'\\xff\\xfd\\x01\\xff\\xfb\\x03\\xff\\xfd\\x03GET /gzip2.php HTTP/1.0 But I'm not sure if that's entirely relevant. But there's nothing more that's related to it. 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/bug.php?id=34071 -- Edit this bug report at http://bugs.php.net/bug.php?id=34071&edit=1
#34071 [Com]: buffering is destroyed when using ob_gzhandler and ob_clean
ID: 34071 Comment by: greg at xdissent dot com Reported By: dennis at nocertainty dot com Status: No Feedback Bug Type: Output Control Operating System: Windows XP SP2 PHP Version: 5CVS-2005-08-10 (dev) New Comment: this appears to be ob_gzhandler's fault. it seems to send the content-encoding: gzip header even if ob_end_clean or similar is called which produces no output. that means that if you use ob_gzhandler and then change your mind about compression and need to kill that buffer, you're out of luck. in the following small example, "output" WILL be printed in plaintext but will be misinterpreted by the browser as gzipped content. you can use telnet to better view the situation because it will almost always result in a white browser window. as others have pointed out, you have to use the accept-encoding to trigger ob_gzhandler's compression: $ telnet localhost 80 GET /ob_test.php HTTP/1.1 Host: localhost Accept-Encoding: gzip,deflate now, should ob_gzhandler really be sending the header if the buffer is ended without outputting anything? should it maybe check the length of the buffer when it is closed to determine whether or not the content-encoding header should be sent? Previous Comments: [2005-08-19 01:00:06] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-08-14 23:10:12] dehstil at gmail dot com I've reproduced the bug. I've been wondering why my script wouldn't run until I saw this bug. I'm using apache server on win xp with php 4 as a module. The above code produced the bug: With further debuging this doesn't work either: I noticed that the content-length in my headers was non-zero so I tried this and lo and behold: I realized the bug is sending bad gz binary but for some reason the following code did work...: To my surprise, this didn't, thus confusing me: I'll be looking for the source on cvs and report back to ya! [2005-08-11 23:12:45] [EMAIL PROTECTED] 1) Check your php.ini settings (how they differ to whatever you used as base for your php.ini, -dist or -recommended) 2) Set error_reporting to E_ALL and try again.. [2005-08-11 20:54:56] dennis at nocertainty dot com I found someone else who has the same problem as me: http://www.sitepoint.com/forums/showpost.php?p=2093119&postcount=5 However, I can't find any specific information. I looked through my Apache error log, and the only thing I found was: [Wed Aug 10 18:59:56 2005] [error] [client 127.0.0.1] request failed: erroneous characters after protocol string: \\xff\\xfb\\x1f\\xff\\xfb \\xff\\xfb\\x18\\xff\\xfb'\\xff\\xfd\\x01\\xff\\xfb\\x03\\xff\\xfd\\x03GET /gzip2.php HTTP/1.0 [Wed Aug 10 19:00:21 2005] [error] [client 127.0.0.1] request failed: erroneous characters after protocol string: \\xff\\xfb\\x1f\\xff\\xfb \\xff\\xfb\\x18\\xff\\xfb'\\xff\\xfd\\x01\\xff\\xfb\\x03\\xff\\xfd\\x03GET /gzip2.php HTTP/1.0 But I'm not sure if that's entirely relevant. But there's nothing more that's related to it. [2005-08-10 20:12:21] [EMAIL PROTECTED] Then provide more info about it; look into the apache logs; try on another server and with another PHP version etc etc. As I've already said, it works perfectly here. 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/34071 -- Edit this bug report at http://bugs.php.net/?id=34071&edit=1
#34071 [Com]: buffering is destroyed when using ob_gzhandler and ob_clean
ID: 34071 Comment by: dehstil at gmail dot com Reported By: dennis at nocertainty dot com Status: Feedback Bug Type: Output Control Operating System: Windows XP SP2 PHP Version: 5CVS-2005-08-10 (dev) New Comment: I've reproduced the bug. I've been wondering why my script wouldn't run until I saw this bug. I'm using apache server on win xp with php 4 as a module. The above code produced the bug: With further debuging this doesn't work either: I noticed that the content-length in my headers was non-zero so I tried this and lo and behold: I realized the bug is sending bad gz binary but for some reason the following code did work...: To my surprise, this didn't, thus confusing me: I'll be looking for the source on cvs and report back to ya! Previous Comments: [2005-08-11 23:12:45] [EMAIL PROTECTED] 1) Check your php.ini settings (how they differ to whatever you used as base for your php.ini, -dist or -recommended) 2) Set error_reporting to E_ALL and try again.. [2005-08-11 20:54:56] dennis at nocertainty dot com I found someone else who has the same problem as me: http://www.sitepoint.com/forums/showpost.php?p=2093119&postcount=5 However, I can't find any specific information. I looked through my Apache error log, and the only thing I found was: [Wed Aug 10 18:59:56 2005] [error] [client 127.0.0.1] request failed: erroneous characters after protocol string: \\xff\\xfb\\x1f\\xff\\xfb \\xff\\xfb\\x18\\xff\\xfb'\\xff\\xfd\\x01\\xff\\xfb\\x03\\xff\\xfd\\x03GET /gzip2.php HTTP/1.0 [Wed Aug 10 19:00:21 2005] [error] [client 127.0.0.1] request failed: erroneous characters after protocol string: \\xff\\xfb\\x1f\\xff\\xfb \\xff\\xfb\\x18\\xff\\xfb'\\xff\\xfd\\x01\\xff\\xfb\\x03\\xff\\xfd\\x03GET /gzip2.php HTTP/1.0 But I'm not sure if that's entirely relevant. But there's nothing more that's related to it. [2005-08-10 20:12:21] [EMAIL PROTECTED] Then provide more info about it; look into the apache logs; try on another server and with another PHP version etc etc. As I've already said, it works perfectly here. [2005-08-10 19:47:05] dennis at nocertainty dot com Also, I disabled PHP4 in my http.conf file, and it still doesn't work properly in PHP5Dev. So I still believe there's a bug in PHP5. [2005-08-10 19:44:50] dennis at nocertainty dot com Rasmus is right. The telnet thing works because ob_gzhandler doesn't do anything. As soon as a specify a Content-Encoding: gzip header, nothing gets displayed again. So it's not my browser that's causing the problem. 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/34071 -- Edit this bug report at http://bugs.php.net/?id=34071&edit=1
