Bug #12022 Updated: limitations of php://stdout

ID: 12022 User updated by: noisefactor@netscape.net Reported By: noisefactor@netscape.net 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] noisefactor@netscape.net > >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] sterling@php.net 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] noisefactor@netscape.net 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=12022&edit=1