origin - ASP.NET Web Api HttpResponseException 400(Solicitud incorrecta) secuestrada por IIS

enable cors web config (6)

Estaba golpeando esta misma condición, volviendo:

httpResponseMessage = context.Request.CreateResponse(statusCode);

La adición de <httpErrors existingResponse = "PassThrough"> no lo solucionó, el tipo de contenido y el cuerpo del contenido faltaban en la respuesta.

Lo que se arregló fue construir el HttpResponseMessage de esta manera:

var httpResponseMessage = context.Request.CreateResponse(statusCode, reasonPhrase);

Al incluir el parámetro ''valor'' (en este caso, ''reasonPhrase''), el tipo de contenido y el cuerpo del contenido estaban presentes en la respuesta.

Estoy escribiendo un servicio de API web y estoy intentando devolver una solicitud incorrecta (400) si mi ModelState no es válido. No quiero adjuntar un cuerpo de respuesta a esto. Parece que IIS está secuestrando mi respuesta y siempre devuelve un tipo de contenido de texto / html con una página de error larga y con estilo. Esto es un problema.

[HttpPost] public void Link(LinkDeviceModel model) { if (ModelState.IsValid) { try { model.Save(); } catch (Exception ex) { ErrorSignal.FromCurrentContext().Raise(ex); throw new HttpResponseException(ex.Message, HttpStatusCode.InternalServerError); } } else { throw new HttpResponseException(HttpStatusCode.BadRequest); } }

Aquí está mi solicitud de violinista:

POST http://localhost/myapp/service/link HTTP/1.1 Host: localhost Content-Length: 112 Content-Type: application/json Accept: application/json {"DeviceUniqueId":"CC9C6FC0-7D06-11E1-8B0E-31564824019B", "UserName": "[email protected]"," Pin": "111111"}

Y mi respuesta errónea, llena de cuerpo, respuesta:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>IIS 7.5 Detailed Error - 400.0 - Bad Request</title> <style type="text/css">  </style> </head> <body> <div id="header"><h1>Server Error in Application "DEFAULT WEB SITE/MYAPP"</h1></div> <div id="server_version"><p>Internet Information Services 7.5</p></div> <div id="content"> <div class="content-container"> <fieldset><legend>Error Summary</legend> <h2>HTTP Error 400.0 - Bad Request</h2> <h3>Bad Request</h3> </fieldset> </div> <div class="content-container"> <fieldset><legend>Detailed Error Information</legend> <div id="details-left"> <table border="0" cellpadding="0" cellspacing="0"> <tr class="alt"><th>Module</th><td>ManagedPipelineHandler</td></tr> <tr><th>Notification</th><td>ExecuteRequestHandler</td></tr> <tr class="alt"><th>Handler</th><td>System.Web.Http.WebHost.HttpControllerHandler</td></tr> <tr><th>Error Code</th><td>0x00000000</td></tr> </table> </div> <div id="details-right"> <table border="0" cellpadding="0" cellspacing="0"> <tr class="alt"><th>Requested URL</th><td>http://localhost:80/myapp/service/link</td></tr> <tr><th>Physical Path</th><td>C:/workspace/myapp/service/link</td></tr> <tr class="alt"><th>Logon Method</th><td>Anonymous</td></tr> <tr><th>Logon User</th><td>Anonymous</td></tr> </table> <div class="clear"></div> </div> </fieldset> </div> <div class="content-container"> <fieldset><legend>Most likely causes:</legend> <ul> <li></li> </ul> </fieldset> </div> <div class="content-container"> <fieldset><legend>Things you can try:</legend> <ul> <li>Create a tracing rule to track failed requests for this HTTP status code. For more information about creating a tracing rule for failed requests, click <a href="http://go.microsoft.com/fwlink/?LinkID=66439">here</a>. </li> </ul> </fieldset> </div> <div class="content-container"> <fieldset><legend>Links and More Information</legend> The request could not be understood by the server due to malformed syntax. <p><a href="http://go.microsoft.com/fwlink/?LinkID=62293&IIS70Error=400,0,0x00000000,7601">View more information »</a></p> <p>Microsoft Knowledge Base Articles:</p> <ul><li></li></ul> </fieldset> </div> </div> </body> </html>

He intentado configurar TrySkipIisCustomErrors = True con gran esperanza, pero no tengo suerte. ¿Algunas ideas? Apreciado. Gracias.

Intenta agregar esto a tu web.config. Tuve un problema muy similar que este resuelto.

<configuration> <system.webServer> <httpErrors existingResponse="PassThrough" /> </system.webServer> </configuration>

Por lo general, en tales casos, es suficiente establecer TrySkipIisCustomErrors = true en el objeto de respuesta, pero en el caso de la API web a veces no funciona (la API web incluso intenta establecer esta marca internamente). Para situaciones como esta, puede considerar cambiar la configuración de IIS. Por favor, eche un vistazo here (debería estar interesado principalmente en existingResponse = "PassThrough").

Suponiendo que está dentro de su APIController y no necesita un ExceptionFilterAttribute para realizar ningún trabajo adicional para la respuesta, simplemente devuelva una respuesta con el código de estado de error en lugar de lanzar una HttpResponseException.

return Request.CreateResponse(HttpStatusCode.BadRequest, "Invalid model.");

Tuve el mismo problema con la aplicación Web Form de Asp.Net. El cliente envía una llamada ajax al controlador web del servidor (* .ashx).

Quería devolver el mensaje de excepción al usuario. El controlador web envía solo el mensaje de excepción y el código de estado de http 400.

El truco está en Response.TrySkipIisCustomErrors = true;

try { //do some coding } catch (Exception exception) { Log.Error(exception); context.Server.ClearError(); context.Response.TrySkipIisCustomErrors = true; context.Response.ContentType = "text/plain"; context.Response.Write(exception.Message); context.Response.StatusCode = 400; //400 Bad Request //The server cannot or will not process the request due to an apparent client error // //intentionally hidden exception //prevent to send yellow page of death in ajax response }

Tuve una situación en la que estaba llamando a un punto final de WebApi desde otro, y al leer que HttpClients debería ser estático, hice ese cambio. Funcionó bien durante unas pocas docenas de mensajes, pero luego sería interceptado por la instancia de auto-host que devolvería una 400 Solicitud incorrecta. No parecía haber nada malo, especialmente con el éxito inicial, pero mi código original agregaría un encabezado predeterminado al cliente antes de la llamada. Después de hacer el cliente estático, esto habría significado que estaba agregando el encabezado varias veces al mismo cliente. Cambié el código para enviar crear y enviar un HttpRequestMessage en lugar de dejar que el cliente lo hiciera, y agregué el encabezado a la solicitud. Parece haber resuelto mi problema.