https://bz.apache.org/bugzilla/show_bug.cgi?id=65662
--- Comment #21 from Yann Ylavic <ylavic....@gmail.com> ---
(In reply to Lothar from comment #17)
> Created attachment 38099 [details]
> Trace8 Log filtered by one PID, serving the Request IP-Addresses/hostnames
> anonymised
>
> The Last Logentry related to this connection was at 08:35:32.
> The Connection Status swtiched from Established to CLOSE_WAIT on 08:35:32
> at 08:35:42 the Connection was closed by Remote System with TCP RST package.
So below are the traces when the backend (10.1.1.1:443) initiates the shut down
with the proxy which in turn shuts down with the client (10.0.0.1:51469) :
>[Tue Nov 23 08:35:32.217620 2021] [proxy:trace8] [pid 35586448]
>proxy_util.c(4880): [client 10.0.0.1:51469] proxy: CONNECT: polling
>(client=31, origin=31)
>[Tue Nov 23 08:35:32.217637 2021] [proxy:trace8] [pid 35586448]
>proxy_util.c(4903): [client 10.0.0.1:51469] AH10215: proxy: CONNECT: woken up,
>1 result(s)
>[Tue Nov 23 08:35:32.217648 2021] [proxy:trace8] [pid 35586448]
>proxy_util.c(4911): [client 10.0.0.1:51469] proxy: CONNECT: #0: origin: 1/31
>[Tue Nov 23 08:35:32.217658 2021] [proxy:trace8] [pid 35586448]
>proxy_util.c(4812): [client 10.0.0.1:51469] proxy: CONNECT: origin input ready
>[Tue Nov 23 08:35:32.217703 2021] [proxy:trace2] [pid 35586448]
>proxy_util.c(4648): (70014)End of file found: [client 10.0.0.1:51469]
>ap_proxy_transfer_between_connections complete (from 10.1.1.1:443)
>[Tue Nov 23 08:35:32.217718 2021] [proxy:trace3] [pid 35586448]
>proxy_util.c(4840): [client 10.0.0.1:51469] proxy: CONNECT: origin read
>shutdown
>[Tue Nov 23 08:35:32.217729 2021] [proxy:trace8] [pid 35586448]
>proxy_util.c(4880): [client 10.0.0.1:51469] proxy: CONNECT: polling
>(client=35, origin=0)
>[Tue Nov 23 08:35:32.217745 2021] [proxy:trace8] [pid 35586448]
>proxy_util.c(4903): [client 10.0.0.1:51469] AH10215: proxy: CONNECT: woken up,
>1 result(s)
>[Tue Nov 23 08:35:32.217755 2021] [proxy:trace8] [pid 35586448]
>proxy_util.c(4911): [client 10.0.0.1:51469] proxy: CONNECT: #0: client: 4/35
>[Tue Nov 23 08:35:32.217766 2021] [proxy:trace8] [pid 35586448]
>proxy_util.c(4945): [client 10.0.0.1:51469] proxy: CONNECT: client output ready
>[Tue Nov 23 08:35:32.217777 2021] [proxy:trace3] [pid 35586448]
>proxy_util.c(4968): [client 10.0.0.1:51469] proxy: CONNECT: client write
>shutdown
>[Tue Nov 23 08:35:32.217813 2021] [proxy:trace8] [pid 35586448]
>proxy_util.c(4880): [client 10.0.0.1:51469] proxy: CONNECT: polling
>(client=31, origin=0)
Same as comment 16, the proxy is now waiting (indefinitely) for the client to
shut down before shutting down the connection to the backend.
So regarding the states of the connections on the proxy system, the
client<>proxy connection is in FIN_WAIT2 and the proxy<>backend connection is
in CLOSE_WAIT.
The question is: why doesn't the client close (or reset) the connection when it
receives the FIN?
Until then the proxy cannot consider that the communication is complete and can
only wait for some time that it happens, unfortunately proxy_connect does not
set up a timeout for its connections (thus the infinite wait).
The timeout handling has been added to mod_proxy_connect in trunk (r1894290)
and will probably be in the next 2.4 versions, but in the current 2.4 releases
I can't think of a way to abort the connection before the client's FIN/RST,
this needs to be patched with r1894290.
Possibly mod_proxy could also handle a setting like "SetEnv proxy-nohalfclose"
(à la proxy-nokeepalive) to issue a full close (for both read and write on both
the client and backend connections) whenever one side sends a FIN.
Note that the half-close change was introduced in 2.4.47 (released in 2.4.48):
*) mod_proxy: Improve tunneling loop to support half closed connections and
pending data draining (for protocols like rsync). PR 61616.
Before this mod_proxy was not working correctly for some protocols, so it's a
fix really though for backward compatibility there could be an opt-out (for
those that don't want to wait for the timeout..).
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
