Re: http-server-close problem (also with Tomcat backend)

I have "forwarded" the issue (with your explanation, thank you Willy) to Tomcat developers mailing list and it has got several replies, maybe you want to participate:

http://marc.info/?t=127011623400002&r=1&w=2

Regards,
Óscar

2010/4/1 Willy Tarreau <w#1wt.eu>

> Hi Oscar,
>
> On Wed, Mar 31, 2010 at 07:15:34PM +0200, Óscar Frías Barranco wrote:
> > I have been looking at Tomcat source code and apparently it looks like
> there
> > is an easy fix.
>
> That's good news !
>
> > Here is the class where the logic is implemented:
> >
> http://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java
> >
> > And this is the patch that I have generated:
> >
> > 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;
>
> Indeed, eventhough I generally don't read Java code, this one
> looks obviously right :-)
>
> > I would like to send this to Tomcat mailing list, but if we want this
> change
> > to be implemented I think that we must explain which are the benefits of
> > using chunked encoding also when not using keepalive.
> > Willy, could you help me with this ?
>
> Yes, I will try :-)
>
> 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.
>
> Hoping this helps !
> Anyway, if Cyril's workaround works, I'll merge it because Tomcat
> is probably not the only component affected by that. That way we'd
> be able to enable it when needed.
>
> Willy
>
>
Received on 2010/04/01 13:03