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

[rm at mamma.varadinet.de]

On Thu, Mar 22, 2001 at 11:18:27AM -0700, D. Stimits wrote:
> 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.

opposite to common belief, this is not a windowism. The combination
\r\n is the way to go, at least according to the RFCs. BTW, this
is much older than the 'Web'.  To quote the famous 822 RFC
(format of email): '... It is separated from the headers by a 
null line (i.e., a line with nothing preceding the CRLF). '

Failing to use the 'right' line ending can create hard to find 
bugs. One notorious place this showed up where older  Java VM.
They tried to be 'smart' and waited for the next character to
decied about line-endness. When you forget to send a correct
combination of \r\n at the end of data send to an applet the
would VM would block for quite a long time.

> 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.

... or, silly asl it might sound, the _Ending_ of the URL 
(uhhs from the audience). When developed my first XML driven
weblications transmogrified Apache to format XML files into
HTML (correct content type, header etc.). After a day or
two we got angry calls by our customers: whenever you asked
Netscape on MS boxes to fetch 'pricelist.xml' it would 
happily launch IE ... 


 Ralf