Both .NET Socket and NetworkStream offer Read method, which blocks, when there is no data available. The problem is that, if client doesn’t know the size of the message, there is no reliable way of understanding when server has finished sending the message.
My question is – what principle do higher level libraries (like HTTP-level WebRequest) use in order to stop reading from the socket and present full message to the client, without resorting to any sort of reading timeouts? It seems like HTTP protocol doesn’t offer any “EOF” tokens…
HTTP 1.1 manages this by using one of two mechanisms. Either the content-length is sent in the headers, or a chunked transfer encoding is used. The chunked transer encoding is one of the big advantages of HTTP 1.1 over HTTP 1.0 where, in the case that no content-length was sent, end of transmission could not be reliably detected resulting in abiguity between transmission problems and the actual end of the payload. In some cases (such as audio streams over HTTP) there is no content-length or other encoding that might indicate end of transmission, but in this case it would be of little importance to the client.