Am 2020-04-20 um 11:32 schrieb Mark Thomas:
On 20/04/2020 09:52, Michael Osipov wrote:
Am 2020-04-19 um 17:32 schrieb Rainer Jung:
Hi Michael,
Am 19.04.2020 um 17:11 schrieb Michael Osipov:
Am 2020-04-19 um 14:40 schrieb Rainer Jung:
I observed this when using Apache mod_proxy_http and
mod_proxy_balancer with ping=5000, which wil add the expectation to
any POST request. I wanted to tune Apache/Tomcat communication to
use connections very long in order to reduce TLS handshakes during
the servers. It turned out, that because the application always does
redirect-after-POST and due to the above described TC behavior, the
effective reuse for the connections was very small.
Regardless of the problem itself. Why does the module modify the
request? Isn't the ping supposed to work via HEAD with expect:
100-continue at most?
Not that I am aware of. AFAIK the expectation is only allowed for
requests with bodies.
That's nonsense from my side. Mental disconception.
That's what I see when applying patches to mod_proxy_http recently.
That would be a surpsise to me, especially after checking trunk and
2.4 now again. Any code citation? Note I am talking about
mod_proxy_http ping, not the AJP one and not the H2 one.
I'd need to go more deeply into the code, but from my memory I discussed
aspects from this in BZ 63626 with Rüdiger and Yann. I may be wrong, of
course!
Some clients don't even handle the expect header, like browsers.
Not a question of clients here. They do not have to support it for the
reverse proxy ping feature. It only changes communication between
proxy and back end, the client will not see a difference.
But that all is not really related to my original question. Why is TC
closing the connection after a successful expectation handling and
fully reading the request body when the application returns a non-2xx
response (eg. a 3xx)?
Right, the question is what qualifies to close a connection if this has
not been done explicitly like from application code or in
#statusDropsConnection().
The comment in that block:
// to ensure that the connection is closed. Some clients may
// still send the body, some may send the next request.
// No way to differentiate, so close the connection to
// force the client to send the next request.
is a safety net from my understanding for misbehaving clients.
That understanding is not correct.
The check is there to avoid security issues. The spec allows the client
to send the request body at any time and the server has no way of
differentiating the client sending the request body vs the client
sending the next request. If the server can't be sure it has received
the entire request body (and hence the next data received must be the
next request) it MUST close the connection for security.
But you are right, there is no reason why it should be closed with a 3xx
at least.
Yes there is. See above.
Thank you for the explanation. So you consider 3xx not to be complete as
2xx to qualify the for connecton closure because the client is supposed
to issue another request on that connection?
If so, you are absolutely right.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
