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
signature.asc
Description: OpenPGP digital signature
