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 clos
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
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 wrote:
> so the spe
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.
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,
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 requ
On 04/01/2010 07:43 AM, Costin Manolache wrote:
+1 on switching to chunked by default.
can't you achieve this through a filter?
Filip
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
+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
> Hello.
>
> Currently Tomcat HTTP 1.1 Connector dis
On Thu, Apr 1, 2010 at 12:39, Remy Maucherat 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 this point.
On Thu, Apr 1, 2010 at 12:52, Mark Thomas 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 come up wi
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 effect
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 the
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 cha
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. So
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 the
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 connecto
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
---
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
18 matches
Mail list logo
