request and idle timeout behavior clarification

[csrl]

Hello,

We are upgrading from Cowboy 2.10.0 to 2.14.2. We found a behavior change in timeouts impacted our http1.1 use case.

Commit 1a175e7 "Fix wrong HTTP/1 timeout being used in some cases" is the primary offending commit and when reverted then our expected behavior was restored.

That commit along with other recent updates brings the code behavior and documentation in line, and we have this new understanding of the intended behavior:

1. request_timeout - the time from the end of one request/response (or opening of the connection) until the reception of the full request headers.
2. idle_timeout - the time a connection can go idle while a request is in progress, optionally reset with reset_idle_timeout_on_send.

And the tested behavior that we implemented against in 2.10.0 is this:

1. request_timeout - the time from receiving the request line on keep alive requests (or from connection opened) until the full request headers received.
2. idle_timeout - the time a connection goes idle whether a request is in progress or not.

Specifically on keep-alive connections, when a request/response completed, the idle_timeout continued to be used when no request was in progress and the request_timeout started when the request line came in.

Our use case has these needs:

1. A connection may be idle without any requests active on it for N period
2. A response may not be available for N period of time before becoming ready and being sent to the client
3. Once a request begins (request line received), we expect timely completion of the full request headers in order to make decisions on whether to allow the request to continue or not.

1. and 2) has the same inactivity period requirements for us, and with cowboy 2.10.0 we used idle_timeout to ensure the connection remained open for both cases
2. was satisfied by setting a short request_timeout in cowboy 2.10.0

With the new behavior, we can not satisfy all three needs. The inactivity time between requests is now constrained by the request_timeout and not the idle_timeout. So, now, we must either configure time between requests must be short, or the time from request start to all headers received must be long.

It seems to me cowboy needs these controls:

1. request timeout - time from connection open or between requests until start of request line
2. headers timeout - time from start of request line to full headers received
3. read request body (part) timeout - max time to receive body (part).

Any "idle" time outside of the above controls doesn't seem to be appropriate for cowboy internals to enforce, instead left to the use case implementation.

[essen]

There's no difference between "waiting for the beginning of the next request" and "waiting until all headers have been received" for user code. Cowboy does not begin the request handling until all headers have been received. So in your case I think you just need a larger request timeout?

The idle timeout is there to make sure we detect TCP half-closed sockets and can clean up, it shouldn't be triggered too often and you only need to increase it if you have really long period of times where nothing gets sent for some requests.

[csrl]

Fair enough about request/header timeout in terms of user code, although I think there are illicit behavior concerns with clients that start a request but trickle in bytes for the headers over a long request timeout period. Having a request timeout where no activity is occurring, with clear behavior expectation on time to send headers and time to send body once started, is preferred.

[essen]

Yes I get the semantic difference but it makes little difference in terms of resources used.

The ideal scenario is a low request timeout and to have clients disconnect or reconnect on inactivity, rather than keep the connection open indefinitely.

As far as resource usage goes a client keeping the connection open sending nothing and a client keeping the connection open sending one byte at a time is roughly the same, Cowboy disallows both by default and I wouldn't recommend increasing request_timeout too much outside of controlled environments.

HTTP/2 and above are better suited for long running connections but the ideal scenario is the same, clients should just disconnect or reconnect on inactivity.