Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Date: 2 Apr 2004 21:38:00 -0000
Message-ID: <20040402213800.16054.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: tomcat-dev@jakarta.apache.org
Cc: 
Subject: 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 jessh@ptc.com  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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org