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]
