1

I understand that the keep-alive message aims to prevent the underlying TCP connection from closing so that multiple requests can be sent over the same TCP connection.

However it is unclear how this affects a request that has timed out:

  • If multiple requests are handled over the same TCP connection, when the client times-out, how will ASP.NET know? I'm not sure how to ask this question correctly, but I suspect that HttpWorkerRequest.IsClientConnected is false if the underlying TCP connection is closed? How would I determine if the client has timed out? Surely the response can no longer be sent?
  • Since the client can send keep-alive messages, what effect, if any does it have on the request? I expect that it will have no effect and mechanisms such as a timeout will work as usual.

Thank you for your time and assistance.

Community
  • 1
  • 1
Pooven
  • 1,744
  • 1
  • 25
  • 44

1 Answers1

5

HTTP keep-alive (which should not be confused with TCP keep alive) asks the server to not close the connection after the HTTP response is fully sent. Thus HTTP keep-alive is only relevant for the time after the HTTP response is sent and before the next HTTP request will be received.

... when the client times-out, how will ASP.NET know?

The server is trying to read data. If the client closes the connection the server will get notified (like by reading 0 bytes) and will close the connection too.

... Surely the response can no longer be sent?

To repeat myself, HTTP keep-alive is only relevant after the full response was sent. So this question is unrelated to HTTP keep-alive.

Since the client can send keep-alive messages, what effect, if any does it have on the request?

No effect on the current request. But the client must be aware that the server might close the connection anytime after the HTTP response was sent and before the server gets the new request. Thus it might happen that the server closes the connection exactly in the moment when the client is trying to send a new request. In this case idempotent requests (GET) must be retried by the client within a new connection, while other requests should fail.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • 1
    Thank you explaining Steffen. Based on your reply, it makes sense for `keep-alive` to live in the request HTTP header. Why would a client need to send additional HTTP `keep-alive` packets? Am I actually mixing those up with the TCP level `keep-alive` packets? – Pooven Dec 17 '15 at 11:06
  • 2
    @Pooven: yes your are mixing HTTP and TCP keep-alive. HTTP keep-alive is only sent inside the HTTP header and it is a request from the client to the server to please not close the connection after the response is done. TCP keep alive instead is used to make sure that idle connections (i.e. no data flow) does not get closed because of timeouts in firewalls etc in between and that the endpoint will detect loss of connectivity due to broken routers, switched off servers etc. TCP keep alive can be used with any kind of TCP connection, not only HTTP. – Steffen Ullrich Dec 17 '15 at 12:00