2010-04-23 13 views
12

Seguramente, seguramente, hay una forma de configurar el objeto .Net HttpWebRequest para que no genere una excepción cuando se llama a HttpWebRequest.GetResponse() y cualquier 300 o 400 códigos de estado son devueltos?Cómo detener .Net HttpWebRequest.GetResponse() al generar una excepción

Jon Skeet does not think so, así que casi no me atrevo a preguntar, pero me cuesta creer que no haya forma de evitar esto. Los códigos de respuesta 300 y 400 son respuestas válidas en ciertas circunstancias. ¿Por qué nos veríamos obligados a incurrir en los gastos generales de una excepción?

¿Quizás haya alguna configuración de configuración oscura que evadió a Jon Skeet? ¿Tal vez hay un tipo completamente diferente de objeto de solicitud que se puede usar y que no tiene este comportamiento?

(y sí, sé que solo puede detectar la excepción y obtener la respuesta de eso, pero me gustaría encontrar una manera de no tener que hacerlo).

Gracias por cualquier ayuda

Respuesta

5

acuerdo con la especificación cuando un servidor envía un código 400 de estado significa que:

La solicitud no podría ser entendido por el servidor debido a sintaxis incorrecta. El cliente NO DEBE repetir la solicitud sin modificaciones.

Por lo tanto, parece bastante natural tener una excepción en este caso. En lo que respecta a 300, es más debatible.

De todos modos, si desea un comportamiento no estándar siempre puede recurrir a un TcpClient, pero eso realmente parece una medida extrema y desesperada.

¿Realizó pruebas de rendimiento? ¿Ha confirmado que lanzar una excepción en esta excepcional caso es un cuello de botella para su aplicación? Parece una micro optimización en este caso. ¿No puedes hacer feliz a este servidor web al forjar una solicitud válida y obtener 200 al final? Si no, ¿no puedes cambiar a un servidor web más estándar?

+0

Hola Darin Gracias por su respuesta. Usted hace buenos puntos. Siento que las excepciones (debido a su costo) deberían ser opcionales, y estoy sorprendido de que no haya forma de eludir esto. Sus soluciones alternativas son buenas ideas. Voy a investigar más ... – James

+0

Acepto y, lo que es más importante, los servicios web comúnmente devuelven los códigos de estado 400 y 500 para informar entradas inválidas a las llamadas de servicio. En muchos casos, estos no son errores. Por ejemplo, obtenemos 400 códigos de estado devueltos de un determinado servicio web solo para indicar que no hay ningún registro disponible, aunque no es un error. El cuerpo de la respuesta todavía está json con un mensaje para nosotros. Así que estoy de acuerdo en que sería ideal para desactivar las excepciones, razón por la cual yo y muchos otros estamos buscando esta publicación. –

1

Establecer la propiedad AllowAutoRedirect en HttpWebRequest en false evitará que se produzca una excepción cuando un servidor envía un código de estado 300.

No impide que los códigos de estado 404 emitan una excepción.

9

Si desea recuperar la respuesta de error de errores 4xx puede hacerlo de esta manera:

HttpWebResponse res = null; 
string response = string.Empty; 
StreamReader sr = null; 
Stream resst = null; 
try 
{ 
    res = (HttpWebResponse)req.GetResponse(); 
    resst = res.GetResponseStream(); 
    sr = new StreamReader(resst); 
    response = sr.ReadToEnd(); 
} 
catch (WebException exception) 
{ 
    HttpWebResponse errorResponse = (HttpWebResponse)exception.Response; 
    resst = errorResponse.GetResponseStream(); 
    sr = new StreamReader(resst); 
    response = sr.ReadToEnd(); 
} 
this.Response.Write(response); 

Espero que esto ayude ...

+0

esta respuesta http://stackoverflow.com/a/2676411/671619 dice lo contrario. ¿quién tiene razón? – Firo

+1

Acabo de ejecutar ese código después de obtener un 400 y devuelve los detalles de error esperados en la respuesta. – rob

+1

Tenga cuidado, [WebException.Response puede ser nulo] (https://msdn.microsoft.com/query/dev11.query?appId=Dev11IDEF1&l=EN-US&k=k%28System.Net.WebException.Response%29;k% 28TargetFrameworkMoniker-.NETFramework). –

Cuestiones relacionadas