PDF in IE revisited

[Ulrich Mayring <ul...@denic.de>]

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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>

Re: PDF in IE revisited

[Ulrich Mayring <ul...@denic.de>]

Gritsenko wrote:
> 
> I had similar problem with IE5.
> 
> Before I was getting blank pages in IE5, after - normal PDF in separate
> Acrobat window.

This works indeed, but it requires your users to change their local
configuration, so I don't think it's ideal.

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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>

Re: PDF in IE revisited

[Gritsenko <gr...@home.com>]

I had similar problem with IE5.

I produce PDF as result of request to blabla.jsc, which is a servlet in
fact, since in Tomcat 3.2 I performed an url pattern mapping for *.jsc to
this particular servlet.

Do the following once, close IE5 and Acrobat afterwards, restart IE5, try
URL woith PDF again.
The following: <When in Acrobat window, I clicked ctrl-K, got to
Preferences - Options - and unchecked 'Display PDF in browser'. I think
"Check browser settings when starting Acrobat" should be unchecked as well.
I use Acrobat 5.0.>

The effect was: IE5 simply redirected PDF to Acrobat and launched Acrobat in
separate window, so somehow they influence each other to lesser degree, I
guess.

Before I was getting blank pages in IE5, after - normal PDF in separate
Acrobat window.

If you try it and it does not work, send me URL of your PDF and I will try
it myself.

Viktor


----- Original Message -----
From: "Ulrich Mayring" <ul...@denic.de>
To: <co...@xml.apache.org>
Sent: Friday, June 08, 2001 8:52 AM
Subject: PDF in IE revisited


> 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: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
>


---------------------------------------------------------------------
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>