[PHP-DEV] Bug #12022 Updated: limitations of php://stdout
ID: 12022 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Output Control Operating System: linux PHP Version: 4.0.2 New Comment: First update to more recent version before submiting any bug reports. 4.0.2 is just too old. --Jani Previous Comments: [2001-09-09 15:07:16] [EMAIL PROTECTED] incidently, i've used telnet to port 80 to monitor the output of the .php script that feeds the applet, and it's clear that the problem is on the php end. having said that, i have no idea if this is normal 4.0.2 behavior or if it will not be reproduced on other systems. results of these tests are below... # # First using the php://stdout technique, # exactly as suggested by rasmus # telnet artcontext.org 80 Trying 160.79.162.111... Connected to artcontext.org. Escape character is '^]'. GET /act/01/test/makeencoded.php HTTP/1.0 HTTP/1.1 200 OK Date: Sun, 09 Sep 2001 19:21:14 GMT Server: Apache/1.3.12 (Unix) ApacheJServ/1.1.2 PHP/4.0.2 X-Powered-By: PHP/4.0.2 Connection: close Content-Type: application/x-gzip Connection closed by foreign host. # # connection closes, no output # # # next using the readfile technique -- # telnet artcontext.org 80 Trying 160.79.162.111... Connected to artcontext.org. Escape character is '^]'. GET /act/01/test/makeencoded.php HTTP/1.0 HTTP/1.1 200 OK Date: Sun, 09 Sep 2001 19:21:31 GMT Server: Apache/1.3.12 (Unix) ApacheJServ/1.1.2 PHP/4.0.2 X-Powered-By: PHP/4.0.2 Connection: close Content-Type: application/x-gzip (some garbage compression text appears here) [2001-09-09 14:57:45] [EMAIL PROTECTED] in order to demonstrate the problem that i'm experiencing, i've made a small tarball with rasmus's suggestion, and the java applet (simplified) code that accepts the file-based gzip data, but doesn't work with the technique rasmus suggests. since i'm using 4.0.2, i could only try one of his suggestions (there was no gzencode in 4.0.2). andy http://artcontext.org/act/01/test.gz PS successful execution of the applet simply dumps Hello World into the monitor/console. [2001-09-08 20:34:59] [EMAIL PROTECTED] What exactly is the issue here? Why are you trying to open up stdout? You can write gzip data directly without doing that. For example: ? Header(Content-type: application/x-gzip); echo gzencode(Hello World); ? This works just fine. The headers are uncompressed, the content is compressed. I don't see a bug here. stdout only makes sense when running from the command line. Which also works just fine, by the way: ? Header(Content-type: application/x-gzip); $fp = gzopen(php://stdout, w); gzputs ($fp, Hello World); ? which when run from the command line produces: X-Powered-By: PHP/4.0.7-dev Content-type: application/x-gzip óHÍÉÉÏ/ÊIV±J Again, uncompressed headers, compressed data. [2001-09-08 20:16:23] [EMAIL PROTECTED] You may want to wait on closing that bug... ID: 12022 Updated by: sterling Old Status: Open Status: Closed Bug Type: Output Control Operating System: linux New Comment: use the header() function, btw, Perl is not php, gzopen(php://stdout, w) is not the same as the Perl example. With respect to Sterling's suggestion that I use header(), that was of course the _first_ thing that I tried, but it did not work with (my PHP/4.0.2 running on Linux). I'm not sure what point he is trying to make about perl not being php. I'm not a perl fanatic trying to demonstrate the limitations of php, I simply can't do what I want to do with php. if you read the original bug report carefully, you will see that the problem resides in not being able to emit uncompressed headers before the compressed output, at least when using php://stdout. i have no problem when i use the readfile() technique: the headers are uncompressed and the content of the file can be g-zip. andy Previous Comments: [2001-07-10 14:23:04] [EMAIL PROTECTED] With perl cgi I can create a GZIP output stream to a Java applet as follows: print(Content-type: application/x-gzip\n\n); my $gz=gzopen(\*STDOUT, wb) || die(gasp!); however, the same technique seems to be impossible with php://stdout. i realize that i can open a gzip'd stream as follows (note: i am using php 4.02): gzopen(php://stdout,w); however, there seems to be no way to get header fields (uncompressed) to precede the gzip'd output. this presents an unresolvable problem on the browser side, because some
[PHP-DEV] Bug #12022 Updated: limitations of php://stdout
ID: 12022 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Output Control Operating System: linux PHP Version: 4.0.2 New Comment: incidently, i've used telnet to port 80 to monitor the output of the .php script that feeds the applet, and it's clear that the problem is on the php end. having said that, i have no idea if this is normal 4.0.2 behavior or if it will not be reproduced on other systems. results of these tests are below... # # First using the php://stdout technique, # exactly as suggested by rasmus # telnet artcontext.org 80 Trying 160.79.162.111... Connected to artcontext.org. Escape character is '^]'. GET /act/01/test/makeencoded.php HTTP/1.0 HTTP/1.1 200 OK Date: Sun, 09 Sep 2001 19:21:14 GMT Server: Apache/1.3.12 (Unix) ApacheJServ/1.1.2 PHP/4.0.2 X-Powered-By: PHP/4.0.2 Connection: close Content-Type: application/x-gzip Connection closed by foreign host. # # connection closes, no output # # # next using the readfile technique -- # telnet artcontext.org 80 Trying 160.79.162.111... Connected to artcontext.org. Escape character is '^]'. GET /act/01/test/makeencoded.php HTTP/1.0 HTTP/1.1 200 OK Date: Sun, 09 Sep 2001 19:21:31 GMT Server: Apache/1.3.12 (Unix) ApacheJServ/1.1.2 PHP/4.0.2 X-Powered-By: PHP/4.0.2 Connection: close Content-Type: application/x-gzip (some garbage compression text appears here) Previous Comments: [2001-09-09 14:57:45] [EMAIL PROTECTED] in order to demonstrate the problem that i'm experiencing, i've made a small tarball with rasmus's suggestion, and the java applet (simplified) code that accepts the file-based gzip data, but doesn't work with the technique rasmus suggests. since i'm using 4.0.2, i could only try one of his suggestions (there was no gzencode in 4.0.2). andy http://artcontext.org/act/01/test.gz PS successful execution of the applet simply dumps Hello World into the monitor/console. [2001-09-08 20:34:59] [EMAIL PROTECTED] What exactly is the issue here? Why are you trying to open up stdout? You can write gzip data directly without doing that. For example: ? Header(Content-type: application/x-gzip); echo gzencode(Hello World); ? This works just fine. The headers are uncompressed, the content is compressed. I don't see a bug here. stdout only makes sense when running from the command line. Which also works just fine, by the way: ? Header(Content-type: application/x-gzip); $fp = gzopen(php://stdout, w); gzputs ($fp, Hello World); ? which when run from the command line produces: X-Powered-By: PHP/4.0.7-dev Content-type: application/x-gzip óHÍÉÉÏ/ÊIV±J Again, uncompressed headers, compressed data. [2001-09-08 20:16:23] [EMAIL PROTECTED] You may want to wait on closing that bug... ID: 12022 Updated by: sterling Old Status: Open Status: Closed Bug Type: Output Control Operating System: linux New Comment: use the header() function, btw, Perl is not php, gzopen(php://stdout, w) is not the same as the Perl example. With respect to Sterling's suggestion that I use header(), that was of course the _first_ thing that I tried, but it did not work with (my PHP/4.0.2 running on Linux). I'm not sure what point he is trying to make about perl not being php. I'm not a perl fanatic trying to demonstrate the limitations of php, I simply can't do what I want to do with php. if you read the original bug report carefully, you will see that the problem resides in not being able to emit uncompressed headers before the compressed output, at least when using php://stdout. i have no problem when i use the readfile() technique: the headers are uncompressed and the content of the file can be g-zip. andy Previous Comments: [2001-07-10 14:23:04] [EMAIL PROTECTED] With perl cgi I can create a GZIP output stream to a Java applet as follows: print(Content-type: application/x-gzip\n\n); my $gz=gzopen(\*STDOUT, wb) || die(gasp!); however, the same technique seems to be impossible with php://stdout. i realize that i can open a gzip'd stream as follows (note: i am using php 4.02): gzopen(php://stdout,w); however, there seems to be no way to get header fields (uncompressed) to precede the gzip'd output. this presents an unresolvable problem on the browser side, because some browsers will assume that no data has been sent if no header fields are received. can the php://stdout mechanism be changed to allow me to print uncompressed lines to stdout before the compressed output begins? am i missing
[PHP-DEV] Bug #12022 Updated: limitations of php://stdout
ID: 12022 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Closed Status: Open Bug Type: Output Control Operating System: linux Old PHP Version: 4.0.6 PHP Version: 4.0.2 New Comment: You may want to wait on closing that bug... ID: 12022 Updated by: sterling Old Status: Open Status: Closed Bug Type: Output Control Operating System: linux New Comment: use the header() function, btw, Perl is not php, gzopen(php://stdout, w) is not the same as the Perl example. With respect to Sterling's suggestion that I use header(), that was of course the _first_ thing that I tried, but it did not work with (my PHP/4.0.2 running on Linux). I'm not sure what point he is trying to make about perl not being php. I'm not a perl fanatic trying to demonstrate the limitations of php, I simply can't do what I want to do with php. if you read the original bug report carefully, you will see that the problem resides in not being able to emit uncompressed headers before the compressed output, at least when using php://stdout. i have no problem when i use the readfile() technique: the headers are uncompressed and the content of the file can be g-zip. andy Previous Comments: [2001-07-10 14:23:04] [EMAIL PROTECTED] With perl cgi I can create a GZIP output stream to a Java applet as follows: print(Content-type: application/x-gzip\n\n); my $gz=gzopen(\*STDOUT, wb) || die(gasp!); however, the same technique seems to be impossible with php://stdout. i realize that i can open a gzip'd stream as follows (note: i am using php 4.02): gzopen(php://stdout,w); however, there seems to be no way to get header fields (uncompressed) to precede the gzip'd output. this presents an unresolvable problem on the browser side, because some browsers will assume that no data has been sent if no header fields are received. can the php://stdout mechanism be changed to allow me to print uncompressed lines to stdout before the compressed output begins? am i missing something here? i realize that i can put zipped data into a file and use readfile() to send it, and this actually does send all the header fields as would be expected. however, this will cause me unnecessary drive activity because i will have to modify the files, which i had not wanted to do. Previous Comments: [2001-09-06 23:21:57] [EMAIL PROTECTED] use the header() function, btw, Perl is not php, gzopen(php://stdout, w) is not the same as the Perl example. [2001-07-10 14:23:04] [EMAIL PROTECTED] With perl cgi I can create a GZIP output stream to a Java applet as follows: print(Content-type: application/x-gzip\n\n); my $gz=gzopen(\*STDOUT, wb) || die(gasp!); however, the same technique seems to be impossible with php://stdout. i realize that i can open a gzip'd stream as follows (note: i am using php 4.02): gzopen(php://stdout,w); however, there seems to be no way to get header fields (uncompressed) to precede the gzip'd output. this presents an unresolvable problem on the browser side, because some browsers will assume that no data has been sent if no header fields are received. can the php://stdout mechanism be changed to allow me to print uncompressed lines to stdout before the compressed output begins? am i missing something here? i realize that i can put zipped data into a file and use readfile() to send it, and this actually does send all the header fields as would be expected. however, this will cause me unnecessary drive activity because i will have to modify the files, which i had not wanted to do. Edit this bug report at http://bugs.php.net/?id=12022edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12022 Updated: limitations of php://stdout
ID: 12022 Updated by: rasmus Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Output Control Operating System: linux PHP Version: 4.0.2 New Comment: What exactly is the issue here? Why are you trying to open up stdout? You can write gzip data directly without doing that. For example: ? Header(Content-type: application/x-gzip); echo gzencode(Hello World); ? This works just fine. The headers are uncompressed, the content is compressed. I don't see a bug here. stdout only makes sense when running from the command line. Which also works just fine, by the way: ? Header(Content-type: application/x-gzip); $fp = gzopen(php://stdout, w); gzputs ($fp, Hello World); ? which when run from the command line produces: X-Powered-By: PHP/4.0.7-dev Content-type: application/x-gzip óHÍÉÉÏ/ÊIV±J Again, uncompressed headers, compressed data. Previous Comments: [2001-09-08 20:16:23] [EMAIL PROTECTED] You may want to wait on closing that bug... ID: 12022 Updated by: sterling Old Status: Open Status: Closed Bug Type: Output Control Operating System: linux New Comment: use the header() function, btw, Perl is not php, gzopen(php://stdout, w) is not the same as the Perl example. With respect to Sterling's suggestion that I use header(), that was of course the _first_ thing that I tried, but it did not work with (my PHP/4.0.2 running on Linux). I'm not sure what point he is trying to make about perl not being php. I'm not a perl fanatic trying to demonstrate the limitations of php, I simply can't do what I want to do with php. if you read the original bug report carefully, you will see that the problem resides in not being able to emit uncompressed headers before the compressed output, at least when using php://stdout. i have no problem when i use the readfile() technique: the headers are uncompressed and the content of the file can be g-zip. andy Previous Comments: [2001-07-10 14:23:04] [EMAIL PROTECTED] With perl cgi I can create a GZIP output stream to a Java applet as follows: print(Content-type: application/x-gzip\n\n); my $gz=gzopen(\*STDOUT, wb) || die(gasp!); however, the same technique seems to be impossible with php://stdout. i realize that i can open a gzip'd stream as follows (note: i am using php 4.02): gzopen(php://stdout,w); however, there seems to be no way to get header fields (uncompressed) to precede the gzip'd output. this presents an unresolvable problem on the browser side, because some browsers will assume that no data has been sent if no header fields are received. can the php://stdout mechanism be changed to allow me to print uncompressed lines to stdout before the compressed output begins? am i missing something here? i realize that i can put zipped data into a file and use readfile() to send it, and this actually does send all the header fields as would be expected. however, this will cause me unnecessary drive activity because i will have to modify the files, which i had not wanted to do. [2001-09-06 23:21:57] [EMAIL PROTECTED] use the header() function, btw, Perl is not php, gzopen(php://stdout, w) is not the same as the Perl example. [2001-07-10 14:23:04] [EMAIL PROTECTED] With perl cgi I can create a GZIP output stream to a Java applet as follows: print(Content-type: application/x-gzip\n\n); my $gz=gzopen(\*STDOUT, wb) || die(gasp!); however, the same technique seems to be impossible with php://stdout. i realize that i can open a gzip'd stream as follows (note: i am using php 4.02): gzopen(php://stdout,w); however, there seems to be no way to get header fields (uncompressed) to precede the gzip'd output. this presents an unresolvable problem on the browser side, because some browsers will assume that no data has been sent if no header fields are received. can the php://stdout mechanism be changed to allow me to print uncompressed lines to stdout before the compressed output begins? am i missing something here? i realize that i can put zipped data into a file and use readfile() to send it, and this actually does send all the header fields as would be expected. however, this will cause me unnecessary drive activity because i will have to modify the files, which i had not wanted to do. Edit this bug report at http://bugs.php.net/?id=12022edit=1 -- PHP Development Mailing List http://www.php.net/
[PHP-DEV] Bug #12022 Updated: limitations of php://stdout
ID: 12022 Updated by: sterling Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Output Control Operating System: linux PHP Version: 4.0.6 New Comment: use the header() function, btw, Perl is not php, gzopen(php://stdout, w) is not the same as the Perl example. Previous Comments: [2001-07-10 14:23:04] [EMAIL PROTECTED] With perl cgi I can create a GZIP output stream to a Java applet as follows: print(Content-type: application/x-gzip\n\n); my $gz=gzopen(\*STDOUT, wb) || die(gasp!); however, the same technique seems to be impossible with php://stdout. i realize that i can open a gzip'd stream as follows (note: i am using php 4.02): gzopen(php://stdout,w); however, there seems to be no way to get header fields (uncompressed) to precede the gzip'd output. this presents an unresolvable problem on the browser side, because some browsers will assume that no data has been sent if no header fields are received. can the php://stdout mechanism be changed to allow me to print uncompressed lines to stdout before the compressed output begins? am i missing something here? i realize that i can put zipped data into a file and use readfile() to send it, and this actually does send all the header fields as would be expected. however, this will cause me unnecessary drive activity because i will have to modify the files, which i had not wanted to do. Edit this bug report at http://bugs.php.net/?id=12022edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]