tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Óscar Frías Barranco <ofr...@trabber.com>
Subject Re: Chunked encoding should be used also when not using keepalive
Date Fri, 02 Apr 2010 15:55:12 GMT
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 <devlists@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message