Serving PDF from a servlet - blank screen in IE

[Alex Molochnikov]

I have a problem that is driving me nuts. Our Web app generates PDF files
using iText library; the Tomcat servlet saves the PDF data into a temporary
file, and then forwards it to the browser using sendRedirect() method of
HttpServletResponse.

When the browser gets the response, it launches Adobe Acrobat plugin and
displays the file - at least, this is what it should do. However, sometimes
it shows a blank page, with the name of the PDF file in the Address field.
One must press the RELOAD button to get the file displayed.

This happens with the Internet Explorer - one some machines, but not on all
of them (IOW, in some cases the PDF files are displayed without delay). We
are using IE6.0.26 and Adobe Acrobat 6.0. OSes are: Win NT, 2K, XP. The
generated PDF files are small - under 100K.

This effect can only be observed on IE. Netscape Navigator works fine -
every time. Unfortunately, switching to Netscape is not a solution

Has anyone experienced something like this? I have not found anything on
Google that would resemble my problem.

Any clue will be highly appreciated.

Alex Molochnikov
Gestalt Corporation
www.gestalt.com

 

[Dev]

Hi, one question: have you tryed to send the pdf content right to browser
without save in a temporary file?

Regards Fede.

 

[Roger]

This effect can only be observed on IE. Netscape Navigator works fine -
every time. Unfortunately, switching to Netscape is not a solution

Has anyone experienced something like this? I have not found anything on
Google that would resemble my problem.

Make sure that you have set response.setContentLength() to the size of
your PDF file before sending it. IE will usually display a blank page
if you don't.

Regards
Roger

 

[Davor Cengija]

I have a problem that is driving me nuts. Our Web app generates PDF
files using iText library; the Tomcat servlet saves the PDF data into
a temporary file, and then forwards it to the browser using
sendRedirect() method of HttpServletResponse.

This effect can only be observed on IE. Netscape Navigator works fine
- every time. Unfortunately, switching to Netscape is not a solution

Has anyone experienced something like this? I have not found anything
on Google that would resemble my problem.

Some three or four years ago I stumbled across that problem. Sad to see it
still exists. The problem is in the way IE communicates with Acrobat's
plugin. To have AR display a dinamically created document every time, turn
of AR's browser integration (tick of the appropriate checkbox in AR's
preferences dialog). Now you'll have an instance of AR started on demand,
instead of embedded document preview. It's a client based solution, I'm
affraid you cannot do anything at the server side to solve that problem.

See http://tinyurl.com/39vec, my two years old post explaining the same
problem.

 

[Matt Parker]

I have a problem that is driving me nuts. Our Web app generates PDF files
using iText library; the Tomcat servlet saves the PDF data into a
temporary file, and then forwards it to the browser using sendRedirect()
method of HttpServletResponse.

When the browser gets the response, it launches Adobe Acrobat plugin and
displays the file - at least, this is what it should do. However,
sometimes it shows a blank page, with the name of the PDF file in the
Address field. One must press the RELOAD button to get the file displayed.

This happens with the Internet Explorer - one some machines, but not on
all of them (IOW, in some cases the PDF files are displayed without
delay). We are using IE6.0.26 and Adobe Acrobat 6.0. OSes are: Win NT, 2K,
XP. The generated PDF files are small - under 100K.

This effect can only be observed on IE. Netscape Navigator works fine -
every time. Unfortunately, switching to Netscape is not a solution

Has anyone experienced something like this? I have not found anything on
Google that would resemble my problem.

Any clue will be highly appreciated.

Alex Molochnikov
Gestalt Corporation
www.gestalt.com

Make sure that you have a .pdf on the end of the URL. IE is stupid and often
ignores the mime-type, even if set correctly, unless it has a suffix it
expects.

Matt

 

[Dave Miller]

I have a problem that is driving me nuts. Our Web app generates PDF files
using iText library; the Tomcat servlet saves the PDF data into a temporary
file, and then forwards it to the browser using sendRedirect() method of
HttpServletResponse.

When the browser gets the response, it launches Adobe Acrobat plugin and
displays the file - at least, this is what it should do. However, sometimes
it shows a blank page, with the name of the PDF file in the Address field.
One must press the RELOAD button to get the file displayed.

This happens with the Internet Explorer - one some machines, but not on all
of them (IOW, in some cases the PDF files are displayed without delay). We
are using IE6.0.26 and Adobe Acrobat 6.0. OSes are: Win NT, 2K, XP. The
generated PDF files are small - under 100K.

This effect can only be observed on IE. Netscape Navigator works fine -
every time. Unfortunately, switching to Netscape is not a solution

Has anyone experienced something like this? I have not found anything on
Google that would resemble my problem.

Any clue will be highly appreciated.

Alex Molochnikov
Gestalt Corporation
www.gestalt.com

Dev's suggestion will fix the problem. Lose the temp file, put the iText
document generation within doGet - IE will recognize it and call Reader.

 

[Rogan Dawes]

Some three or four years ago I stumbled across that problem. Sad to see it
still exists. The problem is in the way IE communicates with Acrobat's
plugin. To have AR display a dinamically created document every time, turn
of AR's browser integration (tick of the appropriate checkbox in AR's
preferences dialog). Now you'll have an instance of AR started on demand,
instead of embedded document preview. It's a client based solution, I'm
affraid you cannot do anything at the server side to solve that problem.

See http://tinyurl.com/39vec, my two years old post explaining the same
problem.

there is another possible reason for the problem. I have heard that the
Acrobat plugin uses Content-Range to get only the specific portion of
the document that is currently being displayed. If Acrobat requests a
certain portion of the document, and later comes back and requests a
different portion, your servlet/jsp has to recreate the PDF, and send
only the requested byte range.

If you create a temporary file, and redirect the PDF plugin to it, the
application server is able to satisfy those range requests
automatically, with no impact on your servlet.

You may wish to check *exactly* what is beng requested, using a network
monitor such as Ethereal, or similar, in order to rule this out.

Regards,

Rogan

 

[Alexandr Molochnikov]

Hi, one question: have you tryed to send the pdf content right to browser
without save in a temporary file?

Regards Fede.

We tried this in the past, and had to give up on it. Here is the reason:

Our servlet produces reports in PDF format. The reports can have active
(mouse-sensitive) areas that, when clicked upon, send an HTTP request to the
servlet for another report, based on the content of the clicked-on field.
This drill-down report sequence is what prevents us from streaming the
content to the browser, because one cannot get back to the previous page in
the IE (it works fine in the Netscape browser, BTW, because NS caches the
PDF content - but what else is new when it comes to MSIE?). So, without
serving the PDF content from saved files, one can only traverse the reports
forward, but not backward.

Thanks for looking into my problem.

Alex.

 

[Alexandr Molochnikov]

I would like to thank all those who responded to my inquiry, and add one
more piece of info that I should have mentioned.

Serving PDF content from Tomcat servlet to the IE browser actually works -
as long as the HTTP request is handled by the Tomcat server itself. I.e. if
the request is formatted with the Tomcat port number:
http://abc.com:8080/Report.

But in our case, the requests are handled by Apache web server, and rerouted
to Tomcat using JK2 connector. This way we do not have to specify the port
number in HTTP requests (it goes to the default port 80 Apache is listening
to). And this is when the problem shows up.

I searched Google for any clues regarding JK2 and PDF, but found nothing.

Anyone heard something like this?

Alex.

 

[Rogan Dawes]

I would like to thank all those who responded to my inquiry, and add one
more piece of info that I should have mentioned.

Serving PDF content from Tomcat servlet to the IE browser actually works -
as long as the HTTP request is handled by the Tomcat server itself. I.e. if
the request is formatted with the Tomcat port number:
http://abc.com:8080/Report.

But in our case, the requests are handled by Apache web server, and rerouted
to Tomcat using JK2 connector. This way we do not have to specify the port
number in HTTP requests (it goes to the default port 80 Apache is listening
to). And this is when the problem shows up.

I searched Google for any clues regarding JK2 and PDF, but found nothing.

Anyone heard something like this?

Alex.

I suggest that you use a network sniffer to check *exactly* what is
being sent between the server and browser. You will probably find that
you have a different header, or encoding scheme, or something that
accounts for the difference that you are seeing.

i.e. Run ethereal or similar when you request the pdf from Apache
Do the same when getting it from Tomcat

Compare the headers (and maybe the body, too!)

You should see something that explains what you are seeing.

Regards,

Rogan

 

[Roedy Green]

i.e. Run ethereal or similar

see http://mindprod.com/jgloss/sniffer.html for some choices.

 

[Mohun Biswas]

see http://mindprod.com/jgloss/sniffer.html for some choices.

There's also NetTool (http://nettool.sourceforge.net/) which is not
listed in the glossary. This is much simpler than either Ethereal or
WebScarab (neither of which I've ever figured out how to use). Nettool
is HTTP-specific and simply puts up two panes, showing requests in the
left pane and responses in the right. I use it all the time for
debugging. It's pure Java.

The downside is that it hasn't been maintained for a couple of years now
and there are a few missing features which would make it much more
pleasant to use (like remembering what port to listen on - I have to
type in "8080" every time it starts up). But even with those little
warts it's very handy.

MB