We got burned by that last gotcha as well. We got around it by sending the pdf
content back to a jsp and then forwarding the request from the jsp to an
application/pdf request.
--- Steven Owens <[EMAIL PROTECTED]> wrote:
> > I'm trying to compress a PDF Stream before transmitting to the
> > client. The browser is not displaying anything. The PDF displays
> > normally without my GZIP code. (I get 33% size reduction with
> > compression)
> >
> > Where have I goofed ? Thanks in Advance
>
> We were playing with returning PDFs today, so I may be able
> to shed a little light on this...
>
> > [...]
> > OutputStream sos = ServletUtilities.zipIt(request, response);
> > response.setHeader("Vary", "Accept-Encoding");
> > response.setContentType("application/pdf");
>
> You're still sending it as application/pdf. I don't know much
> about PDF stuff, but I would not assume that the browser will be able
> to figure out that it's gzipped PDF and gunzip and automatically
> display it in a PDF browser. For that matter, if you set the content
> type to gzip the browser would'nt automatically bring up a PDF viewer.
>
> Hm... a little poking around (a google search on "content-type pdf
> gzip") shows a few messages:
>
> http://lists.w3.org/Archives/Public/www-talk/2000MayJun/0003.html
> http://lists.w3.org/Archives/Public/site-comments/2000Sep/0031.html
>
> This suggest that what you need to do is set the content-encoding
> to gzip, and leave the content-type as application/pdf.
>
> Another interesting gotcha, which we learned about today. We
> were using a form POST to kick off a request to a servlet with a
> parameter identifying what file to send back. The servlet returned
> the file properly, with a proper content-type, but instead of
> displaying the file, the browser apparently interrupted the original
> request with a second request with no parameters (which of course
> caused the servlet to return a null).
>
> Our best guess is that when you use a content-type that IE needs
> to display in a plug-in like Adobe Acrobat, IE brings up the plug-in
> and then makes a second request to the same URL (but apparently
> without the form parameters) for the plug-in to use. We changed our
> approach to use method=GET and it worked just fine.
>
> Steven J. Owens
> [EMAIL PROTECTED]
>
> ___________________________________________________________________________
> 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
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
___________________________________________________________________________
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
