On Wed, Aug 31, 2011 at 8:42 AM, Eric Lease Morgan <[log in to unmask]> wrote:
> Eric wrote:
> > Unfortunately IE's behavior is weird. The first time someone tries to
> > one of these URL nothing happens. When someone tries to load another one,
> > loads just fine. When they re-try the first one, it loads. We are banging
> > our heads against the wall here at Catholic Pamphlet Central. Networking
> > issue? Port issue? IE PDF plug-in? Invalid HTTP headers? On-campus versus
> > off-campus issue?
> Thank you for all the replies.
> We'er not one hundred percent positive, but we think the issue with IE has
> something to do with headers. As alluded to previously, IE needs/desires
> file name extensions in order to know what to do with incoming files. We are
> serving these PDF documents from Fedora which is sending out a stream, not
> necessarily a file. Apparently this confuses IE. Since Fedora is not really
> designed to be a "file server", we will write a piece of intermediary
> software to act as a go between. This isn't really a big deal since all of
> our other implementations of Fedora are expected to work in the same way.
> Wish us luck.
FWIW, this is true for any and all HTTP servers. Only the client's request
specifies a name (as the path component of the request, e.g.,
The server's reply does not contain a name at all. It simply specifies what
type and, typically, the length of the returned content is. The returned
content itself is just a blob of bytes. Your server says "this blob of
bytes is a PDF object (application/pdf)", but it doesn't specify the length.
Not specifying the length makes the job of the client slightly more
difficult, which is why the HTTP/1.1 specification discourages it; it now
has to read the stream until the server closes the connection. It is
certainly possible that IE's PDF plug-in is not prepared to deal with this
situation; and I would certainly fix this first.