Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <4E85832A.2020908@ice-sa.com>
Date: Fri, 30 Sep 2011 10:51:54 +0200
From: =?ISO-8859-15?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Tomcat 7.0.6 FIN_WAIT2 Connections and Connection Keep-Alive
References: 
 <CAHajmmCqNMib8DSJi8Rtfi8EokzRayN5K5r1Fe2bPncYSrtYRQ@mail.gmail.com><4E84AF9A.9060503@kippdata.de>
 <CAHajmmDsLANJfHHjRfOx=M2K=5as2ECFEQC-WpezrCyCZhj8MA@mail.gmail.com>
 <4E8572B8.6090005@kippdata.de>
In-Reply-To: <4E8572B8.6090005@kippdata.de>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Rainer Jung wrote:
> On 29.09.2011 22:49, rapponcape wrote:
>>> Aha, the client is using HTTP 1.0 and not 1.1. This could be one reason
>>> for Tomcat closing the connection. See below.
>>>
>> When I reconfigure and put Apache in front of Tomcat and use a jkmount with
>> AJP connector, response is normal and without error.  Appears to only happen
>> when tomcat is standalone.
> 
> Could be the answer is small enough, that Apache can buffer it and send
> without chunked encoding. Don't know.
> 
>>>> You see: no Content-Length header. I
>> I do see Content-Length in the POST header
> 
> You cut out the relevant part. I was talkingabout the Tomcat answer, you
> saw it in the client request. That's now the same ;)
> 
> Rainer
> 
rapponcape,

to clarify maybe the discussion and answers which you have received so far :

1) Your clients, in their requests, indicate a protocol level HTTP/1.0.
If you read RFC2616 (HTTP 1.1), you will see that for HTTP 1.0, the persistent 
("keep-alive") kind of connection is not very well defined.
Keep-alive connections are only well-defined and supported in HTTP/1.1.

Consequently, a HTTP/1.1-capable server (like Apache httpd and Tomcat), upon receiving a 
request specifying HTTP/1.0, cannot assume that the client really knows how to handle this 
properly, and /can/ decide to not honor the desire for keep-alive connections, and close 
the connection after every response.
In this case, it appears that Apache httpd may follow one behaviour, and Tomcat the other.
Other webservers may choose to do either one or the other.
(Both behaviours are allowed by the RFC).

The point is : if your client wants to increase its chances to get a keep-alive 
connection, then it should use HTTP/1.1, not HTTP/1.0.

2) When your client connects to Apache httpd, and httpd serves as a proxy to Tomcat, there 
are two independent connections :

client <-- (1) --> Apache httpd + mod_jk <-- (2) ---> Tomcat

It is allowed for (Apache httpd + mod_jk) to make a proxy connection (2) to Tomcat using a 
HTTP 1.1 protocol level, allowing for persistent connections, even if on the other side 
(1) the connection is HTTP/1.0 and not persistent.
(In fact, here this is pretty much irrelevant, since the connection (2) is made under the 
AJP protocol, not HTTP.  And mod_jk will always try to use persistent connections to 
Tomcat, for efficiency).

So it is very possible that your client sees a different behaviour when it talk to Apache 
httpd, compared to when it talks to Tomcat directly.
But that is because your client indicates that it wants a protocol level HTTP/1.0.

So, in summary :
- Apache httpd and Tomcat are right, because they follow the RFC
- your client is wrong, inasmuch as it has an unfounded expectation, using HTTP/1.0, to 
actually get a persistent connection when it asks for it.

It should be added that, even under HTTP/1.1, there is no guarantee for the client that 
when it asks for a persistent connection, it will actually get one.  The HTTP 1.1 server 
can still decide to close the connection after the response, for a variety of reasons.
But let's say that it would have a much better chance.

And let's leave the question of chunked responses for the next step.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org