Major Description
TLDR; similar to TS-4720 – slower to close than it should, instead of never closing
As a continuation of TS-4720, while testing that the session is closed when we expect-- I found that it isn't.
Although we are now closing the sessions, we aren't doing it as quickly as we should. In this client abort case we expect the client to abort, and ATS should initially continue to send bytes to the client-- as we are in the half-open state. After the first set of bytes are sent to the client-- the client will send an RST-- which should signal ATS to stop sending the request (and tear down the origin connection etc.).
I'm able to reproduce this locally, and the debug output (with some additional comments) looks like below:
< FIN FROM CLIENT >
[Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG: <HttpSM.cc:2649 (main_handler)> (http) [0] [HttpSM::main_handler, VC_EVENT_EOS]
[Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG: <HttpSM.cc:892 (state_watch_for_client_abort)> (http) [0] [&HttpSM::state_watch_for_client_abort, VC_EVENT_EOS]
< RST FROM CLIENT >
Got an HttpTunnel event 100
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: <HttpTunnel.cc:1173 (producer_handler)> (http_tunnel) [0] producer_handler [http server VC_EVENT_READ_READY]
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: <HttpTunnel.cc:1108 (producer_handler_chunked)> (http_tunnel) [0] producer_handler_chunked [http server VC_EVENT_READ_READY]
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: <HttpTunnel.cc:203 (read_size)> (http_chunk) read chunk size of 15 bytes
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: <HttpTunnel.cc:279 (read_chunk)> (http_chunk) completed read of chunk of 15 bytes
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: <HttpTunnel.cc:1213 (producer_handler)> (http_redirect) [HttpTunnel::producer_handler] enable_redirection: [1 0 0] event: 100
Got an HttpTunnel event 101
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: <HttpTunnel.cc:1373 (consumer_handler)> (http_tunnel) [0] consumer_handler [user agent VC_EVENT_WRITE_READY]
write ready consumer_handler
In this situation the connection doesn't close here at the RST-- but rather on the next set of bytes from the origin to send-- which end up tripping a VC_EVENT_ERROR-- and tearing down the connection.
When the client sends the first RST epoll returns a WRITE_READY event – which the HTTPTunnel consumer ignores completely. It seems then that when we recieve the WRITE_READY event we need to determine if we are already in the writing state-- and if so, then we should stop the transaction (since we are already edge-triggered).
