DO NOT REPLY [Bug 28170] - PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28170. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28170 PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1 --- Additional Comments From [EMAIL PROTECTED] 2004-05-04 10:32 --- We serve our PDFs with a servlet which had worked for a long time with all Tomcat4 versions and Acrobat versions 4/5 and also Acrobat 6.0.0 but not Tomcat 4.1.29 and Acrobat 6.0.1. With Tomcat 4.1.30 it works again. This report is only valid for IE of course (tested only with IE6). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28170] - PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28170. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28170 PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1 --- Additional Comments From [EMAIL PROTECTED] 2004-04-05 14:31 --- Thanks guys. The servlet checks out: GET /sample.pdf HTTP/1.0 HTTP/1.1 200 OK Last-Modified: Fri, 02 Apr 2004 18:38:42 GMT Content-disposition: inline; filename=sample.pdf Content-Type: application/pdf Content-Length: 32111 Date: Mon, 05 Apr 2004 14:28:36 GMT Server: Apache-Coyote/1.1 Connection: close I can understand all the motivations behind all of this. Ours is that JSPs are a lot more convenient to develop than servlets, but so it goes. Peace, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28170] - PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28170. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28170 PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1 --- Additional Comments From [EMAIL PROTECTED] 2004-04-05 18:30 --- Created an attachment (id=11139) WEB-INF directory for PDF serving servlet test - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28170] - PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28170. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28170 PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1 --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 20:44 --- Created an attachment (id=11107) Test Case for Bug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28170] - PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28170. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28170 PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 20:53 --- This is actually normal. JSP is textual data, so a charset will be sent to the client. Acrobat is broken and doesn't like that (and this is the end of the story). You should either: - use a servlet to generate the PDF (this seems a better match) - hack Jasper a little bit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28170] - PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28170. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28170 PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1 --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 21:09 --- I read this supposedly fixed bug 24970: charset appended to content-type even if not text/* Do you care to comment on this? This is the problem. Some comment about how you guys fixed the extra characters for images (but not application mimetypes?) I have not generated any text up to that point in my jsp and would have thought that setting the content type would cause your connectors to behave appropriately. If I am not following the standards then please point me to the document that proves it. I thought that Tomcat was a Reference Implementation. Also my test case works with everyone else and I know that MS IE is a bad actor with its 2X or 3X request mimetype snooping, but you guys certainly have had to deal with that for years. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28170] - PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28170. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28170 PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1 --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 21:13 --- Well, it's what I said. Bug 24970 is about the connector always setting the charset every time. OTOH, JSPs, since they are text, always append the charset in the application layer (here, it's the default HTTP encoding). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28170] - PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28170. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28170 PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1 --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 21:16 --- I'll get back yo you if the servlet doesn't work, but I'd hate to have my developers change things if it won't. Regards, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28170] - PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28170. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28170 PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1 --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 21:22 --- Write a trivial servlet to test, without the actual PDF body generation to test it (and use a telnet to see the headers). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28170] - PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28170. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28170 PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1 --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 21:37 --- In other words, there is a bug/gap/feature in the JSP spec itself that one really cannot return anything but text of some variety or another from a JSP page. Essentially prior to filters you had to use a servlet for anything other than text -- including images, PDFs (which really should not be treated as text for various reasons), etc. Even with filters you JSP page must pass something to the filter which is not the end-binary response whereupon the filter produces the binary responses -- which is not always convenient... This is unfortunate (and something I debated with the spec authors -- especially since no filters existed at the time), but essentially the notions of having to either require any non-text page authors to strictly watch out for or auto-discard whitespace produced by JSP source formatting, etc, were both considered untenable. At this point, I have to agree the spec authors to *some* degree, though it would still be nice to just use the familiar JSP page mechanism for binary output as well, e.g. by setting the page to binary prior to the output writer being flushed and then being able to get a hold of the output *stream* instead of writer. Anyway, to make a long story short -- you'll have deal with the spec implications. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28170] - PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28170. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28170 PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1 --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 23:27 --- Thanks, I did the telnet trick to see everything: GET /badpdf.jsp HTTP/1.0 Returns: HTTP/1.1 200 OK Set-Cookie: JSESSIONID=FACB1957A5D101E32866F2466D16D929; Path=/ Content-disposition: inline; filename=sample.pdf Content-Type: application/pdf;charset=ISO-8859-1 Content-Length: 32111 Date: Fri, 02 Apr 2004 23:08:46 GMT Server: Apache-Coyote/1.1 Connection: close While GET /sample.pdf HTTP/1.0 Returns: HTTP/1.1 200 OK ETag: W/32111-1080931122000 Last-Modified: Fri, 02 Apr 2004 18:38:42 GMT Content-Type: application/pdf Content-Length: 32111 Date: Fri, 02 Apr 2004 23:11:06 GMT Server: Apache-Coyote/1.1 Connection: close So it looks like servlet time. About PDFs as Text - As someone who beta tested Acrobat 1.0 and has followed it ever since although not as closely since 4.0. Done all kinds of things like Java applets launched from a 3.0 plugin, etc. - Since PDF-1.2 (or so) and linearized/zipped content streams PDFs are no longer 7- bit ASCII. So, I can see where a character set choice might confuse any of the applications upstream of the web server! Also, Jess's point about worrying about linefeeds is something I'm always checking - particularly the one(s) which easily can get tacked on after the last % - PDFs (unless linearized) need the end of the file to find everything - all the objects are found from the end. Here we are the little guys and upstream we have Sun, MSFT and Adobe doing what they will. Peace. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
