The changes [1] for bug 50748 [2] (be aware the bug number changed) have triggered some Servlet 3.0 TCK failures. I don't want to get into the details of those tests, but I do want to discuss the root cause.
Consider the following scenario: Servlet knows it will return exactly 100 bytes of content Servlet calls setContentLength() Servlet calls getOutputStream() or getWriter() Servlet writes 100 bytes In this case everything works as expected. Now add a filter to the mix that adds additional content to the response Filter calls getOutputStream() or getWriter() Filter writes 20 bytes to the response Servlet knows it will return exactly 100 bytes of content Servlet calls setContentLength() Servlet calls getOutputStream() or getWriter() Servlet writes 100 bytes There are a couple of potential issues in the second scenario: - If the Filter called getOutputStream(), the Servlet must also call getOutputStream() - If the Filter called getWriter(), the Servlet must also call getWriter() - The response contains 120 bytes but the content length header says 100 so the response is truncated by 20 bytes. This final point is (essentially) what is causing the TCK failures. The Servlet in question is the default Servlet. Prior to the commit for bug 50748, scenario 2 above would have worked if getWriter() had been used but would have failed if getOutputStream() has been used. One of the things I like about the fix for bug 50748 is that the behaviour is now consistent regardless of whether getOutputStream() or getWriter() is called. I couldn't find much in the spec about what is correct in this case although the spec does seem to imply that if a filter is going to modify the response, it should wrap the response. So, the questions we need to decide: 1. Is the fix for bug 50748 correct? I think it is. 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. 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. 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. Mark [1] http://svn.apache.org/viewvc?rev=1069131&view=rev [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=50748 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
