Hi,
Thanks to Bill, Vincent, Marco and Mark for their ideas about what was
happening. It helped me figure the whole thing. I have not verified
everything because it would take too much time, but here is my conclusions.
>From the pdf spec, I learned that when the browser receive an
application/pdf content, it starts the plug-in, passing it the data and the
corresponding URL. If the plug-in can take control, it aborts the request
and issues a new request using that URL.
It is still unclear to me if the plug-in issues a new request for any kind
of pdf data, or only for linearized data, (ie pdf optimized for streaming,
with all ressources at the beginning, and a couple of other changes). As my
pdf is produced by FOP, I would have to check for this, but unfortunately, I
have no time now.
So, any data send with the request should be in the URL. This does not mean
using POST, just putting the data in the URL. So we can use GET with
parameters, or POST with personnalised parameters or extra path. (BTW,
that's how session ID are passed when cookies are disabled and URLs are
encoded.)
This means if you really need to use POST with data from a form, you should
either use a client side program to compute the URL from user input data, or
use a servlet to encode the parameter in the URL and forward.
I checked the Adobe support pages but they do not seem to know about this
problem. They have lot of information about pdf displayed as a blank *pdf*
page (ie, in the plug-in), but this is a completly different problem (and an
easy one to solve : you just need to send the content length.)
Of course, there are also other workarounds, like those that where
mentionned (putting parameters in the session and waiting for the next
request, producing the data on the first request and putting it in the
session, waiting for the next request, putting the data in a file and
sending a link to that file, with send redirect, etc.) None of these seems
acceptable to me. Writting to a file is really not scalable and waiting for
the second request will just not work with some browsers (like Nestcape 4).
Hope this will be usefull to some of you
Pierre-Yves
-----Message d'origine-----
De : A mailing list for discussion about Sun Microsystem's Java Servlet
API Technology. [mailto:[EMAIL PROTECTED]]De la part de
Lindsay, William (USPC.PCT.Hopewell)
Envoy� : jeudi 19 juillet 2001 21:30
� : [EMAIL PROTECTED]
Objet : Re: Request sent twice from IE5.5 and N6 when content type is
app lication/pdf
Hi Pierre-Yves,
We put a workaround in to allow POST today. We chose to use a COOKIE
to keep the Web Farm stateless. We set the COOKIE on every request, and
retrieve the COOKIE only when NULLS arrive on the
Server. The COOKIE stores the unique document criteria, which we use to
extract from the IBM's Content OnDemand.
This allows us to avoid any configuration of Adobe Acrobat from 3.x
to 5.0.
It also allows us to avoid the filesystem on the Webserver.
Bill
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
