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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
On Thu, Apr 1, 2010 at 12:39, Remy Maucherat r...@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
+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 ofr...@trabber.com
Hello.
Currently Tomcat HTTP
17 matches
Mail list logo
