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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
