[lug] CGI Generated PDFs and MS Explorer 5.5 Problems...

[D. Stimits]

First thing I would have to wonder is if people upgraded IE without
upgrading the pdf ActiveX component. There is a possibility that the pdf
component also needs a matching upgrade (whether or not such an upgrade
exists).

In the code below, I also wonder if something happened where it now
fails to interpret the "\n" notation, now requiring the Windowsism of
"\r\n". Where you have:
> print "Content-Length: $bytes\n",
>       "Content-Type: application/pdf\n\n";
Try making each \n as \r\n.

The reason I grasp at something so silly and improbable is that you said
the two were identical. What remains are the non-printing characters,
such as newlines.

Ryan Kirkpatrick wrote:
> 
>         Here is a problem for all you Microsoft conspiracy theorist out
> there... :)
> 
>         I have a CGI program that dynamically generates PDF files and
> returns them to the user's web browser for it to display. This works
> without a hitch with Netscape 4.x on Linux and Windows, and with Internet
> Explorer 5.0 on Windows. I simply provide the appropriate content-type
> header (application/pdf), acroread is loaded, and the PDF is displayed.
>         Recently though, Microsoft decided to update Internet Explorer to
> version 5.5, which means many of the users of this CGI program (blindly)
> followed along and upgraded. Unfortunetly the same CGI program, when it
> attempts to give a user running IE 5.5 a PDF file, results in acroread
> loading, followed by a blank screen and a message in the status bar that
> there was an error with the file. Given Microsoft's lack of verbosity in
> their error messages I did not know where to start.
>         I wrote a small CGI program that just returned a static PDF file
> and it too would not work with IE 5.5. I then added a Content-Length
> header to better match the headers returned by Apache when a PDF file is
> request directly. This appeared to solve the problem, IE 5.5 would now
> display the CGI served PDF file. The perl script is below:
> 
> #!/usr/bin/perl
> 
> open(PDF,"/tmp/pdf.pdf");
> $bytes = read(PDF,$pdf,5000000);
> print "Content-Length: $bytes\n",
>       "Content-Type: application/pdf\n\n";
> print $pdf;
> 
>         Now, I attempted to change my CGI program to reflect the addition
> of a Content-Lenght header. Yet, even with that additionally header IE
> 5.5 still refuses to show the served PDF file, and fails with the same
> behavior. Lastly, I used a telnet client to connect to my server and
> manually issued the HTTP commands to call the CGI program and my small
> perl script above. The resulting data was identical, and the first few
> lines are shown below:
> 
> HTTP/1.1 200 OK
> Date: Thu, 22 Mar 2001 05:05:03 GMT
> Server: Apache/1.3.9 (Unix) Debian/Alpha
> Content-Length: 121727
> Connection: close
> Content-Type: application/pdf
> Content-Language: pl
> 
> %PDF-1.2
> <................Lots of Binary Data.................>
> 
> Since both CGI scripts are returning the same data, I am stumped as to why
> IE 5.5 will display the PDF file from one, but not the other. The static
> PDF file being served is merely a copy of one of the dynamicly generated
> PDF files the CGI program is serving. In other words the PDF files being
> served both CGI scripts are basically identical.
>         So, anyone have any ideas on how to solve this problem, or where
> to look for more clues? Also, having my users downgrade to IE5 or use
> Netscape is a non-option (they are customers who's machines I have no
> control over). Thanks.
> 
> ---------------------------------------------------------------------------
> |   "For to me to live is Christ, and to die is gain."                    |
> |                                            --- Philippians 1:21 (KJV)   |
> ---------------------------------------------------------------------------
> |   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
> ---------------------------------------------------------------------------
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug