I read the spec the same way as you do. I have written filters that are even more permissive than this fix, and I have also written filters that strictly adhere to the spec. 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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
