Re: [PHP-DEV] Output Compression Issues

2001-08-16 Thread John Donagher

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

2001-08-15 Thread John Donagher


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

2001-08-15 Thread Rasmus Lerdorf

 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]