Trying to serve PDF files using gzip encoding in PHP

Using ob_gzhandler

[grahamstewart]

I had a cunning plan.

I thought I'd try serving up a PDF file via the PHP gzip encoding.

So I tried this..

[pre]
function servePDF( $filename ) {
  if ( $fp = @fopen($filename, 'rb') ) {
    ob_start( 'ob_gzhandler' );
    header( 'Content-Type: application/pdf' );
    header( 'Content-Location: '.$filename );
    @fpassthru( $fp );
    ob_end_flush();
  }
  else {
    print 'Unable to open file '.$filename;
  }
}
[/pre]

This works just fine in Opera 7 but it seems to confuse IE 6.
It seems to ignore the Content-Location header so it index up try to open a file with a .php extension instead.

Bizarrely it all works perfectly if I comment out the ob_start() and ob_end_flush() (but of course then its not compressed anymore).

Any idea how to make Internet Explorer behave itself?

[DrDoc]

Tried putting ob_start after the headers?

header( 'Content-Type: application/pdf' );
header( 'Content-Location: '.$filename );
ob_start( 'ob_gzhandler' );
@fpassthru( $fp );
ob_end_flush();

[grahamstewart]

Good theory - but no ball.

I think the problem could be that IE looks at the file extension instead of the MIME type.

I could make the webserver treat pdf files as PHP and then rename the script.... but to be honest I've given up on this for now - perhaps something for the future.

[DrDoc]

No, IE looks at the mime type... I just tried firing up a *.txt (but image/gif mime type) and it worked.

Besides, since it works if you remove the ob_start and ob_end_flush lines, it must have something to do with that.

Truly weird... This is from the PHP manual:

ob_gzhandler() is intended to be used as a callback function for ob_start() to help facilitate sending gz-encoded data to web browsers that support compressed web pages. Before ob_gzhandler() actually sends compressed data, it determines what type of content encoding the browser will accept ("gzip", "deflate" or none at all) and will return it's output accordingly. All browsers are supported since it's up to the browser to send the correct header saying that it accepts compressed web pages.

[DrDoc]

Are you sure no other headers have already been sent?

[grahamstewart]

Yep - the page that calls the function literally looks like this:

manual.php:

<?php
include 'libs/fileserve.php';
servePDF( 'manual.pdf' );
?>

No spaces or lines before <?php
Same with fileserv.php

And there are no errors thrown from php about headers already being sent. AND I've checked the headers manually using telnet and they are all present and correct. AND it wroks with Opera :)

So its definitely not that.

[grahamstewart]

Heres a view of the headers if you are interested..

C:\> telnet 127.0.0.1 80 
HEAD /blah/blah/manual.php HTTP/1.1 
Host: 127.0.0.1 
Connection: close 
User-Agent: Sam Spade 1.14 
Accept-Encoding: gzip 
  
HTTP/1.1 200 OK 
Date: Thu, 19 Jun 2003 05:39:00 GMT 
Server: Apache/1.3.27 (Win32) PHP/4.3.1 
X-Powered-By: PHP/4.3.1 
Set-Cookie: PHPSESSID=2a5118bbcf4aa3302f6432477146eaee; path=/ 
Expires: Thu, 19 Nov 1981 08:52:00 GMT 
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 
Pragma: no-cache 
Content-Location: ed_manual.pdf 
Content-Encoding: gzip 
Vary: Accept-Encoding 
Connection: close 
Content-Type: application/pdf 
Content-Language: en-au 

But as I say - I'm pretty sure its to do with the php extension on the file (and the fact IE seems to blatantly ignore the Content-Location header) because if I select Open then IE tries to open the file up in TextPad!

[DrDoc]

What happens if you do something other than content-location? Can't think of what though...

Trixy hobbits...