title: Why does HttpWebRequest not sent TCP Keep-Alive packages even when using ServicePointManager.SetTcpKeepAlive
body: <p>I want to retrieve some data with an HttpWebRequest (GET):</p>
  
  <pre><code>var request = (HttpWebRequest)WebRequest.Create(myUri);
  request.Timeout = 5 * 60 * 1000;
  request.ReadWriteTimeout = 5 * 60 * 1000;
  
  // request.ServicePoint.SetTcpKeepAlive(true, 5 * 1000, 1000);
  var response = request.GetResponse();
  </code></pre>
  
  <p>Unfortunately the computation on the server can take two or more minutes. So between me sending the header and finally receiving the data in the response stream the socket connection is idle.</p>
  
  <p>With curl or a browser the response finally comes through. But when using HttpWebRequest I always get an exception after 90 seconds:</p>
  
  <pre><code>System.AggregateException: One or more errors occurred. ---&gt;
  System.Net.WebException: Error getting response stream (ReadDone1): ReceiveFailure ---&gt; 
  System.IO.IOException: Unable to read data from the transport connection: Connection reset by peer. ---&gt;
  System.Net.Sockets.SocketException: Connection reset by peer
  </code></pre>
  
  <p>When comparing the TCP traffic in Wireshark between curl and HttpWebRequest I noticed that curl sends TCP Keep-Alive packages (ACK). Unfortunately even after enabling</p>
  
  <pre><code>ServicePointManager.SetTcpKeepAlive(true, 5 * 1000, 1000);
  </code></pre>
  
  <p>before creating the HttpWebRequest I can't see the Keep-Alive packages in the Wireshark trace. Why does the underlying socket not send an ACK package every five seconds (I picked this short interval for debugging. In production it could be set one minute).</p>
  
  <p>When I start curl with the <code>--no-keepalive</code> parameter it shows the same behavior (connection drop after 90s). Some network related stuff seems to disconnect the socket if there is no traffic.</p>
  
  <p><em>Remark:</em>
  <em>I know the server should not do such lengthly computation in response to GET and hopefully the API will change in the future. It's just bugging me that I can not produce TCP Keep-Alive packages with .Net</em></p>