On Fri, Sep 30, 2011 at 4:51 AM, André Warnier <a...@ice-sa.com> wrote:
> 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.
Very helpful detail.
It would be nice to see Tomcat react similarly to how Apache reacts to
HTTP/1.0 messages that specify Keep-Alive and Content Length. From
Apache docs...
"For HTTP/1.0 clients, Keep-Alive connections will only be used if
they are specifically requested by a client. In addition, a Keep-Alive
connection with an HTTP/1.0 client can only be used when the length of
the content is known in advance."
Thanks all.
-wr
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
