You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jess Holle <je...@ptc.com> on 2003/12/02 16:46:22 UTC
Tomcat 5 Issue (not 5.0.16 specific!)
First, I'd like to say that we should *not* consider the following issue
as one to prevent a "stable" label for Tomcat 5.0.16.
That said, I've noted that if you do:
response.setContentLength( 0 );
All subsequent setHeader(), etc, calls are ignored -- Tomcat considers
the response commited.
Is this as per the spec? Or is this an odd corner case?
[The fact that we have code that does a setContentLength(0) seems to be
an odd corner case in and of itself... I've worked around this in our
code by ensuring that this call is always made after all other headers
are assigned.]
--
Jess Holle
Re: Tomcat 5 Issue (not 5.0.16 specific!)
Posted by Jess Holle <je...@ptc.com>.
Dan Johnsson wrote:
> Jess Holle wrote:
>
>> Tim Funk wrote:
>>
>>> Section 5.5 of the spec:
>>> When a response is closed, the container must immediately flush all
>>> remaining content in the response buffer to the client. The
>>> following events indicate that the servlet has satisfied the request
>>> and that the response object is to be closed:
>>> /.../
>>> * • The amount of content specified in the setContentLength method
>>> of the response has been written to the response. *
>>
>> That's what I figured. I'm just a bit uncertain about the corner/end
>> case where nothing is to be written to the response, i.e. for a
>> content-length of 0. \
>
> It becomes clearer to me if I rephrase "The amount /.../ has been
> written /.../" to the in this context supposedly equivalent "At least
> the amount /.../ has been written /.../". Then the special case of 0
> becomes: "At least zero bytes have been written to the response." which
> is indisputably true, and thus the response object is to be closed.
I am absolutely in agreement that Tomcat is in line with the letter of
the spec here.
I just think that the a few more letter should really present as it
seems inappropriate for a setContentLength(0) to commit a response.
--
Jess Holle
Re: Tomcat 5 Issue (not 5.0.16 specific!)
Posted by Dan Johnsson <da...@omegapoint.se>.
Jess Holle wrote:
> Tim Funk wrote:
>
>> Section 5.5 of the spec:
>> When a response is closed, the container must immediately flush all
>> remaining content in the response buffer to the client. The following
>> events indicate that the servlet has satisfied the request and that
>> the response object is to be closed:
>> /.../
>> * • The amount of content specified in the setContentLength method of
>> the response has been written to the response. *
>
> That's what I figured. I'm just a bit uncertain about the corner/end
> case where nothing is to be written to the response, i.e. for a
> content-length of 0.
It becomes clearer to me if I rephrase "The amount /.../ has been
written /.../" to the in this context supposedly equivalent "At least
the amount /.../ has been written /.../". Then the special case of 0
becomes: "At least zero bytes have been written to the response." which
is indisputably true, and thus the response object is to be closed.
Dan Johnsson
_________________________________________________
Dan Johnsson | Säkerhetsarkitekt
dan.johnsson@omegapoint.se | www.omegapoint.se
tel 0709-15 88 43 | fax 08-517 008 29
Omegapoint AB - din säkra punkt i tillvaron
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat 5 Issue (not 5.0.16 specific!)
Posted by Jess Holle <je...@ptc.com>.
Tim Funk wrote:
> Section 5.5 of the spec:
> When a response is closed, the container must immediately flush all
> remaining content in the response buffer to the client. The following
> events indicate that the servlet has satisfied the request and that
> the response object is to be closed:
> • The termination of the service method of the servlet.
> * • The amount of content specified in the setContentLength method of
> the response has been written to the response. *
That's what I figured. I'm just a bit uncertain about the corner/end
case where nothing is to be written to the response, i.e. for a
content-length of 0.
> • The sendError method is called.
> • The sendRedirect method is called.
>
> Looks like the behavior is OK.
I was kind of guessing this was to the letter of the spec -- I'm fine
with my changes (which would not have been necessary but for some old
mechanisms which produce a hash of headers and toss them at code which
simply spits them at the response in hash order -- with a few special
cases to use more specific methods where possible).
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat 5 Issue (not 5.0.16 specific!)
Posted by Tim Funk <fu...@joedog.org>.
Section 5.5 of the spec:
When a response is closed, the container must immediately flush all remaining
content in the response buffer to the client. The following events indicate
that the servlet has satisfied the request and that the response object is to
be closed:
• The termination of the service method of the servlet.
* • The amount of content specified in the setContentLength method of the
response has been written to the response. *
• The sendError method is called.
• The sendRedirect method is called.
Looks like the behavior is OK.
-Tim
Jess Holle wrote:
> First, I'd like to say that we should *not* consider the following issue
> as one to prevent a "stable" label for Tomcat 5.0.16.
>
> That said, I've noted that if you do:
>
> response.setContentLength( 0 );
>
> All subsequent setHeader(), etc, calls are ignored -- Tomcat considers
> the response commited.
>
> Is this as per the spec? Or is this an odd corner case?
>
> [The fact that we have code that does a setContentLength(0) seems to be
> an odd corner case in and of itself... I've worked around this in our
> code by ensuring that this call is always made after all other headers
> are assigned.]
>
> --
> Jess Holle
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org