cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gritsenko" <gritse...@home.com>
Subject Re: PDF in IE revisited
Date Sat, 09 Jun 2001 01:52:43 GMT
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" <ulim@denic.de>
To: <cocoon-users@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: <cocoon-users-unsubscribe@xml.apache.org>
> For additional commands, e-mail: <cocoon-users-help@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: <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail: <cocoon-users-help@xml.apache.org>


Mime
View raw message