I'm designing a REST-Webservice and pondering the following scenario:
On the client end, this is easily detected - no response arrives, so at some point, the client application will run into a timeout. However, is there any guarantee the server can detect the loss of its reponse packet?
In my mind, it should theoretically work - since the TCP connection is not gracefully terminated by the client after receiving the last part of the response, the server should be able to notice that something is wrong. However, is this a feasible assumption to make, knowing that the internet is a big and unreliable place?
Specifically, assuming there are (possibly multiple) HTTP reverse proxies, loadbalancers, etc. between my client and server. Can I even assume that my "TCP-level" client is the same machine as the application-level, i.e. HTTP-level client? Or could there be a scenario (as in "is it a common networking practice to have the kind of setup where this could happen") where my server sees the TCP connection as gracefully terminated because some proxy has received the full HTTP packet, but the packet gets lost between that proxy and my actual client?
Specifically, assuming there are (possibly multiple) HTTP reverse proxies, loadbalancers, etc. between my client and server. Can I even assume that my "TCP-level" client is the same machine as the application-level, i.e. HTTP-level client?
No, that's literally how HTTP proxies work – the TCP connection from the client has to terminate at the proxy, which then creates a completely separate TCP connection to its backend server.
The status of the backend TCP connection, including e.g. the proxy's receive buffer, does not correspond to status of the client at all. And of course, the proxy has to receive (any given part of) the response before it can even begin forwarding that to the client, so it is very possible that the 1st half succeeds but the 2nd half fails.
If the proxy were to just transparently pass TCP segments, it wouldn't be able to do most of its job as an HTTP proxy.