You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Óscar Frías Barranco <of...@trabber.com> on 2010/04/01 12:02:24 UTC

Chunked encoding should be used also when not using keepalive

Hello.

Currently Tomcat HTTP 1.1 Connector disables the use of chunked encoding if
keepalive is not used.  This happens when an HTTP 1.1 request contains a
"Connection: close" header.
I propose to change Coyote to use chunked encoding (for HTTP 1.1) even if
keepalive is disabled.

Chunked transfer-encoding is an alternative to content-length, for use when
the content-length cannot initially be determined.  While it is mandatory to
have either of them to support keep-alive, its use is not restricted to
keep-alive and one useful immediate benefit of using it is to allow a client
to distinguish a connection abort from a complete response in order to avoid
storing truncated data.

Another useful case is when a reverse-proxy is installed in front of the
server, and this reverse proxy tries to maintain keep-alive connections with
the clients and intends to close the connections with the servers (like
apache 1.3, haproxy, and I think nginx).  The lack of content-length and
chunked encoding prevents the proxy from keeping client connections alive.
The "connection: close" sent by the proxy to the server only indicates that
the proxy will send just one request to the server, not that it does not
care about the response length.  The same is true when that proxy caches.
Without any content-length nor chunked encoding, the cache could store and
distribute truncated response believing they are complete, while this would
not happen with chunked encoding because the cache will be able to know it
has not seen the end of the response.

The fix seems easy.  This is the patch:

Index: java/org/apache/coyote/http11/Http11Processor.java
===================================================================
--- java/org/apache/coyote/http11/Http11Processor.java    Tue Mar 09
18:09:50 CET 2010
+++ java/org/apache/coyote/http11/Http11Processor.java    Tue Mar 09
18:09:50 CET 2010
@@ -1547,7 +1547,7 @@
                 (outputFilters[Constants.IDENTITY_FILTER]);
             contentDelimitation = true;
         } else {
-            if (entityBody && http11 && keepAlive) {
+            if (entityBody && http11) {
                 outputBuffer.addActiveFilter
                     (outputFilters[Constants.CHUNKED_FILTER]);
                 contentDelimitation = true;


What do you think ?

Regards,
Oscar Frias
Trabber.com

Re: Chunked encoding should be used also when not using keepalive

Posted by Tim Funk <fu...@apache.org>.
Wait a sec ... not enough coffee. I might have answered a totally 
different question (and incorrectly too)

-Tim

On 4/1/2010 6:42 AM, Tim Funk wrote:
> Doing this would be bad. When serving JSP's (or anything dynamic greater
> than the buffer size) - the content length is not sent to the client. So
> when the end of the request is sent - there is no signal to the client
> to let them know the request is over and they can start a new request
> over the same connection.
>
> With chunked encoded - we can get away with no content length header
> because the each chunk as the length.
>
> -Tim
>
> On 4/1/2010 6:02 AM, Óscar Frías Barranco wrote:
>> Hello.
>>
>> Currently Tomcat HTTP 1.1 Connector disables the use of chunked
>> encoding if
>> keepalive is not used. This happens when an HTTP 1.1 request contains a
>> "Connection: close" header.
>> I propose to change Coyote to use chunked encoding (for HTTP 1.1) even if
>> keepalive is disabled.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: Chunked encoding should be used also when not using keepalive

Posted by Tim Funk <fu...@apache.org>.
Doing this would be bad. When serving JSP's (or anything dynamic greater 
than the buffer size) - the content length is not sent to the client. So 
when the end of the request is sent - there is no signal to the client 
to let them know the request is over and they can start a new request 
over the same connection.

With chunked encoded - we can get away with no content length header 
because the each chunk as the length.

-Tim

On 4/1/2010 6:02 AM, Óscar Frías Barranco wrote:
> Hello.
>
> Currently Tomcat HTTP 1.1 Connector disables the use of chunked encoding if
> keepalive is not used.  This happens when an HTTP 1.1 request contains a
> "Connection: close" header.
> I propose to change Coyote to use chunked encoding (for HTTP 1.1) even if
> keepalive is disabled.
>
> Chunked transfer-encoding is an alternative to content-length, for use when
> the content-length cannot initially be determined.  While it is mandatory to
> have either of them to support keep-alive, its use is not restricted to
> keep-alive and one useful immediate benefit of using it is to allow a client
> to distinguish a connection abort from a complete response in order to avoid
> storing truncated data.
>
> Another useful case is when a reverse-proxy is installed in front of the
> server, and this reverse proxy tries to maintain keep-alive connections with
> the clients and intends to close the connections with the servers (like
> apache 1.3, haproxy, and I think nginx).  The lack of content-length and
> chunked encoding prevents the proxy from keeping client connections alive.
> The "connection: close" sent by the proxy to the server only indicates that
> the proxy will send just one request to the server, not that it does not
> care about the response length.  The same is true when that proxy caches.
> Without any content-length nor chunked encoding, the cache could store and
> distribute truncated response believing they are complete, while this would
> not happen with chunked encoding because the cache will be able to know it
> has not seen the end of the response.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: Chunked encoding should be used also when not using keepalive

Posted by Óscar Frías Barranco <of...@trabber.com>.
But as described in the thread using chunked encoding has 2 advantages:
- detection of truncated responses
- better interoperability with reverse proxies

And the only drawback is a slight increase in bytes and cpu cycles.


On Fri, Apr 2, 2010 at 17:46, Filip Hanik - Dev Lists <de...@hanik.com>wrote:

> so the spec says, use apples or oranges, we use oranges, and you want
> apples
>
> my suggestion would be to write a filter and set the chunked header
> yourself
>
>
> On 04/02/2010 09:25 AM, Óscar Frías Barranco wrote:
>
>> Ok, but it does not say that chunked encoding cannot be used when closing
>> the connection.
>>
>> In fact chunked encoding takes precedence over connection close in the
>> determination of the transfer-length:
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
>>
>> Oscar
>>
>>
>> On Fri, Apr 2, 2010 at 17:09, Filip Hanik - Dev Lists<devlists@hanik.com
>> >wrote:
>>
>>
>>
>>> The HTTP spec says that when you close the connection, that is the
>>> delimiter for the content.
>>>
>>> Filip
>>>
>>>
>>> On 04/01/2010 04:02 AM, Óscar Frías Barranco wrote:
>>>
>>>
>>>
>>>> Hello.
>>>>
>>>> Currently Tomcat HTTP 1.1 Connector disables the use of chunked encoding
>>>> if
>>>> keepalive is not used.  This happens when an HTTP 1.1 request contains a
>>>> "Connection: close" header.
>>>> I propose to change Coyote to use chunked encoding (for HTTP 1.1) even
>>>> if
>>>> keepalive is disabled.
>>>>
>>>> Chunked transfer-encoding is an alternative to content-length, for use
>>>> when
>>>> the content-length cannot initially be determined.  While it is
>>>> mandatory
>>>> to
>>>> have either of them to support keep-alive, its use is not restricted to
>>>> keep-alive and one useful immediate benefit of using it is to allow a
>>>> client
>>>> to distinguish a connection abort from a complete response in order to
>>>> avoid
>>>> storing truncated data.
>>>>
>>>> Another useful case is when a reverse-proxy is installed in front of the
>>>> server, and this reverse proxy tries to maintain keep-alive connections
>>>> with
>>>> the clients and intends to close the connections with the servers (like
>>>> apache 1.3, haproxy, and I think nginx).  The lack of content-length and
>>>> chunked encoding prevents the proxy from keeping client connections
>>>> alive.
>>>> The "connection: close" sent by the proxy to the server only indicates
>>>> that
>>>> the proxy will send just one request to the server, not that it does not
>>>> care about the response length.  The same is true when that proxy
>>>> caches.
>>>> Without any content-length nor chunked encoding, the cache could store
>>>> and
>>>> distribute truncated response believing they are complete, while this
>>>> would
>>>> not happen with chunked encoding because the cache will be able to know
>>>> it
>>>> has not seen the end of the response.
>>>>
>>>> The fix seems easy.  This is the patch:
>>>>
>>>> Index: java/org/apache/coyote/http11/Http11Processor.java
>>>> ===================================================================
>>>> --- java/org/apache/coyote/http11/Http11Processor.java    Tue Mar 09
>>>> 18:09:50 CET 2010
>>>> +++ java/org/apache/coyote/http11/Http11Processor.java    Tue Mar 09
>>>> 18:09:50 CET 2010
>>>> @@ -1547,7 +1547,7 @@
>>>>                  (outputFilters[Constants.IDENTITY_FILTER]);
>>>>              contentDelimitation = true;
>>>>          } else {
>>>> -            if (entityBody&&   http11&&   keepAlive) {
>>>> +            if (entityBody&&   http11) {
>>>>                  outputBuffer.addActiveFilter
>>>>                      (outputFilters[Constants.CHUNKED_FILTER]);
>>>>                  contentDelimitation = true;
>>>>
>>>>
>>>> What do you think ?
>>>>
>>>> Regards,
>>>> Oscar Frias
>>>> Trabber.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Re: Chunked encoding should be used also when not using keepalive

Posted by Mark Thomas <ma...@apache.org>.
On 02/04/2010 18:30, Costin Manolache wrote:
> The question is what to use by default - yes, the spec allows you to use
> either.
>
> Closing the connection has the benefit of saving few bytes on network and
> maybe few cycles on server.
>
> Chunked has the benefit of better detecting failures - since a close could
> happen for other reasons besides normal end. Seems like a good deal to me.

That was my instinct but I wanted some hard numbers to back it up. After 
dealing with various networking issues associated with the rate the 
connections are created and destroyed in a test where there is no 
keep-alive, I was able to complete some tests using:
ab -n 100000 -c 1 http://localhost:8080/index.html

With and without the proposed patch requests were being handled in the 
4400 to 4500 requests per second range with no discernible difference 
between the two.

Therefore, I am going to apply the patch to 7.0.x and propose it for 
6.0.x and 5.5.x on the grounds that it adds benefit for no detectable 
overhead.

Mark

>
> Costin
>
> On Fri, Apr 2, 2010 at 8:46 AM, Filip Hanik - Dev Lists
> <de...@hanik.com>wrote:
>
>> so the spec says, use apples or oranges, we use oranges, and you want
>> apples
>>
>> my suggestion would be to write a filter and set the chunked header
>> yourself
>>
>>
>> On 04/02/2010 09:25 AM, Óscar Frías Barranco wrote:
>>
>>> Ok, but it does not say that chunked encoding cannot be used when closing
>>> the connection.
>>>
>>> In fact chunked encoding takes precedence over connection close in the
>>> determination of the transfer-length:
>>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
>>>
>>> Oscar
>>>
>>>
>>> On Fri, Apr 2, 2010 at 17:09, Filip Hanik - Dev Lists<devlists@hanik.com
>>>> wrote:
>>>
>>>
>>>
>>>> The HTTP spec says that when you close the connection, that is the
>>>> delimiter for the content.
>>>>
>>>> Filip
>>>>
>>>>
>>>> On 04/01/2010 04:02 AM, Óscar Frías Barranco wrote:
>>>>
>>>>
>>>>
>>>>> Hello.
>>>>>
>>>>> Currently Tomcat HTTP 1.1 Connector disables the use of chunked encoding
>>>>> if
>>>>> keepalive is not used.  This happens when an HTTP 1.1 request contains a
>>>>> "Connection: close" header.
>>>>> I propose to change Coyote to use chunked encoding (for HTTP 1.1) even
>>>>> if
>>>>> keepalive is disabled.
>>>>>
>>>>> Chunked transfer-encoding is an alternative to content-length, for use
>>>>> when
>>>>> the content-length cannot initially be determined.  While it is
>>>>> mandatory
>>>>> to
>>>>> have either of them to support keep-alive, its use is not restricted to
>>>>> keep-alive and one useful immediate benefit of using it is to allow a
>>>>> client
>>>>> to distinguish a connection abort from a complete response in order to
>>>>> avoid
>>>>> storing truncated data.
>>>>>
>>>>> Another useful case is when a reverse-proxy is installed in front of the
>>>>> server, and this reverse proxy tries to maintain keep-alive connections
>>>>> with
>>>>> the clients and intends to close the connections with the servers (like
>>>>> apache 1.3, haproxy, and I think nginx).  The lack of content-length and
>>>>> chunked encoding prevents the proxy from keeping client connections
>>>>> alive.
>>>>> The "connection: close" sent by the proxy to the server only indicates
>>>>> that
>>>>> the proxy will send just one request to the server, not that it does not
>>>>> care about the response length.  The same is true when that proxy
>>>>> caches.
>>>>> Without any content-length nor chunked encoding, the cache could store
>>>>> and
>>>>> distribute truncated response believing they are complete, while this
>>>>> would
>>>>> not happen with chunked encoding because the cache will be able to know
>>>>> it
>>>>> has not seen the end of the response.
>>>>>
>>>>> The fix seems easy.  This is the patch:
>>>>>
>>>>> Index: java/org/apache/coyote/http11/Http11Processor.java
>>>>> ===================================================================
>>>>> --- java/org/apache/coyote/http11/Http11Processor.java    Tue Mar 09
>>>>> 18:09:50 CET 2010
>>>>> +++ java/org/apache/coyote/http11/Http11Processor.java    Tue Mar 09
>>>>> 18:09:50 CET 2010
>>>>> @@ -1547,7 +1547,7 @@
>>>>>                   (outputFilters[Constants.IDENTITY_FILTER]);
>>>>>               contentDelimitation = true;
>>>>>           } else {
>>>>> -            if (entityBody&&    http11&&    keepAlive) {
>>>>> +            if (entityBody&&    http11) {
>>>>>                   outputBuffer.addActiveFilter
>>>>>                       (outputFilters[Constants.CHUNKED_FILTER]);
>>>>>                   contentDelimitation = true;
>>>>>
>>>>>
>>>>> What do you think ?
>>>>>
>>>>> Regards,
>>>>> Oscar Frias
>>>>> Trabber.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: Chunked encoding should be used also when not using keepalive

Posted by Costin Manolache <co...@gmail.com>.
The question is what to use by default - yes, the spec allows you to use
either.

Closing the connection has the benefit of saving few bytes on network and
maybe few cycles on server.

Chunked has the benefit of better detecting failures - since a close could
happen for other reasons besides normal end. Seems like a good deal to me.

Costin

On Fri, Apr 2, 2010 at 8:46 AM, Filip Hanik - Dev Lists
<de...@hanik.com>wrote:

> so the spec says, use apples or oranges, we use oranges, and you want
> apples
>
> my suggestion would be to write a filter and set the chunked header
> yourself
>
>
> On 04/02/2010 09:25 AM, Óscar Frías Barranco wrote:
>
>> Ok, but it does not say that chunked encoding cannot be used when closing
>> the connection.
>>
>> In fact chunked encoding takes precedence over connection close in the
>> determination of the transfer-length:
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
>>
>> Oscar
>>
>>
>> On Fri, Apr 2, 2010 at 17:09, Filip Hanik - Dev Lists<devlists@hanik.com
>> >wrote:
>>
>>
>>
>>> The HTTP spec says that when you close the connection, that is the
>>> delimiter for the content.
>>>
>>> Filip
>>>
>>>
>>> On 04/01/2010 04:02 AM, Óscar Frías Barranco wrote:
>>>
>>>
>>>
>>>> Hello.
>>>>
>>>> Currently Tomcat HTTP 1.1 Connector disables the use of chunked encoding
>>>> if
>>>> keepalive is not used.  This happens when an HTTP 1.1 request contains a
>>>> "Connection: close" header.
>>>> I propose to change Coyote to use chunked encoding (for HTTP 1.1) even
>>>> if
>>>> keepalive is disabled.
>>>>
>>>> Chunked transfer-encoding is an alternative to content-length, for use
>>>> when
>>>> the content-length cannot initially be determined.  While it is
>>>> mandatory
>>>> to
>>>> have either of them to support keep-alive, its use is not restricted to
>>>> keep-alive and one useful immediate benefit of using it is to allow a
>>>> client
>>>> to distinguish a connection abort from a complete response in order to
>>>> avoid
>>>> storing truncated data.
>>>>
>>>> Another useful case is when a reverse-proxy is installed in front of the
>>>> server, and this reverse proxy tries to maintain keep-alive connections
>>>> with
>>>> the clients and intends to close the connections with the servers (like
>>>> apache 1.3, haproxy, and I think nginx).  The lack of content-length and
>>>> chunked encoding prevents the proxy from keeping client connections
>>>> alive.
>>>> The "connection: close" sent by the proxy to the server only indicates
>>>> that
>>>> the proxy will send just one request to the server, not that it does not
>>>> care about the response length.  The same is true when that proxy
>>>> caches.
>>>> Without any content-length nor chunked encoding, the cache could store
>>>> and
>>>> distribute truncated response believing they are complete, while this
>>>> would
>>>> not happen with chunked encoding because the cache will be able to know
>>>> it
>>>> has not seen the end of the response.
>>>>
>>>> The fix seems easy.  This is the patch:
>>>>
>>>> Index: java/org/apache/coyote/http11/Http11Processor.java
>>>> ===================================================================
>>>> --- java/org/apache/coyote/http11/Http11Processor.java    Tue Mar 09
>>>> 18:09:50 CET 2010
>>>> +++ java/org/apache/coyote/http11/Http11Processor.java    Tue Mar 09
>>>> 18:09:50 CET 2010
>>>> @@ -1547,7 +1547,7 @@
>>>>                  (outputFilters[Constants.IDENTITY_FILTER]);
>>>>              contentDelimitation = true;
>>>>          } else {
>>>> -            if (entityBody&&   http11&&   keepAlive) {
>>>> +            if (entityBody&&   http11) {
>>>>                  outputBuffer.addActiveFilter
>>>>                      (outputFilters[Constants.CHUNKED_FILTER]);
>>>>                  contentDelimitation = true;
>>>>
>>>>
>>>> What do you think ?
>>>>
>>>> Regards,
>>>> Oscar Frias
>>>> Trabber.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Re: Chunked encoding should be used also when not using keepalive

Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
so the spec says, use apples or oranges, we use oranges, and you want apples

my suggestion would be to write a filter and set the chunked header yourself

On 04/02/2010 09:25 AM, Óscar Frías Barranco wrote:
> Ok, but it does not say that chunked encoding cannot be used when closing
> the connection.
>
> In fact chunked encoding takes precedence over connection close in the
> determination of the transfer-length:
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
>
> Oscar
>
>
> On Fri, Apr 2, 2010 at 17:09, Filip Hanik - Dev Lists<de...@hanik.com>wrote:
>
>    
>> The HTTP spec says that when you close the connection, that is the
>> delimiter for the content.
>>
>> Filip
>>
>>
>> On 04/01/2010 04:02 AM, Óscar Frías Barranco wrote:
>>
>>      
>>> Hello.
>>>
>>> Currently Tomcat HTTP 1.1 Connector disables the use of chunked encoding
>>> if
>>> keepalive is not used.  This happens when an HTTP 1.1 request contains a
>>> "Connection: close" header.
>>> I propose to change Coyote to use chunked encoding (for HTTP 1.1) even if
>>> keepalive is disabled.
>>>
>>> Chunked transfer-encoding is an alternative to content-length, for use
>>> when
>>> the content-length cannot initially be determined.  While it is mandatory
>>> to
>>> have either of them to support keep-alive, its use is not restricted to
>>> keep-alive and one useful immediate benefit of using it is to allow a
>>> client
>>> to distinguish a connection abort from a complete response in order to
>>> avoid
>>> storing truncated data.
>>>
>>> Another useful case is when a reverse-proxy is installed in front of the
>>> server, and this reverse proxy tries to maintain keep-alive connections
>>> with
>>> the clients and intends to close the connections with the servers (like
>>> apache 1.3, haproxy, and I think nginx).  The lack of content-length and
>>> chunked encoding prevents the proxy from keeping client connections alive.
>>> The "connection: close" sent by the proxy to the server only indicates
>>> that
>>> the proxy will send just one request to the server, not that it does not
>>> care about the response length.  The same is true when that proxy caches.
>>> Without any content-length nor chunked encoding, the cache could store and
>>> distribute truncated response believing they are complete, while this
>>> would
>>> not happen with chunked encoding because the cache will be able to know it
>>> has not seen the end of the response.
>>>
>>> The fix seems easy.  This is the patch:
>>>
>>> Index: java/org/apache/coyote/http11/Http11Processor.java
>>> ===================================================================
>>> --- java/org/apache/coyote/http11/Http11Processor.java    Tue Mar 09
>>> 18:09:50 CET 2010
>>> +++ java/org/apache/coyote/http11/Http11Processor.java    Tue Mar 09
>>> 18:09:50 CET 2010
>>> @@ -1547,7 +1547,7 @@
>>>                   (outputFilters[Constants.IDENTITY_FILTER]);
>>>               contentDelimitation = true;
>>>           } else {
>>> -            if (entityBody&&   http11&&   keepAlive) {
>>> +            if (entityBody&&   http11) {
>>>                   outputBuffer.addActiveFilter
>>>                       (outputFilters[Constants.CHUNKED_FILTER]);
>>>                   contentDelimitation = true;
>>>
>>>
>>> What do you think ?
>>>
>>> Regards,
>>> Oscar Frias
>>> Trabber.com
>>>
>>>
>>>
>>>        
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>>      
>    


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: Chunked encoding should be used also when not using keepalive

Posted by Óscar Frías Barranco <of...@trabber.com>.
Ok, but it does not say that chunked encoding cannot be used when closing
the connection.

In fact chunked encoding takes precedence over connection close in the
determination of the transfer-length:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4

Oscar


On Fri, Apr 2, 2010 at 17:09, Filip Hanik - Dev Lists <de...@hanik.com>wrote:

> The HTTP spec says that when you close the connection, that is the
> delimiter for the content.
>
> Filip
>
>
> On 04/01/2010 04:02 AM, Óscar Frías Barranco wrote:
>
>> Hello.
>>
>> Currently Tomcat HTTP 1.1 Connector disables the use of chunked encoding
>> if
>> keepalive is not used.  This happens when an HTTP 1.1 request contains a
>> "Connection: close" header.
>> I propose to change Coyote to use chunked encoding (for HTTP 1.1) even if
>> keepalive is disabled.
>>
>> Chunked transfer-encoding is an alternative to content-length, for use
>> when
>> the content-length cannot initially be determined.  While it is mandatory
>> to
>> have either of them to support keep-alive, its use is not restricted to
>> keep-alive and one useful immediate benefit of using it is to allow a
>> client
>> to distinguish a connection abort from a complete response in order to
>> avoid
>> storing truncated data.
>>
>> Another useful case is when a reverse-proxy is installed in front of the
>> server, and this reverse proxy tries to maintain keep-alive connections
>> with
>> the clients and intends to close the connections with the servers (like
>> apache 1.3, haproxy, and I think nginx).  The lack of content-length and
>> chunked encoding prevents the proxy from keeping client connections alive.
>> The "connection: close" sent by the proxy to the server only indicates
>> that
>> the proxy will send just one request to the server, not that it does not
>> care about the response length.  The same is true when that proxy caches.
>> Without any content-length nor chunked encoding, the cache could store and
>> distribute truncated response believing they are complete, while this
>> would
>> not happen with chunked encoding because the cache will be able to know it
>> has not seen the end of the response.
>>
>> The fix seems easy.  This is the patch:
>>
>> Index: java/org/apache/coyote/http11/Http11Processor.java
>> ===================================================================
>> --- java/org/apache/coyote/http11/Http11Processor.java    Tue Mar 09
>> 18:09:50 CET 2010
>> +++ java/org/apache/coyote/http11/Http11Processor.java    Tue Mar 09
>> 18:09:50 CET 2010
>> @@ -1547,7 +1547,7 @@
>>                  (outputFilters[Constants.IDENTITY_FILTER]);
>>              contentDelimitation = true;
>>          } else {
>> -            if (entityBody&&  http11&&  keepAlive) {
>> +            if (entityBody&&  http11) {
>>                  outputBuffer.addActiveFilter
>>                      (outputFilters[Constants.CHUNKED_FILTER]);
>>                  contentDelimitation = true;
>>
>>
>> What do you think ?
>>
>> Regards,
>> Oscar Frias
>> Trabber.com
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Re: Chunked encoding should be used also when not using keepalive

Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
The HTTP spec says that when you close the connection, that is the 
delimiter for the content.

Filip

On 04/01/2010 04:02 AM, Óscar Frías Barranco wrote:
> Hello.
>
> Currently Tomcat HTTP 1.1 Connector disables the use of chunked encoding if
> keepalive is not used.  This happens when an HTTP 1.1 request contains a
> "Connection: close" header.
> I propose to change Coyote to use chunked encoding (for HTTP 1.1) even if
> keepalive is disabled.
>
> Chunked transfer-encoding is an alternative to content-length, for use when
> the content-length cannot initially be determined.  While it is mandatory to
> have either of them to support keep-alive, its use is not restricted to
> keep-alive and one useful immediate benefit of using it is to allow a client
> to distinguish a connection abort from a complete response in order to avoid
> storing truncated data.
>
> Another useful case is when a reverse-proxy is installed in front of the
> server, and this reverse proxy tries to maintain keep-alive connections with
> the clients and intends to close the connections with the servers (like
> apache 1.3, haproxy, and I think nginx).  The lack of content-length and
> chunked encoding prevents the proxy from keeping client connections alive.
> The "connection: close" sent by the proxy to the server only indicates that
> the proxy will send just one request to the server, not that it does not
> care about the response length.  The same is true when that proxy caches.
> Without any content-length nor chunked encoding, the cache could store and
> distribute truncated response believing they are complete, while this would
> not happen with chunked encoding because the cache will be able to know it
> has not seen the end of the response.
>
> The fix seems easy.  This is the patch:
>
> Index: java/org/apache/coyote/http11/Http11Processor.java
> ===================================================================
> --- java/org/apache/coyote/http11/Http11Processor.java    Tue Mar 09
> 18:09:50 CET 2010
> +++ java/org/apache/coyote/http11/Http11Processor.java    Tue Mar 09
> 18:09:50 CET 2010
> @@ -1547,7 +1547,7 @@
>                   (outputFilters[Constants.IDENTITY_FILTER]);
>               contentDelimitation = true;
>           } else {
> -            if (entityBody&&  http11&&  keepAlive) {
> +            if (entityBody&&  http11) {
>                   outputBuffer.addActiveFilter
>                       (outputFilters[Constants.CHUNKED_FILTER]);
>                   contentDelimitation = true;
>
>
> What do you think ?
>
> Regards,
> Oscar Frias
> Trabber.com
>
>    


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: Chunked encoding should be used also when not using keepalive

Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
On 04/01/2010 07:43 AM, Costin Manolache wrote:
> +1 on switching to chunked by default.
>    

can't you achieve this through a filter?

Filip

> I don't think the extra few bytes are a problem ( or few extra
> objects/cycles on server ) - at least compared with not knowing if the
> response was really fully sent.
>
> Costin
>
> 2010/4/1 Óscar Frías Barranco<of...@trabber.com>
>
>    
>> Hello.
>>
>> Currently Tomcat HTTP 1.1 Connector disables the use of chunked encoding if
>> keepalive is not used.  This happens when an HTTP 1.1 request contains a
>> "Connection: close" header.
>> I propose to change Coyote to use chunked encoding (for HTTP 1.1) even if
>> keepalive is disabled.
>>
>> Chunked transfer-encoding is an alternative to content-length, for use when
>> the content-length cannot initially be determined.  While it is mandatory
>> to
>> have either of them to support keep-alive, its use is not restricted to
>> keep-alive and one useful immediate benefit of using it is to allow a
>> client
>> to distinguish a connection abort from a complete response in order to
>> avoid
>> storing truncated data.
>>
>> Another useful case is when a reverse-proxy is installed in front of the
>> server, and this reverse proxy tries to maintain keep-alive connections
>> with
>> the clients and intends to close the connections with the servers (like
>> apache 1.3, haproxy, and I think nginx).  The lack of content-length and
>> chunked encoding prevents the proxy from keeping client connections alive.
>> The "connection: close" sent by the proxy to the server only indicates that
>> the proxy will send just one request to the server, not that it does not
>> care about the response length.  The same is true when that proxy caches.
>> Without any content-length nor chunked encoding, the cache could store and
>> distribute truncated response believing they are complete, while this would
>> not happen with chunked encoding because the cache will be able to know it
>> has not seen the end of the response.
>>
>> The fix seems easy.  This is the patch:
>>
>> Index: java/org/apache/coyote/http11/Http11Processor.java
>> ===================================================================
>> --- java/org/apache/coyote/http11/Http11Processor.java    Tue Mar 09
>> 18:09:50 CET 2010
>> +++ java/org/apache/coyote/http11/Http11Processor.java    Tue Mar 09
>> 18:09:50 CET 2010
>> @@ -1547,7 +1547,7 @@
>>                  (outputFilters[Constants.IDENTITY_FILTER]);
>>              contentDelimitation = true;
>>          } else {
>> -            if (entityBody&&  http11&&  keepAlive) {
>> +            if (entityBody&&  http11) {
>>                  outputBuffer.addActiveFilter
>>                      (outputFilters[Constants.CHUNKED_FILTER]);
>>                  contentDelimitation = true;
>>
>>
>> What do you think ?
>>
>> Regards,
>> Oscar Frias
>> Trabber.com
>>
>>      
>    


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: Chunked encoding should be used also when not using keepalive

Posted by Costin Manolache <co...@gmail.com>.
+1 on switching to chunked by default.

I don't think the extra few bytes are a problem ( or few extra
objects/cycles on server ) - at least compared with not knowing if the
response was really fully sent.

Costin

2010/4/1 Óscar Frías Barranco <of...@trabber.com>

> Hello.
>
> Currently Tomcat HTTP 1.1 Connector disables the use of chunked encoding if
> keepalive is not used.  This happens when an HTTP 1.1 request contains a
> "Connection: close" header.
> I propose to change Coyote to use chunked encoding (for HTTP 1.1) even if
> keepalive is disabled.
>
> Chunked transfer-encoding is an alternative to content-length, for use when
> the content-length cannot initially be determined.  While it is mandatory
> to
> have either of them to support keep-alive, its use is not restricted to
> keep-alive and one useful immediate benefit of using it is to allow a
> client
> to distinguish a connection abort from a complete response in order to
> avoid
> storing truncated data.
>
> Another useful case is when a reverse-proxy is installed in front of the
> server, and this reverse proxy tries to maintain keep-alive connections
> with
> the clients and intends to close the connections with the servers (like
> apache 1.3, haproxy, and I think nginx).  The lack of content-length and
> chunked encoding prevents the proxy from keeping client connections alive.
> The "connection: close" sent by the proxy to the server only indicates that
> the proxy will send just one request to the server, not that it does not
> care about the response length.  The same is true when that proxy caches.
> Without any content-length nor chunked encoding, the cache could store and
> distribute truncated response believing they are complete, while this would
> not happen with chunked encoding because the cache will be able to know it
> has not seen the end of the response.
>
> The fix seems easy.  This is the patch:
>
> Index: java/org/apache/coyote/http11/Http11Processor.java
> ===================================================================
> --- java/org/apache/coyote/http11/Http11Processor.java    Tue Mar 09
> 18:09:50 CET 2010
> +++ java/org/apache/coyote/http11/Http11Processor.java    Tue Mar 09
> 18:09:50 CET 2010
> @@ -1547,7 +1547,7 @@
>                 (outputFilters[Constants.IDENTITY_FILTER]);
>             contentDelimitation = true;
>         } else {
> -            if (entityBody && http11 && keepAlive) {
> +            if (entityBody && http11) {
>                 outputBuffer.addActiveFilter
>                     (outputFilters[Constants.CHUNKED_FILTER]);
>                 contentDelimitation = true;
>
>
> What do you think ?
>
> Regards,
> Oscar Frias
> Trabber.com
>

Re: Chunked encoding should be used also when not using keepalive

Posted by Óscar Frías Barranco <of...@trabber.com>.
On Thu, Apr 1, 2010 at 12:39, Remy Maucherat <re...@apache.org> wrote:

>
> His reverse proxy argument is probably the worst one: "connection:
> close" does not land in the response by accident, it is added for good
> reason. This is just begging for hacks at this point.
>


Sorry, I will try to clarify this point.  Tomcat adding the "connection:
close" header in the response is not the problem.  Problem is that as the
response (from Tomcat to the reverse proxy) does not contain a
Content-Length and is not chunked, it cannot be included in a keepalived
connection from the reverse proxy to the client.

Re: Chunked encoding should be used also when not using keepalive

Posted by Óscar Frías Barranco <of...@trabber.com>.
On Thu, Apr 1, 2010 at 12:52, Mark Thomas <ma...@apache.org> wrote:

> So it comes down to "Is the extra expense of chunked encoding a price
> worth paying so UAs and proxies can tell if a response was unexpectedly
> truncated, eg due to network error?"
>
> I don't have any hard figures (I'll see if I can come up with some) but
> my instinct is that this would be a price worth paying.
>


I forgot to mention that Apache HTTP Server uses chunked encoding also when
it receives a "Connection: close" header.
I do not know if they analized the trade-off but in any case this is what
they do.

Oscar

Re: Chunked encoding should be used also when not using keepalive

Posted by Mark Thomas <ma...@apache.org>.
On 01/04/2010 11:39, Remy Maucherat wrote:
> On Thu, 2010-04-01 at 11:28 +0100, Mark Thomas wrote:
>> On 01/04/2010 11:02, Óscar Frías Barranco wrote:
>>> What do you think ?
>>
>> Seems reasonable but I'd like to hear from some of the other committers
>> before making any changes.
>>
>> If the change is made, it needs to be made for all connectors, not just
>> the BIO connector.
> 
> It is not needed in the spec and is more expensive, as closing the
> connection is one of the valid content delimitation methods.

So it comes down to "Is the extra expense of chunked encoding a price
worth paying so UAs and proxies can tell if a response was unexpectedly
truncated, eg due to network error?"

I don't have any hard figures (I'll see if I can come up with some) but
my instinct is that this would be a price worth paying.

Mark



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: Chunked encoding should be used also when not using keepalive

Posted by Tim Funk <fu...@apache.org>.
OMG ... That is the argument made in the original request. (I need to 
re-read and think more before response) I'm really sorry for the noise, 
worst april 1 ever. Please put me on /ignore for the rest of the day.

My opinion on the change is +0. (The change has some penalties, but the 
net effect might be good)


-Tim

On 4/1/2010 6:54 AM, Tim Funk wrote:
> A good argument to add is chunked encoding would that it gives the
> client the best guess on whether the entire response was returned (by
> receiving the last full chunk). But that argument is weak.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: Chunked encoding should be used also when not using keepalive

Posted by Tim Funk <fu...@apache.org>.
Agree with Remy. If 'connection: close' is sent by the client, then 
tomcat needs to close the connection on the end of the response. So 
sending the results via chunked encoding is extra overhead which is not 
needed.

A good argument to add is chunked encoding would that it gives the 
client the best guess on whether the entire response was returned (by 
receiving the last full chunk). But that argument is weak.

-Tim

On 4/1/2010 6:39 AM, Remy Maucherat wrote:
> On Thu, 2010-04-01 at 11:28 +0100, Mark Thomas wrote:
>> On 01/04/2010 11:02, Óscar Frías Barranco wrote:
>>> What do you think ?
>>
>> Seems reasonable but I'd like to hear from some of the other committers
>> before making any changes.
>>
>> If the change is made, it needs to be made for all connectors, not just
>> the BIO connector.
>
> It is not needed in the spec and is more expensive, as closing the
> connection is one of the valid content delimitation methods.
>
> His reverse proxy argument is probably the worst one: "connection:
> close" does not land in the response by accident, it is added for good
> reason. This is just begging for hacks at this point.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: Chunked encoding should be used also when not using keepalive

Posted by Remy Maucherat <re...@apache.org>.
On Thu, 2010-04-01 at 11:28 +0100, Mark Thomas wrote:
> On 01/04/2010 11:02, Óscar Frías Barranco wrote:
> > What do you think ?
> 
> Seems reasonable but I'd like to hear from some of the other committers
> before making any changes.
> 
> If the change is made, it needs to be made for all connectors, not just
> the BIO connector.

It is not needed in the spec and is more expensive, as closing the
connection is one of the valid content delimitation methods.

His reverse proxy argument is probably the worst one: "connection:
close" does not land in the response by accident, it is added for good
reason. This is just begging for hacks at this point.

Rémy



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: Chunked encoding should be used also when not using keepalive

Posted by Mark Thomas <ma...@apache.org>.
On 01/04/2010 11:02, Óscar Frías Barranco wrote:
> What do you think ?

Seems reasonable but I'd like to hear from some of the other committers
before making any changes.

If the change is made, it needs to be made for all connectors, not just
the BIO connector.

Mark



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org