PDFs from a servlet works in all broswers but you have to remember to do all
of the following:
1.) Set the headers:
response.setContentType("application/pdf");
response.addHeader("Content-Disposition", "inline; filename=report.pdf");
(Also try to structure your URL so that the last few characters are ".pdf".
This helps some stupid version of IE that you are returing a pdf)
2.) Write out the size of the pdf:
response.setContentLength( pdfDoc.length );
3.) Flush your output stream:
out.flush();
out.close();
Dave
----- Original Message -----
From: "Micheál Healy" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 05, 2001 8:47 AM
Subject: Re: bit OT but..streaming PDF to browsers
> I can't seem to get fop to show me a pdf wit IE 5.5. Am I doing something
> wrong? This is just for general info - it's working fine with 5.0.
>
> Micheál Healy
>
> ----- Original Message -----
> From: Dave Frankson <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, July 05, 2001 2:43 PM
> Subject: Re: bit OT but..streaming PDF to browsers
>
>
> > Actually it is the sloppy way IE deals with MIME types. At the
first
> > hit, IE determines that it can't handle the content type and an external
> > plugin needs to handle the request. So it discards the data after
reading
> > the http header and does a second hit passing the entire thing to
Acrobat.
> >
> > We are using FOP to generate some reports that take 15 minutes to build,
> and
> > this is the biggest performance hit.
> >
> > Dave
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "Alex McLintock" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, July 05, 2001 4:08 AM
> > Subject: Re: bit OT but..streaming PDF to browsers
> >
> >
> > > --- David Frankson <[EMAIL PROTECTED]> wrote:
> > > > I get pdfs from servlets to work fine in IE, but I never have
overcome
> > > > the 2 hits per pdf. Is there a solution to this?
> > >
> > > I've noticed the "two hits" issue but always assumed it was due to my
> > > rubbish proxy configuration.
> > >
> > > It may be that the first request is hust a "head" request to determine
> > > the datestamp of the response and thus to determine whether or not
> > > it can retrieve the file from its cache. (It is presumably seeing that
> > > the datestamp is later than the cached version and thus requesting
> > > the whole response the second time.)
> > >
> > > So one possibility is to check for a head request and when you get it
> > > to NOT generate the PDF but just output the headers saying that the
> > > file would be new if you hadn't just done a head request.
> > >
> > > This is a bit off topic so learning how to do this is left as an
> exercise
> > > for the reader.
> > >
> > > Or if you are in London you can pay me to do it for you :-)
> > >
> > > Alex
> > >
> > >
> > > =====
> > > Alex McLintock [EMAIL PROTECTED] Open Source Consultancy in
> London
> > > OpenWeb Analysts Ltd, http://www.OWAL.co.uk/
> > > DR WHO COMPETITION:
> > http://www.diversebooks.com/cgi-bin/caption/captions.cgi?date=200104
> > > Get Your XML T-Shirt <t-shirt/> at http://www.inversity.co.uk/
> > >
> > > ____________________________________________________________
> > > Do You Yahoo!?
> > > Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
> > > or your free @yahoo.ie address at http://mail.yahoo.ie
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, email: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
