You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "verlag.preisser@t-online.de" <ve...@t-online.de> on 2011/01/13 22:41:00 UTC
No response buffering in Tomcat 7.0.6?
Good afternoon,
some weeks ago, I posted a question about the ISAPI redirector using chunked encoding for 304 responses (Topic:
Tomcat Jakarta 1.2.31 ISAPI Reconnector incorrectly sending Content body with HTTP 304 Status) which created invalid responses. These issues were fixed in Tomcat 7.0.6 and not yet released Tomcat Connectors 1.2.32 (thanks to the Tomcat devs, see https://issues.apache.org/bugzilla/show_bug.cgi?id=50363 and https://issues.apache.org/bugzilla/show_bug.cgi?id=50413).
However, when I tried the new Tomcat 7.0.6 these days, I got again a strange issue regarding 304 responses with ISAPI redirector.
It seems that Tomcat 7.0.6 doesn't use a output buffer any more. Consider this simple jsp:
<%= "hello!" %>
Running the jsp in Tomcat 7.0.5, the request and response look like this:
GET /simple.jsp HTTP/1.1
Host: localhost
Keep-Alive: 115
Connection: keep-alive
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=0AFC2875C06A962DF8A02DE6A780F721; Path=/; HttpOnly
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 6
Date: Thu, 13 Jan 2011 21:16:23 GMT
hello!
(note the Content-Lengh header, which indicates that the output has been buffered).
However, running in Tomcat 7.0.6, the response look like this:
GET /simple.jsp HTTP/1.1
Host: localhost
Keep-Alive: 115
Connection: keep-alive
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=2C176DBAC054D5BBF3D99FBE5C026915; Path=/; HttpOnly
Content-Type: text/html;charset=ISO-8859-1
Transfer-Encoding: chunked
Date: Thu, 13 Jan 2011 21:23:19 GMT
6
hello!
0
i.e. chunked encoding is applied to the response, although it should easily fit into the output buffer.
Now, the same is used for "304 Not Modified" responses when accessing static content. Normally, when the DefaultServlet returns a 304 status because the requestet resource has not modified, it writes a content-length: 0 header, but it is removed by the Tomcat HTTP connector (according to Tim Whittington's description). However the ISAPI redirector did not remove the header, and the response looked like this:
HTTP/1.1 304 Not Modified
ETag: W/"13614-1291405552000"
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Thu, 13 Jan 2011 21:27:06 GMT
Content-Length: 0
This was still a valid response. But with Tomcat 7.0.6, using the ISAPI redirector with chunked encoding support enabled, I get the following response:
HTTP/1.1 304 Not Modified
Transfer-Encoding: chunked
ETag: W/"13614-1291405552000"
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Thu, 13 Jan 2011 21:27:06 GMT
0
which is invalid. The issue is fixed for the next version of the ISAPI redirector (1.2.32), but it is not released yet, so I can't use the new version.
Disabling chunked encoding would solve the invalid response symptom, but I would like to continue using use chunked encoding.
Does anybody know why Tomcat uses chunked encoding instead of content-length header (output buffering)?
Thanks,
Konstantin Preisser
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: No response buffering in Tomcat 7.0.6?
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/1/14 André Warnier <aw...@ice-sa.com>:
> Konstantin Kolinko wrote:
>>
>> 2011/1/14 Mark Thomas <ma...@apache.org>:
>>>
>>> On 13/01/2011 21:41, verlag.preisser@t-online.de wrote:
>>>>
>>>> Does anybody know why Tomcat uses chunked encoding instead of
>>>> content-length header (output buffering)?
>>>
>>> Chunked encoding does not mean that the output is unbuffered. If a
>>> client declares support for HTTP/1.1 then web servers are free to use
>>> chunked encoding for the response if they choose.
>>>
>>> I suspect what you are seeing is a side-effect of the fix for
>>> http://issues.apache.org/bugzilla/show_bug.cgi?id=50496 but I haven't
>>> checked through the code.
>>>
>>
>> Confirming this issue. I added it to Bugzilla:
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=50582
>>
>
> There have a been another couple of threads recently related to the chunked
> transfer-encoding.
> If I remember correctly, in one of them the OP complained about Tomcat using
> this encoding for small responses, on the grounds of the added overhead or
> bandwidth introduced by the chunk headers.
> I am not sure that I agree with the basic principle (as the
> transfer-encoding is really the server's or intermediate agent's decision),
> but say in the interest of keeping the peace :
>
> Suggestion: a new attribute of the Connector, allowing to set a minimum
> treshold for the start of chunked encoding, similar to the "compression"
> threshold.
> For example : minChunkTreshold="1000" would mean that below a 1000
> bytes-size response, Tomcat does not use chunked encoding.
>
> That is assuming that Tomcat /can/ detect that the response is "finished"
> after 500 bytes e.g.
>
There is already, - buffer size, 8Kb. The question is why this
feature does not work in this particular case -- see the issue in
Bugzilla.
Chunked encoding is used when content length is not known when
response headers are being sent out. The question is what triggers
sending the headers and why the response length is not known at that
time.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: No response buffering in Tomcat 7.0.6?
Posted by André Warnier <aw...@ice-sa.com>.
Konstantin Kolinko wrote:
> 2011/1/14 Mark Thomas <ma...@apache.org>:
>> On 13/01/2011 21:41, verlag.preisser@t-online.de wrote:
>>> Does anybody know why Tomcat uses chunked encoding instead of content-length header (output buffering)?
>> Chunked encoding does not mean that the output is unbuffered. If a
>> client declares support for HTTP/1.1 then web servers are free to use
>> chunked encoding for the response if they choose.
>>
>> I suspect what you are seeing is a side-effect of the fix for
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=50496 but I haven't
>> checked through the code.
>>
>
> Confirming this issue. I added it to Bugzilla:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50582
>
There have a been another couple of threads recently related to the chunked transfer-encoding.
If I remember correctly, in one of them the OP complained about Tomcat using this encoding
for small responses, on the grounds of the added overhead or bandwidth introduced by the
chunk headers.
I am not sure that I agree with the basic principle (as the transfer-encoding is really
the server's or intermediate agent's decision), but say in the interest of keeping the peace :
Suggestion: a new attribute of the Connector, allowing to set a minimum treshold for the
start of chunked encoding, similar to the "compression" threshold.
For example : minChunkTreshold="1000" would mean that below a 1000 bytes-size response,
Tomcat does not use chunked encoding.
That is assuming that Tomcat /can/ detect that the response is "finished" after 500 bytes e.g.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: No response buffering in Tomcat 7.0.6?
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/1/14 Mark Thomas <ma...@apache.org>:
> On 13/01/2011 21:41, verlag.preisser@t-online.de wrote:
>> Does anybody know why Tomcat uses chunked encoding instead of content-length header (output buffering)?
>
> Chunked encoding does not mean that the output is unbuffered. If a
> client declares support for HTTP/1.1 then web servers are free to use
> chunked encoding for the response if they choose.
>
> I suspect what you are seeing is a side-effect of the fix for
> http://issues.apache.org/bugzilla/show_bug.cgi?id=50496 but I haven't
> checked through the code.
>
Confirming this issue. I added it to Bugzilla:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50582
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: No response buffering in Tomcat 7.0.6?
Posted by eurotrans-Verlag <ve...@t-online.de>.
Hi everybody,
thanks for your replies.
> -----Original Message-----
> From: Mark Thomas [mailto:markt@apache.org]
>
> Chunked encoding does not mean that the output is unbuffered. If a
> client declares support for HTTP/1.1 then web servers are free to use
> chunked encoding for the response if they choose.
Hi Mark,
you're right: It seems Tomcat actually uses a buffer for the response. But it seems a bit strange to me that it uses chunked encoding, although the content length should be known when sending the headers as the response fits into the buffer.
I agree that Tomcat itself is not violating the spec. However what is not compliant to the spec, are that 304 responses that I get from IIS when using the ISAPI redirector 1.2.31 (with chunked encoding enabled) with Tomcat 7.0.6 (and this time for normal 304 responses, not the ones from bug #50413 ;) ), because they contain a "Transfer-encoding: chunked" header and a body (as described in bug #50363).
This worked fine with Tomcat 7.0.5. I will have to disable the chunked encoding support in the ISAPI redirector in order to get spec-compliant 304 responses (because then they will have a "Connection: close" header without a body) until the 1.2.32 connectors are released.
> -----Original Message-----
> From: André Warnier [mailto:aw@ice-sa.com]
>
> There have a been another couple of threads recently related to the
> chunked transfer-encoding.
> If I remember correctly, in one of them the OP complained about Tomcat
> using this encoding
> for small responses, on the grounds of the added overhead or bandwidth
> introduced by the
> chunk headers.
> I am not sure that I agree with the basic principle (as the transfer-
> encoding is really
> the server's or intermediate agent's decision), but say in the interest
> of keeping the peace :
Hello André,
Well I do not want to disable chunked encoding. I clearly prefer a "Transfer-encoding: chunked" header over a "Connection: close" header when the content length is not known in advance, because with chunked encoding the connection can stay open, whereas with a "Connection: close" the connection has to be closed after the response is finished.
That's why I want to use the ISAPI redirector with chunked encoding enabled; however this regression is preventing me from doing this, as it would cause invalid 304 responses (and I can't compile the trunk version of the Connectors by myself, so I have to wait until 1.2.32 gets released or the regression in Tomcat is fixed).
Again, thanks for your replies.
Cheers
Konstantin Preißer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: No response buffering in Tomcat 7.0.6?
Posted by Mark Thomas <ma...@apache.org>.
On 13/01/2011 21:41, verlag.preisser@t-online.de wrote:
> Does anybody know why Tomcat uses chunked encoding instead of content-length header (output buffering)?
Chunked encoding does not mean that the output is unbuffered. If a
client declares support for HTTP/1.1 then web servers are free to use
chunked encoding for the response if they choose.
I suspect what you are seeing is a side-effect of the fix for
http://issues.apache.org/bugzilla/show_bug.cgi?id=50496 but I haven't
checked through the code.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org