title: C# NetworkStream.Read oddity
body: <p>Can anyone point out the flaw in this code? I'm retrieving some HTML with TcpClient. NetworkStream.Read() never seems to finish when talking to an IIS server. If I go use the Fiddler proxy instead, it works fine, but when talking directly to the target server the .read() loop won't exit until the connection exceptions out with an error like "the remote server has closed the connection".</p>
  
  <pre><code>internal TcpClient Client { get; set; }
  
  /// bunch of other code here...
  
  try
  {
  
  NetworkStream ns = Client.GetStream();
  StreamWriter sw = new StreamWriter(ns);
  
  sw.Write(request);
  sw.Flush();
  
  byte[] buffer = new byte[1024];
  
  int read=0;
  
  try
  {
      while ((read = ns.Read(buffer, 0, buffer.Length)) &gt; 0)
      {
          response.AppendFormat("{0}", Encoding.ASCII.GetString(buffer, 0, read));
      }
  }
  catch //(SocketException se)
  {
  
  }
  finally
  {
      Close();
  }
  </code></pre>
  
  <p><strong>Update</strong></p>
  
  <p>In the debugger, <strong>I can see the entire response coming through</strong> immediately and being appended to my StringBuilder (response). It just appears that the connection isn't being closed when the server is done sending the response, or my code isn't detecting it.</p>
  
  <p><strong>Conclusion</strong>
  As has been said here, it's best to take advantage of the offerings of the protocol (in the case of HTTP, the Content-Length header) to determine when a transaction is complete. However, I've found that not all pages have content-length set. So, I'm now using a hybrid solution:</p>
  
  <ol>
  <li><p>For ALL transactions, set the request's <code>Connection</code> header to "close", so that the server is discouraged from keeping the socket open. This improves the chances that the server will close the connection when it is through responding to your request.</p></li>
  <li><p>If <code>Content-Length</code> is set, use it to determine when a request is complete.</p></li>
  <li><p>Else, set the NetworkStream's RequestTimeout property to a large, but reasonable, value like 1 second. Then, loop on <code>NetworkStream.Read()</code> until either a) the timeout occurs, or b) you read fewer bytes than you asked for.</p></li>
  </ol>
  
  <p>Thanks to everyone for their excellent and detailed responses.</p>