Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Fix #43236
Date: Wed, 5 Mar 2008 15:38:07 -0700
Message-ID: <7DD230BACBF7C14BB825154D431D2ED004C78692@posthausx.virtela.cc>
In-Reply-To: <47CDF3FC.8060200@ptc.com>
Thread-Topic: Fix #43236
Thread-Index: Ach+Xjs/McOC91/OQ1qlq/WDNXagCQAscNcQ
From: "Leech, Jonathan" <jleech@virtela.net>
To: "Tomcat Developers List" <dev@tomcat.apache.org>

I read the spec the same way as you do.=20
I have written filters that are even more permissive than this fix, and
I have also written filters that strictly adhere to the spec.=20
Strictly adhering to the spec is definitely the way to go.
If you want/need your application to violate the spec, you can write a
filter that allows it.

I wasn't aware that you can call getOutputStream() in a JSP, when did
that change?

-Jonathan


-----Original Message-----
From: Jess Holle [mailto:jessh@ptc.com]=20
Sent: Tuesday, March 04, 2008 6:15 PM
To: Tomcat Developers List
Subject: Fix #43236

I belatedly noticed this bug fix in 5.5.26 and 6.0.16.

On the one hand this seems like a nice fix, allowing the following call
sequences on ServletResponse:

   1. getWriter(), reset(), and then getOutputStream()
   2. getOutputStream(), reset(), and then getWriter()
   3. getWriter(), reset(), setCharacterEncoding(), and then getWriter()

without exceptions and with the effects one would expect if one had not
reset() or the methods prior to it.

On the other hand, the servlet spec seems to state fairly unequivocally
that (1) and (2) should result in IllegalStateExceptions and in (3) the
setCharacterEncoding() call should be silently ignored.

I'm not arguing for the fix to be rolled back, but I am trying to get
some insight as to whether I'm the only one that reads the spec this
way.

I'm interested this in large part as an occasional (and current) author
of rather complex servlet filters wherein I want to be as general and
transparent as possible.  In this role I want my filter to emulate
/standard /ServletResponse behavior as well as possible irrespective of
the servlet engine in which I'm running.  Behavior like Tomcat's after
this bug fix makes me wonder which way to head.

For now I've been leaving my filters as per my understanding of the spec
-- in large part because trying to emulate Tomcat's new behavior makes
at least my filter a real mess.  Also in practice I don't see a big need
for the new behavior as JSPWriter's usually delay
ServletResponse.getWriter() long enough for one to make up one's mind
and call getOutputStream() instead, for instance.

--
Jess Holle


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org