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