2011/2/25 Mark Thomas <ma...@apache.org>:
> 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
>
> (...)
> The Servlet in question is the default Servlet.
>
>(..)
>
> So, the questions we need to decide:
>
> 1. Is the fix for bug 50748 correct? I think it is.
+1
> 2. Should Tomcat try and handle this situation (e.g. if any bytes have
> been written by a filter, commit the response).
-1. The filter could call flush() by itself. Though I think relying
on flush() so that setContentLength were ignored is a weak workaround.
> 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.
I think that any filter that prepends or appends data to a static file
(e.g. to add a license, an add, a message -- there are certainly are
sites that append their adds) must either
a) take care of
- setContentLength(),
- setHeader("content-length"), setIntHeader("content-length")
calls
b) use context.getRequestDispatcher(...).include(..)
I agree that if the filter does not do either a) or b) then the filter
is broken.
I have not checked yet whet HTTP spec says about content-length header
by cllients. I wonder what happens when content generation with a
content-length header fails in the middle. (and e.g. the
ErrorReportValve appends additional content). The enforcement of
the response length I think is there because otherwise it can break
clients (or proxies) and thus is legit.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
