What makes this HTTPS WebRequest time out even though it works in the browser?

Question

Here\'s my request:

var request = (HttpWebRequest) WebRequest.Create(\"https://mtgox.com/\");
request.CookieContainer = new CookieContainer();
request.AllowA         


        

Answer 1

The typical reason for timeout errors with HttpWebRequest/HttpWebReponse calls is "not closing the response object/stream", which keep the connections active. You have to simply close the Stream object or the HttpWebResponse object after reading the contents of the stream. Default connection-limit is 2.

HttpWebResponse webResponse = (HttpWebResponse)webRequest.GetResponse();
Stream stream = webResponse.GetResponseStream();
string responseString = ((TextReader)new StreamReader(stream)).ReadToEnd();
webResponse.Close();

Alternatively, if you implemented your logic in a web-service which will be concurrently invoked by many users, then you may want to consider increasing the connection-limit in HttpWebRequest object.

HttpWebRequest webRequest = (HttpWebRequest)HttpWebRequest.Create(url);    
webRequest.ServicePoint.ConnectionLimit = 20;

Answer 2

I had the same timeout issue with https requests and none of the answers helped me. Just now I found a solution that resolved the problem for me. Note that this works only with .net framework 4.5 or higher.

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;
var response = WebRequest.Create("https://yoursecurewebservice").GetResponse();
var body = new StreamReader(response.GetResponseStream()).ReadToEnd();
Console.WriteLine(body);

Answer 3

The .NET framework on Windows 7 implements a TLS extension: Server Name Indication (RFC4366). According to your post What does this TLS Alert mean the server is responding with "Unrecognized Name". Not sure why the connection is reported to time out, because it really doesn't. Your network traces should show that the client initiates a connection termination after this [FIN,ACK]. Downgrading to SSL3 avoids the invocation of the the SNI.

FYI: The same .NET framework on Windows XP does not use the TLS Server Name Indication Extension. Your program will work there....

In my case I traced the occurrence of this to a missing ServerName directive in Apache. Adding the ServerName to the SSL configuration solved it, because now the web server no longer is unaware of its name.

Answer 4

Recently found out about this same problem, and wanted to see if Microsoft might have fixed this in newer .net versions. This is the code I tested with (domain removed for privacy):

HttpWebRequest request =
    (HttpWebRequest)WebRequest.Create("https://www.xxSomeDomainNamexx.com/");
HttpWebResponse response = (HttpWebResponse)request.GetResponse();
StreamReader reader = new StreamReader(response.GetResponseStream());
Console.WriteLine(reader.ReadToEnd());

Compiled this against .net versions 2.0, 3.0, and 3.5 and all seemed to exhibit the exact same behavior as everyone here has been discussing. Then I tried compiling against 4.0 and 4.5, and received proper responses in both places.

Based on this, it seems Microsoft has likely fixed this problem in newer .net versions. For posterity I also tested the SecurityProtocol change suggested by enverpex and it worked great on 2.0, 3.0, and 3.5.

Answer 5

Most likely the HTTPS client can't validate the certificate chain presented by this server, for example due to missing root certificate or inaccessible OCSP responder. I.e. there can be something different configured in the browser and in HTTPS client you use.

As one of the options you can take a trial version of our HTTPBlackbox components and try to connect using TElHTTPSClient. It will give you detailed error information (in case of error) so you will be able to determine, what's wrong with HttpWebRequest.

Answer 6

Using Microsoft Network Monitor, I found that HttpWebRequest would get stuck at a stage where it's supposed to send back a client key exchange. It simply didn't. The server duly waited for it, but it never came.

What fixed it was forcing HttpWebRequest to use SSL3 instead of TLS (even though TLS is supposed to automatically turn into SSL3 if necessary):

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

Why this is so I guess I'll never know - just one of those mysterious things that would take more time to figure out than anyone I know is willing to spend...

One thing that was different about the captures: the TLS variant had an "Alert" entry in the Server Hello response, which is absent from the SSL3 exchange and also from all the TLS exchanges that actually worked. Curiously, though, the same alert is present in a capture of Firefox performing the request successfully.

Finally, it appears that there was a temporary OCSP glitch just when I was first posting this question, which has since been resolved. This added to the mess, but isn't the core problem.