Streaming PDF to IE - problem

[Alex Molochnikov]

Our servlet must generate a report in PDF format, and send it to a browser.
I've run into the following two problems:

1. If the generated byte array is streamed to the browser like this (from
the doPost() method):

byte[] bArray = <PDF byte content>
response.setContentType("application/pdf");
response.setContentLength(bArray.length);
ServletOutputStream sos = response.getOutputStream();
sos.write(bArray);
sos.flush();

the file promptly appears in the browser, but if the user presses the back
button, followed by the forward button (jump to the previous page, and then
back to the report page), the report page becomes blank. This happens
because the browser calls doGet() servlet's method (which is not wired up to
produce the report), instead of using the cached page. This happens in IE
only; Netscape and Firefox work fine.

2. I attempted to solve this problem by saving the PDF data in a temporary
file, and serving the file, instead of the data stream. This worked in
Tomcat, where I can designate a directory that is part of the app context
hierarchy (i.e. is visible as a URL) by placing the directory into the
webapps/<app name> folder.

But now the app is deployed as an EJB in JBoss, and there is no location in
JBoss that could be used as a repository of dynamically created files to be
served from it. I suppose, getting into the app server's filesystem is so
much against the grain of EJB, that - unlike Tomcat - JBoss does not have
any notion of the user-managed file hierarchy.

Has anyone been confronted with such problems? Any clues will be
appreciated.

Alex Molochnikov
Gestalt Corporation

 

[Alun Harford]

Our servlet must generate a report in PDF format, and send it to a
browser.
I've run into the following two problems:

1. If the generated byte array is streamed to the browser like this (from
the doPost() method):

byte[] bArray = <PDF byte content>
response.setContentType("application/pdf");
response.setContentLength(bArray.length);
ServletOutputStream sos = response.getOutputStream();
sos.write(bArray);
sos.flush();

the file promptly appears in the browser, but if the user presses the back
button, followed by the forward button (jump to the previous page, and
then
back to the report page), the report page becomes blank. This happens
because the browser calls doGet() servlet's method (which is not wired up
to
produce the report), instead of using the cached page. This happens in IE
only; Netscape and Firefox work fine.

Find a way to use the GET method to get the report instead.
A browser should not send a POST twice, and so cannot reload the content
from the server. It also should not really read the report from its cache as
the page may have changed.

If you're storing the data, redirect to an address where the PDF can be
served using GET.
If you're not storing the data, why are you using POST?

Alun Harford

 

[Alex Molochnikov]

Find a way to use the GET method to get the report instead.
A browser should not send a POST twice, and so cannot reload the content
from the server. It also should not really read the report from its cache as
the page may have changed.

If you're storing the data, redirect to an address where the PDF can be
served using GET.
If you're not storing the data, why are you using POST?

Alun Harford

Thank you for the response. The reason for using POST instead of GET is the
number of parameters that may have to be passed to the servlet to generate
the report. GET method has a restriction on the amount of data one can pass
through the parameters. POST does not have any limits.

But I may have to take your advice anyway, and use GET, possibly limiting
the amount of data passed through the parameters. The only problem in this
case would be distinguishing between the GET that is sent from the HTML
page, requesting the report (the primary GET), and the GET that is sent by
the browser when the user returns to the report page after leaving it (the
secondary GET). I wonder if there is any way to tag the report page with a
unique identifier and have the browser transmit it to the servlet, to let
the servlet find the right byte array (there may be many reports) and send
it back to the browser.

Alex.