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
