Qu'est-ce qui fait que ce HTTPS WebRequest time out même s'il fonctionne dans le navigateur?
Voici ma requête:
var request = (HttpWebRequest) WebRequest.Create("https://mtgox.com/");
request.CookieContainer = new CookieContainer();
request.AllowAutoRedirect = false;
request.Accept = "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8";
request.Headers[HttpRequestHeader.AcceptEncoding] = "gzip, deflate";
request.Headers[HttpRequestHeader.AcceptLanguage] = "en-gb,en;q=0.5";
request.Headers[HttpRequestHeader.AcceptCharset] = "ISO-8859-1,utf-8;q=0.7,*;q=0.7";
request.Timeout = 5000;
request.UserAgent = "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0";
request.Method = "GET";
request.GetResponse();
les en-têtes ont été copiés à partir de Firefox en utilisant HttpFox. J'ai utilisé Fiddler2 pour vérifier qu'au moins pour les requêtes HTTP, les en-têtes sont complètement identiques entre les requêtes Firefox et mes requêtes.
cependant, lors de l'exécution d'une requête à ce site en utilisant HTTPS, la requête est simplement times out. Il travaille pour d'autres sites web.
je dois l'exécuter différemment de Firefox, parce qu'il a toujours il travaille à Firefox. Je ne peux pas le déboguer en utilisant Fiddler2, cependant, parce que chaque fois que Fiddler2 transmet ces requêtes elles temps, même lorsqu'il provient de Firefox.
Est-ce juste un site Web vraiment bogué? Quelle partie de ce qui précède me donne comme Ne pas être Firefox?
6 réponses
en utilisant Microsoft Network Monitor, j'ai trouvé que HttpWebRequest serait bloqué à un stade où il est censé renvoyer un échange de clés client. Ça n'a pas marché. Le serveur l'attendait, mais il n'est jamais venu.
quelle correction forçait HttpWebRequest à utiliser SSL3 au lieu de TLS (même si TLS est supposé se transformer automatiquement en SSL3 si nécessaire):
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;
pourquoi c'est ainsi je suppose que je ne saurai jamais - juste une de ces choses mystérieuses qui prendraient plus de temps à comprendre que quiconque que je connais est prêt à passer...
une chose qui était différente au sujet des captures: la variante TLS avait une entrée "alerte" dans la réponse Hello du serveur, qui est absent de la bourse SSL3 et aussi de toutes les bourses TLS qui ont réellement fonctionné. Curieusement, cependant, la même alerte est présente dans une capture de Firefox exécutant la requête avec succès.
enfin, il semble qu'il y ait eu un bug OCSP temporaire juste au moment où j'ai posté cette question, qui a été résolue depuis. Cela a ajouté au gâchis, mais ce n'est pas le problème principal.
la raison typique des erreurs de timeout avec les appels HttpWebRequest/HttpWebReponse est "ne pas fermer l'objet de réponse/flux", ce qui maintient les connexions actives. Vous avez simplement fermer le Stream ou HttpWebResponse objet après lecture du contenu du flux. La limite de connexion par défaut est 2.
HttpWebResponse webResponse = (HttpWebResponse)webRequest.GetResponse();
Stream stream = webResponse.GetResponseStream();
string responseString = ((TextReader)new StreamReader(stream)).ReadToEnd();
webResponse.Close();
alternativement, si vous avez implémenté votre logique dans un service web qui sera concurremment invoqué par de nombreux utilisateurs, alors vous pouvez envisager d'augmenter la connexion-limite dans L'objet HttpWebRequest.
HttpWebRequest webRequest = (HttpWebRequest)HttpWebRequest.Create(url);
webRequest.ServicePoint.ConnectionLimit = 20;
le framework .NET sur Windows 7 implémente une extension TLS: Indication du nom du serveur (RFC4366). En fonction de votre post que signifie cette Alerte TLS le serveur répond avec "Unreognized Name". Je ne sais pas pourquoi la connexion est signalée à time out, parce que ce n'est vraiment pas le cas. Vos traces réseau devraient montrer que le client initie une fin de connexion après cela [FIN,ACK]. Le déclassement en SSL3 évite l'invocation de la SNI.
POUR INFORMATION: la même chose .NET framework sous Windows XP n'utilise pas l'Extension TLS Server Name Indication. Votre programme de travail....
dans mon cas, J'ai retracé l'occurrence de ceci à une directive ServerName manquante dans Apache. L'ajout du ServerName à la configuration SSL l'a résolu, car le serveur web n'ignore plus son nom.
récemment découvert à propos de ce même problème, et voulait voir si Microsoft pourrait avoir corrigé cela dans les nouvelles versions .net. C'est le code que j'ai testé avec (Domaine supprimé pour la vie privée):
HttpWebRequest request =
(HttpWebRequest)WebRequest.Create("https://www.xxSomeDomainNamexx.com/");
HttpWebResponse response = (HttpWebResponse)request.GetResponse();
StreamReader reader = new StreamReader(response.GetResponseStream());
Console.WriteLine(reader.ReadToEnd());
compilé ce contre .net versions 2.0, 3.0,et 3.5 et tous semblaient montrer le même comportement que tout le monde ici a été discuté. Puis j'ai essayé de compiler contre 4.0 et 4.5, et ai reçu des réponses appropriées dans les deux endroits.
basé sur ceci, il semble Microsoft a probablement corrigé ce problème dans les nouvelles versions .net. Pour la postérité j'ai également testé le changement SecurityProtocol suggéré par enverpex et il a fonctionné très bien sur 2.0, 3.0, et 3.5.
j'ai eu le même problème de délai avec les requêtes https et aucune réponse ne m'a aidé. J'ai trouvé une solution qui a résolu le problème pour moi. Notez que cela ne fonctionne qu'avec .net framework 4.5 ou supérieur.
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);
très probablement le client HTTPS ne peut pas valider la chaîne de certificats présentée par ce serveur, par exemple en raison d'un certificat racine manquant ou d'un répondeur OCSP inaccessible. C'est-à-dire: il peut y avoir quelque chose de différent configuré dans le navigateur et dans le client HTTPS que vous utilisez.
Comme une des options, vous pouvez prendre une version d'essai de notre HTTPBlackbox composants et essayer de se connecter en utilisant TElHTTPSClient. Il vous donnera des informations détaillées sur l'erreur (en cas d'erreur) de sorte que vous sera en mesure de déterminer, quel est le problème avec HttpWebRequest.