Question

J'ai une application qui doit parfois faire des requêtes au serveur pour voir que ces demandes sont correctement bloquées. En d'autres termes, le serveur attendu réponse est 403 interdite.

Avec un morceau de code comme ceci:

HttpWebRequest httpRequest = (HttpWebRequest)WebRequest.Create(protectedPage);
httpRequest.Method = WebRequestMethods.Http.Head;
WebResponse response = HttpRequest.GetResponse();

WebException est jeté sur la dernière ligne.

Lorsque le code de profilage, cette exception dans un bloc try / catch a un impact sur les performances que je veux éviter.

Y at-il un moyen de vérifier la réponse du serveur, attend un 403, sans avoir à prendre une exception (mais en évitant l'utilisation des sockets directement)?

Était-ce utile?

La solution

Malheureusement, ceci est un vexant exception dans le cadre, et il n'y a aucun moyen de l'éviter (tout en utilisant la classe HttpWebRequest). Mais, comme haut fait remarquer, cette gestion des exceptions prendra nanosecondes, tandis que la demande Web lui-même prendra millisecondes (au mieux), donc ne vous inquiétez pas à ce sujet.

L'objet WebException possède une propriété Response qui contient la réponse; lorsque vous manipulez l'exception, il est important de disposer de cet objet WebResponse (pour éviter les connexions qui fuient).

Autres conseils

Ce qui est de prendre le temps dans le profilage est probablement pas l'exception mais la partie attrapant réponse réelle à partir du site Web.

La propriété WebException.Status vous donnera le code d'état de la réponse HTTP et vous pouvez faire un traitement ultérieur sur cette base.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top