On Fri, Sep 30, 2011 at 11:34 AM, André Warnier <a...@ice-sa.com> wrote:
> rapponcape wrote:
>>
>> 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."
>>
> Sorry to insist, but do you really understand the implications of the 2d
> phrase above ?
> Is your Tomcat application setting a content-length /in its response/ ?
>
No, my app does not set/send a content length header. The remote hosts
posting to my app send content length header details, but, my app does not.
.................................remote host's
post.................................
POST /myapp HTTP/1.0
HOST: 10.3.4.7:8080
Connection: Keep-Alive
Authorization: Basic Y2VybmVyOnlpbiZ5YW5n
Content-type: multipart/form-data; boundary=----------1509627285
Content-Length: 66632
------------1509627285
Content-Disposition: form-data; name="xml"
.................................my app's
response.................................
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Date: Mon, 26 Sep 2011 12:39:44 GMT
Connection: close
<?xml version="1.0"?><log><info><stat>OK</stat></info></log>
=========================================================
It appears that I'll have to go back to using Apache to proxy these
requests to get
keep-alive behavior to function with these clients.
-wr
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
