You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Rainer Jung <ra...@kippdata.de> on 2020/04/19 12:40:00 UTC
Connection close for POST after successful expectation and status 302
Hi there,
I noticed today TC behavior in TC 9 HEAD (but probably not specific to
it), that a POST with "Expect: 100-Continue" first gets a correct status
100 response from TC. Then the client (an Apache reverse proxy) send the
request body and the application correctly processes it and finally
sends back a 302 redirect as expected for that application.
But code in java/org/apache/coyote/http11/Http11Processor.java now set
keepalive to false which will close the connection. The code in question
is in checkExpectationAndResponseStatus() and gets called from
prepareResponse() and endRequest().
I understand, that when no 100 response is send or the Redirect happens
before the body was completely read, a connection close is correct. But
why should we close the connection after a complete successful
processing of the request/response?
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.
Any opinion on whether this behavior is correct?
Thanks and regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Connection close for POST after successful expectation and status
302
Posted by Mark Thomas <ma...@apache.org>.
On 20/04/2020 10:45, Rainer Jung wrote:
> Hi Mark, hi all,
>
> Am 20.04.2020 um 11:15 schrieb Mark Thomas:
>> On 19/04/2020 14:04, Rainer Jung wrote:
>>> It might be too simplistic, but the following at least stops the
>>> connection close (but I don't know, whether it also prevents it in cases
>>> where it should still be done):
>>>
>>> diff --git a/java/org/apache/coyote/http11/Http11Processor.java
>>> b/java/org/apache/coyote/http11/Http11Processor.java
>>> index aa1569cfdc..f38993b04d 100644
>>> --- a/java/org/apache/coyote/http11/Http11Processor.java
>>> +++ b/java/org/apache/coyote/http11/Http11Processor.java
>>> @@ -513,7 +513,7 @@ public class Http11Processor extends
>>> AbstractProcessor {
>>>
>>>
>>> private void checkExpectationAndResponseStatus() {
>>> - if (request.hasExpectation() &&
>>> + if (request.hasExpectation() && !isRequestBodyFullyRead() &&
>>> (response.getStatus() < 200 || response.getStatus() >
>>> 299)) {
>>> // Client sent Expect: 100-continue but received a
>>> // non-2xx final response. Disable keep-alive (if enabled)
>>>
>>> Regards,
>>>
>>> Rainer
>>
>> That fix looks right to me.
>>
>> The case we need to avoid is keeping keep-alive enabled when the client
>> and the server have a different view of how much of the request body has
>> been read as that can create request injection issues which are
>> particularly problematic behind a reverse proxy.
>>
>> If the server knows it has read the entire body then the client
>> certainly knows it sent the entire body and all is well.
>
> Soooo, what about in addition drop the non 2xx check. Even if we
> returned a 2xx, shouldn't we close if
>
> request.hasExpectation() && !isRequestBodyFullyRead()
>
> It isn't very likely, that an application returns a 2xx before having
> read the body, but the limitation to non-2xx seems a bit artificial.
There are several moving parts here. There is scope for improvement but
we need to be careful not to introduce a security risk.
> Thinking more about it: what is special here about the expectation case?
> If "!isRequestBodyFullyRead()" make sense as a condition term in these
> places, why bother for limiting it to "request.hasExpectation()"?
> Shouldn't then "!isRequestBodyFullyRead()" be the only check and we
> close the connection for any status code and even when we had no
> expectation? Depending on the detailed behavior of
> isRequestBodyFullyRead() we might need to add a check, if the request
> had a body at all. What do you think?
I don't think the above is quite right. Let me try and explain myself
better.
The non-expectation case is simple. If the client declares it is going
to send a request body it has to send one. Tomcat always knows where one
request ends and the next starts.
What makes things different in the expectation case is that it becomes
optional for the client to send the request body without an easy way for
Tomcat to determine (in some cases) if the client intends to send the
body or not. If Tomcat can't tell if a body is going to be sent it can't
tell if the next byte from the client is the request body or the start
of a new request. The only safe option is to close the connection.
In the expectation + 2xx response case, the client has to send the
request body (if it hasn't already done so) unless Tomcat sends
"Connection: close" so Tomcat always knows what the next byte is and it
is safe to use keep alive.
The expectation + non-2xx response case is where I think we can do
better. If we know the request body has already been sent in full, we
know that the next byte will be the start of the next request and it
will be safe to use keep alive. This is essentially what your original
proposal does and I support it.
If the request body hasn't been read we can't tell if the client decided
to sent it or not and in that case we have to close the connection to
protect against request injection.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Connection close for POST after successful expectation and status
302
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Mark, hi all,
Am 20.04.2020 um 11:15 schrieb Mark Thomas:
> On 19/04/2020 14:04, Rainer Jung wrote:
>> It might be too simplistic, but the following at least stops the
>> connection close (but I don't know, whether it also prevents it in cases
>> where it should still be done):
>>
>> diff --git a/java/org/apache/coyote/http11/Http11Processor.java
>> b/java/org/apache/coyote/http11/Http11Processor.java
>> index aa1569cfdc..f38993b04d 100644
>> --- a/java/org/apache/coyote/http11/Http11Processor.java
>> +++ b/java/org/apache/coyote/http11/Http11Processor.java
>> @@ -513,7 +513,7 @@ public class Http11Processor extends
>> AbstractProcessor {
>>
>>
>> private void checkExpectationAndResponseStatus() {
>> - if (request.hasExpectation() &&
>> + if (request.hasExpectation() && !isRequestBodyFullyRead() &&
>> (response.getStatus() < 200 || response.getStatus() >
>> 299)) {
>> // Client sent Expect: 100-continue but received a
>> // non-2xx final response. Disable keep-alive (if enabled)
>>
>> Regards,
>>
>> Rainer
>
> That fix looks right to me.
>
> The case we need to avoid is keeping keep-alive enabled when the client
> and the server have a different view of how much of the request body has
> been read as that can create request injection issues which are
> particularly problematic behind a reverse proxy.
>
> If the server knows it has read the entire body then the client
> certainly knows it sent the entire body and all is well.
Soooo, what about in addition drop the non 2xx check. Even if we
returned a 2xx, shouldn't we close if
request.hasExpectation() && !isRequestBodyFullyRead()
It isn't very likely, that an application returns a 2xx before having
read the body, but the limitation to non-2xx seems a bit artificial.
Thinking more about it: what is special here about the expectation case?
If "!isRequestBodyFullyRead()" make sense as a condition term in these
places, why bother for limiting it to "request.hasExpectation()"?
Shouldn't then "!isRequestBodyFullyRead()" be the only check and we
close the connection for any status code and even when we had no
expectation? Depending on the detailed behavior of
isRequestBodyFullyRead() we might need to add a check, if the request
had a body at all. What do you think?
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Connection close for POST after successful expectation and status
302
Posted by Mark Thomas <ma...@apache.org>.
On 19/04/2020 14:04, Rainer Jung wrote:
> It might be too simplistic, but the following at least stops the
> connection close (but I don't know, whether it also prevents it in cases
> where it should still be done):
>
> diff --git a/java/org/apache/coyote/http11/Http11Processor.java
> b/java/org/apache/coyote/http11/Http11Processor.java
> index aa1569cfdc..f38993b04d 100644
> --- a/java/org/apache/coyote/http11/Http11Processor.java
> +++ b/java/org/apache/coyote/http11/Http11Processor.java
> @@ -513,7 +513,7 @@ public class Http11Processor extends
> AbstractProcessor {
>
>
> private void checkExpectationAndResponseStatus() {
> - if (request.hasExpectation() &&
> + if (request.hasExpectation() && !isRequestBodyFullyRead() &&
> (response.getStatus() < 200 || response.getStatus() >
> 299)) {
> // Client sent Expect: 100-continue but received a
> // non-2xx final response. Disable keep-alive (if enabled)
>
> Regards,
>
> Rainer
That fix looks right to me.
The case we need to avoid is keeping keep-alive enabled when the client
and the server have a different view of how much of the request body has
been read as that can create request injection issues which are
particularly problematic behind a reverse proxy.
If the server knows it has read the entire body then the client
certainly knows it sent the entire body and all is well.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Connection close for POST after successful expectation and status
302
Posted by Rainer Jung <ra...@kippdata.de>.
It might be too simplistic, but the following at least stops the
connection close (but I don't know, whether it also prevents it in cases
where it should still be done):
diff --git a/java/org/apache/coyote/http11/Http11Processor.java
b/java/org/apache/coyote/http11/Http11Processor.java
index aa1569cfdc..f38993b04d 100644
--- a/java/org/apache/coyote/http11/Http11Processor.java
+++ b/java/org/apache/coyote/http11/Http11Processor.java
@@ -513,7 +513,7 @@ public class Http11Processor extends AbstractProcessor {
private void checkExpectationAndResponseStatus() {
- if (request.hasExpectation() &&
+ if (request.hasExpectation() && !isRequestBodyFullyRead() &&
(response.getStatus() < 200 || response.getStatus() >
299)) {
// Client sent Expect: 100-continue but received a
// non-2xx final response. Disable keep-alive (if enabled)
Regards,
Rainer
Am 19.04.2020 um 14:50 schrieb Rainer Jung:
> Communication trace for the sake of completenes:
>
> 1) Request
>
> POST /sid/D1_13.html HTTP/1.1
> Host: z-web-01.some.domain:8143
> User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:75.0)
> Gecko/20100101 Firefox/75.0
> Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> Accept-Language: de,en-US;q=0.7,en;q=0.3
> Accept-Encoding: gzip, deflate, br
> Content-Type: application/x-www-form-urlencoded
> Origin: https://z-web-01.some.domain:8143
> Referer: https://z-web-01.some.domain:8143/sid/D1_13.html
> Cookie: JSESSIONID=oLPPJ60ADM3Bu9Fc7AgQuDuphGVM9Vxe.app1;
> ssogrp1-ics50=/Hqk7x4s+/A
> Upgrade-Insecure-Requests: 1
> Expect: 100-Continue
> X-Forwarded-For: 123.234.234.123
> X-Forwarded-Host: z-web-01.some.domain:8143
> X-Forwarded-Server: myapp.some.domain
> Content-Length: 165
> Connection: Keep-Alive
>
> 2) 100 Response
>
> HTTP/1.1 100
>
> 3) Request Body
>
> form=form&form%3AD1_13%3Aqsc%3Ard%3AdropDown=ao1&form%3AbtPanel%3Abackward%3AbackwardBt=Zur%C3%BCck&javax.faces.ViewState=-1953107942000075919%3A-7969732459277369777
>
>
> 4) Response with status 302 and closing conection
>
> HTTP/1.1 302
> Pragma: no-cache
> Cache-Control: no-cache, no-store, must-revalidate
> Expires: 0
> x-myapp-session-id: oLPPJ60ADM3Bu9Fc7AgQuDuphGVM9Vxe.app1
> Location: /sid/A_25.html
> Content-Length: 0
> Date: Sun, 19 Apr 2020 11:03:06 GMT
> Connection: close
>
> Regards,
>
> Rainer
>
> Am 19.04.2020 um 14:40 schrieb Rainer Jung:
>> Hi there,
>>
>> I noticed today TC behavior in TC 9 HEAD (but probably not specific to
>> it), that a POST with "Expect: 100-Continue" first gets a correct
>> status 100 response from TC. Then the client (an Apache reverse proxy)
>> send the request body and the application correctly processes it and
>> finally sends back a 302 redirect as expected for that application.
>>
>> But code in java/org/apache/coyote/http11/Http11Processor.java now set
>> keepalive to false which will close the connection. The code in
>> question is in checkExpectationAndResponseStatus() and gets called
>> from prepareResponse() and endRequest().
>>
>> I understand, that when no 100 response is send or the Redirect
>> happens before the body was completely read, a connection close is
>> correct. But why should we close the connection after a complete
>> successful processing of the request/response?
>>
>> 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.
>>
>> Any opinion on whether this behavior is correct?
>>
>> Thanks and regards,
>>
>> Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Connection close for POST after successful expectation and status
302
Posted by Rainer Jung <ra...@kippdata.de>.
Communication trace for the sake of completenes:
1) Request
POST /sid/D1_13.html HTTP/1.1
Host: z-web-01.some.domain:8143
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:75.0)
Gecko/20100101 Firefox/75.0
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Origin: https://z-web-01.some.domain:8143
Referer: https://z-web-01.some.domain:8143/sid/D1_13.html
Cookie: JSESSIONID=oLPPJ60ADM3Bu9Fc7AgQuDuphGVM9Vxe.app1;
ssogrp1-ics50=/Hqk7x4s+/A
Upgrade-Insecure-Requests: 1
Expect: 100-Continue
X-Forwarded-For: 123.234.234.123
X-Forwarded-Host: z-web-01.some.domain:8143
X-Forwarded-Server: myapp.some.domain
Content-Length: 165
Connection: Keep-Alive
2) 100 Response
HTTP/1.1 100
3) Request Body
form=form&form%3AD1_13%3Aqsc%3Ard%3AdropDown=ao1&form%3AbtPanel%3Abackward%3AbackwardBt=Zur%C3%BCck&javax.faces.ViewState=-1953107942000075919%3A-7969732459277369777
4) Response with status 302 and closing conection
HTTP/1.1 302
Pragma: no-cache
Cache-Control: no-cache, no-store, must-revalidate
Expires: 0
x-myapp-session-id: oLPPJ60ADM3Bu9Fc7AgQuDuphGVM9Vxe.app1
Location: /sid/A_25.html
Content-Length: 0
Date: Sun, 19 Apr 2020 11:03:06 GMT
Connection: close
Regards,
Rainer
Am 19.04.2020 um 14:40 schrieb Rainer Jung:
> Hi there,
>
> I noticed today TC behavior in TC 9 HEAD (but probably not specific to
> it), that a POST with "Expect: 100-Continue" first gets a correct status
> 100 response from TC. Then the client (an Apache reverse proxy) send the
> request body and the application correctly processes it and finally
> sends back a 302 redirect as expected for that application.
>
> But code in java/org/apache/coyote/http11/Http11Processor.java now set
> keepalive to false which will close the connection. The code in question
> is in checkExpectationAndResponseStatus() and gets called from
> prepareResponse() and endRequest().
>
> I understand, that when no 100 response is send or the Redirect happens
> before the body was completely read, a connection close is correct. But
> why should we close the connection after a complete successful
> processing of the request/response?
>
> 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.
>
> Any opinion on whether this behavior is correct?
>
> Thanks and regards,
>
> Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Connection close for POST after successful expectation and status
302
Posted by Michael Osipov <mi...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Connection close for POST after successful expectation and status
302
Posted by Mark Thomas <ma...@apache.org>.
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Connection close for POST after successful expectation and status
302
Posted by Michael Osipov <mi...@apache.org>.
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.
But you are right, there is no reason why it should be closed with a 3xx
at least.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Connection close for POST after successful expectation and status
302
Posted by Rainer Jung <ra...@kippdata.de>.
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 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.
> 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)?
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Connection close for POST after successful expectation and status
302
Posted by Michael Osipov <mi...@apache.org>.
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? That's what I see when applying patches to
mod_proxy_http recently.
Some clients don't even handle the expect header, like browsers.
M
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org