tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Response.getWriter(), getOutputStream(), setContentLength() spec issues
Date Fri, 25 Feb 2011 19:38:59 GMT
Mark,

On 2/25/2011 7:01 AM, Mark Thomas wrote:
> So, the questions we need to decide:
> 
> 1. Is the fix for bug 50748 correct? I think it is.

+0

> 2. Should Tomcat try and handle this situation (e.g. if any bytes have
> been written by a filter, commit the response). This could be tricky to
> get right when forwards are involved and the response is meant to have
> been cleared. I'm leaning towards not doing this.

The Filter definitely needs to be able to set headers and append content
to the response entity. I'm not sure about a Filter having a legitimate
reason to write content /before/ the servlet does to the response
entity... I'm having trouble thinking of a use case for that. Given
that, having the Filter write anything to the response stream/writer
seems reasonable to commit the response.

On the other hand, why should a filter act any differently than a
servlet? What I mean is that the response won't be committed when a
servlet writes to the response until the response buffer has been
filled, or an explicit flush() has been called. Also, a servlet should
have the opportunity to reset the response if possible given the commit
state.

I think that makes me -1 on this one.

> 3. Is any filter that writes to the response without wrapping it so any
> calls to setContentLength() can be intercepted and adjusted as necessary
> broken? I think it is.

+1

Where does this fail the TCK? Do we have a broken Filter, or does the
TCK test an unusual/stupid scenario?

> Thoughts? I'd like to reach some conclusions fairly speedily as this
> might hold up a 7.0.9 release. If we conclude that the filter is at
> fault in point 3, we'll need to raise a TCK challenge.

I guess that answers my question.

We could have a "just-pass-the-damned-TCK" configuration flag (or maybe
something less inflammatory) that would change this behavior to
commit-on-write for Filters.

-chris


Mime
View raw message