HTTP client request timeout handling in keep-alive connections

Question

Regarding to HTTP keep-alive how request timeout should be handled on client side? For example there is a flow:

• Client sends Request1;
• Client waits for 1 minute;
• Client assumes the Request1 failed and resends it, i.e. sends new Request2 = Request1;
• Server responds with Response1 (which is response for Request1);
• Client assumes this is a response to Request2 but can handle it because Request1 = Request2;
• Client sends Request3;
• Server responds with Response2 (which is response for Request2);
• Client assumes this is a response to Request3 and fails to handle it.

I couldn't find any info in specification. It says how to retry if connection was closed by server but nothing about the situation when request took too long to proceed.

Answer 1

I have experience with ASP.NET though I'm not sure if this paradiagm is used for all HTTP pipelines. Here's what I understand:

• The response is tied to the request. In C#, there is a HttpContext that facilitates this. The new request comes in on a separate thread which has no safe context of any other requests.
• When a client makes a request, (for example, via WebRequest) the response is tied to that request.

Therefore Request1 in your example could never be mixed up with Request2. The keep-alive that's used in the HTTP request header indicates that the underlying TCP connection shouldn't be closed so that it can be reused for other requests. As far as I understand, a single request timing out doesn't affect the underlying TCP connection; that is, even though the TCP connection is shared, the request-response mechanisms work as usual.