PDF files, part II: How does IE know?

[Thomas Dowling]

-----Original Message-----
From: Christopher Handy <charta at inetdirect.net>
To: Multiple recipients of list <web4lib at library.berkeley.edu>
Date: Saturday, July 04, 1998 12:49 AM
Subject: Re: PDF files, part II: How does IE know?


>On 7/2/98, Rich.Harrington at co.hennepin.mn.us wrote:
>
>|>Hi, more on the wackiness of linking to PDF files.
>|>
>|>   I told you all before how our machines with IE4 -- but only some of
our
>|>IE3.x machines -- were able to deal with a link to a PDF file even if the
>|>target didn't have a .pdf extension (see <
>|>http://supct.law.cornell.edu/supct/index.html >.  None of the PDF links
>|>there have a .pdf extension).
>|>
>
><snip>
>
>|>
>|>   Perhaps you are thinking that I am fixating a little too much on this
>|>little problem, and perhaps you are right.  But I do hope to gain some
>|>understanding of how the browser works, so if any of you have some
insight,
>|>I'd sure be interested to hear it.
>
>The rules of the game are that any time a server sends a file -- of
>whatever type -- to a client browser it also sends along various metadata,
>including content-type information (e.g. application/pdf in the case of a
>PDF file) so that the browser knows what to do with it. Consequently, while
>the extensions that one ordinarily sees on files downloaded over the
>Internet are very handy, I don't think they're theoretically necessary in
>order for files to be correctly interpreted by a standards-compliant
>browser. The browser should figure this out from the content-types.

Prior to version 4, MSIE had a well-known problem by which it would always
override the server's explicit Content-type header if it perceived a file
extension that pointed at some other application.  When it sees a file
extension it does not recognize, I have not seen it do anything except take
the Content-type header at face value.

I did see two things that could be causing this at the server end.  First,
Rich's server sends out HTTP headers terminated only by a line feed, not the
specified carriage return-line feed combination.  This is something servers
"should not" do in HTTP 1.0 and "must not" do in 1.1.  Second, when I send a
HEAD request for a PDF file on that server, I get back a normal header, but
if I send a GET request, the header is apparently MIME-encoded; on other
servers, a GET for a PDF file brings back the plain text version of the
header and then the rest of the file is encoded.

In short, while MSIE 3 has known problems with MIME types, this could also
be a server problem.

Thomas Dowling
Ohio Library and Information Network
tdowling at ohiolink.edu