Repository navigation
http1.1: support half closed clients #2066
Description
In http1.1 a client can choose to add "Connection: close" to the header and half close their (write) end of the socket and wait for the answer
What happens is envoy does forward the request but then immediately closes both end (probably because it reads the EOF/readability of 0 as an error instead of normal)
Repro
$ fortio curl -loglevel=debug -keepalive=false -halfclose http://echosrv2:8080/debug
18:41:30 D http.go:290> Created client:
{IP:10.39.255.58 Port:8080 Zone:}
GET /debug HTTP/1.1
Host: echosrv2:8080
Connection: close
User-Agent: istio/fortio-0.3.6
18:41:30 D http.go:504> Half closed ok after sending request &{{0xc4200e25b0}} {10.39.255.58 8080 }
18:41:30 E http.go:545> EOF before reading anything on &{{0xc4200e25b0}} {10.39.255.58 8080 }
18:41:30 V fortio_main.go:141> Fetch result code -1, data len 0, headerlen 0
envoy log
[2017-11-16T18:41:30.081Z] "GET /debug HTTP/1.1" 0 - 0 0 0 - "-" "istio/fortio-0.3.6" "e16c359b-048a-47a5-b5ab-b5e917bd2f72" "echosrv2:8080" "10.36.2.8:8080"
Spec extract
Servers SHOULD always respond to at least one request per connection, if at all possible. Servers SHOULD NOT close a connection in the middle of transmitting a response, unless a network or client failure is suspected.
Activity
ldemailly commentedon Nov 15, 2017
cc @ggreenway who mentioned he is fixing it for tcp
ggreenway commentedon Nov 15, 2017
Tracking tcp proxy issue at #2067
Fix/workaround for half close
Fix/workaround for half close and proxy erroneous More data is availa…
stale commentedon Jun 20, 2018
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.
fkowal commentedon Jan 30, 2019
I am tracking the same bug i think.
I this example the client send a tcp FIN, i guess this is what you mean as halfclose.
The Connection: close header is just a representation of that
Clarify log messages (envoyproxy#2066)
Clarify log messages (envoyproxy#2066) (envoyproxy#2067)
kthommandra commentedon Jun 18, 2020
Does anyone know if mainstream browsers (Chrome, Firefox etc) can end up doing TCP half-close under certain scenarios ?
kthommandra commentedon Jun 19, 2020
It clearly shows that there are web apps that end up doing TCP half-close
(eg: see attachment Reviewboard app in Firefox)
Given this behavior, shouldn't Envoy support TCP half-close on HTTP connections?
HA-Proxy seems to work just fine with this.
I haven't yet seen client badness/error etc due to this but its very confusing to see so many "DC" response flag messages being logged in Envoy access logs frequently. I'm not sure how the app recovers from this lack of HTTP response due to cnxn close.
firefox-half-close.pdf
ggreenway commentedon Jun 26, 2020
I brought this up a few years ago as a potential issue, and at the time, no widely-used http client was sending a half-close after the request but before the response. I looked at several. If that's changed, we may need to revisit this.
7 remaining items
github-actions commentedon Nov 13, 2021
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.
ldemailly commentedon Nov 17, 2021
ping
github-actions commentedon Dec 17, 2021
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.
github-actions commentedon Dec 24, 2021
This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.
ldemailly commentedon Jan 20, 2022
ping
ggreenway commentedon Jan 20, 2022
@ldemailly this is unlikely to see any movement unless someone shows a need for it and is willing to work on the fix.
kyessenov commentedon Aug 18, 2022
This is a real problem for CONNECT. TCP half-close is much more common and if we want to faithfully map onto HTTP/1.1 CONNECT, we need to support half-closed semantics. The issue can happen with read direction, too (e.g. upstream closing their end, which is interpreted as full close by Envoy but as half-close by tcp_proxy client).