NetworkStream.DataAvailable Does Not Mark the End of an HTTP Response
Prevent truncated HTTP downloads by using message framing instead of NetworkStream.DataAvailable as the end condition.
NetworkStream.DataAvailable == false means there are no bytes ready to read immediately. It does not mean an HTTP response is complete. A loop stopping there can truncate a perfectly normal SOCKS download during a gap between packets.
After SOCKS establishes the TCP connection, HTTP framing still supplies the completion rule:
- A Content-Length body ends after its declared content bytes.
- A chunked response needs its terminating chunk and applicable trailers.
- A connection-delimited response ends with the connection.
- Some statuses and responses to HEAD have no body.
Read status and headers to determine the applicable rule. Waiting only for closure is not a general fix because a complete HTTP response can leave the connection open. One buffer's capacity is equally unrelated to the response length.
Use the HTTP client's framing implementation when it supports the chosen proxy transport. On a compatible modern .NET runtime, consider HttpClient's native SOCKS support. A raw implementation must keep parsing state across partial headers and body reads and distinguish successful completion from cancellation, timeout and unexpected EOF. For a non-empty read request, zero bytes read means the stream ended; this is different from no bytes being queued right now.
The proxy can make timing gaps noticeable, but it does not change an empty receive queue into an end-of-message marker.