Re: [PHP-DEV] Output Compression Issues
On Wed, 15 Aug 2001, Rasmus Lerdorf wrote: But a second call to Header(Content-Encoding:) will replace the first one. If no content has gone out yet, overwriting a previous Content-Encoding header is trivial. I am not sure what you mean when you say that this doesn't do the job for some browsers. Do they not like a blank content-encoding header? It's not like you end up sending two content-encoding headers. Yea, we tried, it looks like some defaults are assumed if an empty Content-Encoding header is present. I'll have to confirm this tomorrow. We could add some sort of UnHeader() function which calls Apache's ap_table_unset() function, but I am not sure if other SAPI backends have support for this. That would probably have a lot of uses, and would solve our problem. Still, semantically, it seems like when output buffering is aborted with an ob_end_clean(), the headers that ob_gzhandler sets should be as well, although I guess that's rather difficult if people start writing their own output buffering handlers.. John -- 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] Output Compression Issues
We've run into some trouble with output compression, specifically when using PHP to generate PDF's, and send them directly to the browser with an overridden mime-type. It appears as though the browser support for this is rather lame; even recent versions of Netscape hand Acrobat the compressed version of the PDF, and Acrobat chokes, really badly. Some relatively recent versions of IE also have problems dealing with compressed non-HTML content. So, we really want to disable output compression when we are serving anything but HTML/text. Easy enough. We simply wrap calls to header() with our own function that looks at the Content-Type that people are sending, and turn off output buffering if necessary. But what we've been bitten by is the inability to completely turn off output compression once it has been turned on with obstart(ob_gzhandler). ob_end_{clean,flush} will stop the output buffering and compression, but the header 'Content-Encoding: gzip' is already sent, at that point. Since we can't (to my knowledge, please correct me if this is the case) remove the header, the best we can do is replace it with the second header() parameter, which unfortunately doesn't do the job as far as the browsers are concerned. Two ideas: -we could change zlib.c to, when output buffering+compression is on, not call sapi_add_header (with the Content-Encoding header) until a ob_end_flush happens or the buffer is flushed implicitly at the end of program's execution. If an ob_end_clean were to happen, the header is not sent at all. That seems like more correct behavior, but someone more familiar with the code will have to speak to the feasibility of this. or -write an extension wrapping the appropriate Apache API calls so that one, from PHP, can manipulate (read: delete) the headers in Apache's output buffer, like you can in Perl. My guess is that this probably would already have been done if there were not some significant obstacles. Thoughts? -- John Donagher Application Engineer, Intacct Corp. Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- 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]
Re: [PHP-DEV] Output Compression Issues
ob_end_{clean,flush} will stop the output buffering and compression, but the header 'Content-Encoding: gzip' is already sent, at that point. Since we can't (to my knowledge, please correct me if this is the case) remove the header, the best we can do is replace it with the second header() parameter, which unfortunately doesn't do the job as far as the browsers are concerned. But a second call to Header(Content-Encoding:) will replace the first one. If no content has gone out yet, overwriting a previous Content-Encoding header is trivial. I am not sure what you mean when you say that this doesn't do the job for some browsers. Do they not like a blank content-encoding header? It's not like you end up sending two content-encoding headers. We could add some sort of UnHeader() function which calls Apache's ap_table_unset() function, but I am not sure if other SAPI backends have support for this. -Rasmus -- 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]