cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Mayring <u...@denic.de>
Subject PDF in IE revisited
Date Fri, 08 Jun 2001 12:52:46 GMT
Jonathan Fuerth wrote:
> 
> Content-Disposition: inline; filename=thingy.pdf
> 
> will do pretty much the same as a Content-type of "application/pdf"
> should do. You can achieve this in java code with:
> 
> response.setHeader("Content-Disposition", "inline; filename=thingy.pdf");

With the newest security patch of Internet Explorer (Version
5.50.4522.1800) this and all other workarounds do *NOT* fly anymore.
There are some serious bugs in IE, which work together to create hell on
earth for us all. Here is what my research suggests:

1) IE receives some data, looks at the content type, starts an
appropriate application (unless it handles that content type internally,
like "text/html") and downloads the data.
2) Then IE *forgets* what it just learned about the content type and
tries to find an application to display the downloaded data with. This
is the critical point.

IE apparently has some kind of security filter that actually evaluates
the data it receives and it drops any lines that look like suspicious
code. Unfortunately in the case of ASCII-PDF there can be (but do not
have to be) lines that look like suspicious code to IE and they are
dropped. This leads to a blank page displaying, because usually the PDF
will not be well-formed anymore.

But I also have a reproducible case, where the PDF by some stroke of
luck(?) is still well-formed and still displays - only that some of the
information originally contained in it is gone. Believe it or not, in my
case this leads to a letter that simply misses a few lines of text
in-between and some lines simply lack a word or two in the middle of a
sentence. So, even if your PDF displays correctly, you might want to
check with an EtherNet sniffer if the PDF code sent from the server is
actually the same as the code IE sends to Acrobat or the PDF plugin.

This security filter comes into play whenever IE realizes it has to
display a PDF (possibly with other file formats as well). So we have to
tell IE that it in fact *doesn't know* what to do with that file - here
it comes in kind of handy that IE forgot about the content type in the
first place. But we mustn't tell IE "you don't know this" before
downloading by setting a strange content type - it will refuse to
download the PDF then.

So I use:

1) A content type of "application/pdf", so the data is downloaded and
the Acrobat plug-in started in the background.
2) Use this line in the page that returns a PDF:

response.setHeader("Content-Disposition", "inline; filename=thingy");

The same line as suggested originally with the subtle difference that I
use no extension on "thingy". If I use "thingy.pdf" or the other
workaround of changing the filename to mypdf.xml?iefix=yes.pdf or
similar, then IE fires the security filter and possibly drops a few
lines. If I use no extension at all, then IE (depending on user
preferences) either asks the user whether to save the file or it pops up
a window from which the user can select "Acrobat" as the application to
open the data with. This is not very convenient, but at least IE doesn't
touch the PDF anymore.

Note that binary PDFs (like any binary format) probably work. The
security filter apparently only checks ASCII type of data, my guess is
that it looks for malicious scripting code.

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail: <cocoon-users-help@xml.apache.org>


Mime
View raw message