Hi, I had the same problem recently and found there is a bug in IE that ignores the mime header, just not sure why. But the only way I could find to get round this was to append '.pdf' at the end of the page name, i.e. if you call 'showpdf.jsp' call it with a param like 'showpdf.jsp?.pdf'
I know this isn't a fix for tomcat but I believe the problem is not caused by Tomcat. I hope this helps. Chris -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 12 November 2003 14:16 To: [EMAIL PROTECTED] Subject: Issue with Tomcat 4.1.29 default Character Encoding Hi All, We are having an issue with the latest version of Tomcat and how the Content Type header is being set by it now - in particular with PDFs generated by our application. The following is taken straight from the RequestDumperValve: OLD (Tomcat 4.1.24) 2003-11-11 16:11:19 RequestDumperValve[Standalone]: --------------------------------------------------------------- 2003-11-11 16:11:19 RequestDumperValve[Standalone]: authType=null 2003-11-11 16:11:19 RequestDumperValve[Standalone]: contentLength=24971 2003-11-11 16:11:19 RequestDumperValve[Standalone]: contentType=application/pdf 2003-11-11 16:11:19 RequestDumperValve[Standalone]: header=Content-Type=application/pdf 2003-11-11 16:11:19 RequestDumperValve[Standalone]: header=Content-Length=24971 2003-11-11 16:11:19 RequestDumperValve[Standalone]: message=null 2003-11-11 16:11:19 RequestDumperValve[Standalone]: remoteUser=null 2003-11-11 16:11:19 RequestDumperValve[Standalone]: status=200 2003-11-11 16:11:19 RequestDumperValve[Standalone]: =============================================================== NEW (Tomcat 4.1.29) 2003-11-11 16:07:08 RequestDumperValve[Standalone]: --------------------------------------------------------------- 2003-11-11 16:07:08 RequestDumperValve[Standalone]: authType=null 2003-11-11 16:07:08 RequestDumperValve[Standalone]: contentLength=24971 2003-11-11 16:07:08 RequestDumperValve[Standalone]: contentType=application/pdf;charset=ISO-8859-1 2003-11-11 16:07:08 RequestDumperValve[Standalone]: header=Content-Type=application/pdf;charset=ISO-8859-1 2003-11-11 16:07:08 RequestDumperValve[Standalone]: header=Content-Length=24971 2003-11-11 16:07:08 RequestDumperValve[Standalone]: header=Date=Tue, 11 Nov 2003 21:07:08 GMT 2003-11-11 16:07:08 RequestDumperValve[Standalone]: header=Server=Apache-Coyote/1.1 2003-11-11 16:07:08 RequestDumperValve[Standalone]: message=null 2003-11-11 16:07:08 RequestDumperValve[Standalone]: remoteUser=null 2003-11-11 16:07:08 RequestDumperValve[Standalone]: status=200 2003-11-11 16:07:08 RequestDumperValve[Standalone]: =============================================================== Obviously the change is now that the charset has been appended to the Content-Type header. This is causing a problem with IE browsers (tested on the latest 6.0 and also on 5) in that it is no longer activating the Acrobat Reader to display the file - it is instead bringing up an 'Open/Save' dialog box as if it did not recognize the Mime type - though the Type of the document is recognized as 'Adobe Acrobat' in the dialog box. I have done some searching in the documentation and in the Tomcat source on how we can disable the charset being appended - but to no avail so far (I know we can change the character encoding in the wrapper implementation of Response, but at that point in the code we only have access to the HttpServletResponse object - which does not have the corresponding setCharacterEncoding method) Am I missing something? Is there a way to set the Character Encoding in the configuration files? We are using Struts also - which I know has a 'default content type' parameter that can be set - but Im not sure this will help us in this circumstance! Thanks in advance Steve ********************************************************************** The information contained in this message or any of its attachments may be privileged and confidential and intended for the exclusive use of the addressee. The views expressed may not be APAK policy but the personal views of the originator. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy. This footnote also confirms that this email message has been swept for the presence of known computer viruses before being sent. ********************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
