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 <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 > >
