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