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 <devli...@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<devli...@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-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>> >>> >>> >>> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
