tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <knst.koli...@gmail.com>
Subject Re: Response.getWriter(), getOutputStream(), setContentLength() spec issues
Date Fri, 25 Feb 2011 14:58:51 GMT
2011/2/25 Mark Thomas <markt@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message