Client inactivity timeout triggers during slow origin processing POST request

[shinrich]

@djcarlin has been debugging an issue for one of our clients. They are seeing unexpected POST upload failures. Looking at packet captures, traffic log entries, and HTTP debug messages, the client is dutifully sending all the bytes in the post body (64-200 MB of data). But 30 seconds after post body transfer completes, the transaction fails with a ERR_CLIENT_ABORT. We see no traffic from the origin in the packet capture. Based on the traffic logs, the SERVER_FIRST_READ milestone is not set.

The relevant transaction timeouts are

proxy.config.http.transaction_no_activity_timeout_in: 30
proxy.config.http.transaction_no_activity_timeout_out: 60

So it seems likely that the transaction_no_activity_timeout_in timeout is triggering. However, once the client has sent all the data and is waiting for a response, it does not seem that the transaction_no_activity_timeout_in should still be enabled. Yet, looking through the code, it appears that we only cancel the timeout while waiting for the origin if the request content-length is 0. Looking through history, it seems to have been this while for some time.

I have a PR, that disables the transaction_no_activity_timeout_in timeout after the post data tunnel has completed. It also adds an autest that shows without the code change GET's do not timeout with a stalled server but POST's do.

Anyone with broader history in the project know why we make a differentiation for GET and POST methods with respect to canceling the client's inactivity timeout?

[zwoop]

Please remember to remove Projects and Milestones from PRs that are closed.