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.
