IIS7 anula customErrors al configurar Response.StatusCode?

Tengo un problema extraño aquí. Todo el mundo sabe que si usa la customErrorssección de web.config para crear una página de error personalizada, debe configurarla Response.StatusCodeen lo que sea apropiado. Por ejemplo, si hago una página 404 personalizada y la nombro 404.aspx, podría poner <% Response.StatusCode = 404 %>el contenido para que tenga un verdadero encabezado de estado 404.

¿Me sigues tan lejos? Bueno. Ahora intente hacer esto en IIS7. No puedo hacer que funcione, punto. Si Response.StatusCodese establece en la página de error personalizada, IIS7 parece anular la página de error personalizada por completo y muestra su propia página de estado (si tiene una configurada).

¿Alguien más ha visto este comportamiento y quizás también sepa cómo solucionarlo? Funcionaba bajo IIS6, así que no sé por qué cambiaron las cosas.

Nota: Esto no es lo mismo que el problema en ASP.NET Custom 404 Devuelve 200 OK en lugar de 404 Not Found

Establezca existingResponse en PassThrough en la sección system.webServer / httpErrors:

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

El valor predeterminado de la propiedad existingResponse es Auto:

Auto le dice al módulo de error personalizado que haga lo correcto . El texto de error real visto por los clientes se verá afectado según el valor de fTrySkipCustomErrors devuelto en la IHttpResponse::GetStatusllamada. Cuando f TrySkipCustomErrors se establece en verdadero, el módulo de error personalizado dejará pasar la respuesta, pero si se establece en falso, el módulo de errores personalizados reemplaza el texto con su propio texto.

Más información: Qué esperar del módulo de error personalizado IIS7

La forma más sencilla de hacer que el comportamiento sea coherente es borrar el error y usar Response.TrySkipIisCustomErrors y establecerlo en true. Esto anulará el manejo de la página de error global de IIS desde dentro de su página o el controlador de error global en Application_Error.

Server.ClearError();
Response.TrySkipIisCustomErrors = true;

Por lo general, debe hacer esto en su controlador Application_Error que maneja todos los errores que los controladores de errores de su aplicación no detectan.

Puede encontrar información más detallada en esta publicación de blog: http://www.west-wind.com/weblog/posts/745738.aspx

Resuelto: Resulta que "Errores detallados" debe estar activado para que IIS7 "pase a través" de cualquier página de error que pueda tener. Ver http://forums.iis.net/t/1146653.aspx

No estoy seguro de si esto es de naturaleza similar o no, pero resolví un problema que suena similar en la superficie y así es como lo manejé.

En primer lugar, el valor predeterminado para existingResponse (Auto) fue la respuesta correcta en mi caso, ya que tengo un 404, 400 y 500 personalizado (podría crear otros, pero estos tres serán suficientes para lo que estoy haciendo). Aquí están las secciones relevantes que me ayudaron.

Desde web.config:

<customErrors mode="Off" />

Y

<httpErrors errorMode="Custom" existingResponse="Auto" defaultResponseMode="ExecuteURL">
  <clear />
  <error statusCode="404" path="/errors/404.aspx" responseMode="ExecuteURL" />
  <error statusCode="500" path="/errors/500.aspx" responseMode="ExecuteURL" />
  <error statusCode="400" path="/errors/400.aspx" responseMode="ExecuteURL" />
</httpErrors>

A partir de ahí, agregué esto a Application_Error en global.asax:

    Response.TrySkipIisCustomErrors = True

En cada una de mis páginas de error personalizadas, tuve que incluir el código de estado de respuesta correcto. En mi caso, estoy usando un 404 personalizado para enviar usuarios a diferentes secciones de mi sitio, por lo que no quiero que se devuelva un código de estado 404 a menos que en realidad sea una página muerta.

De todos modos, así es como lo hice. Espero que ayude a alguien.

Este problema ha sido un gran dolor de cabeza. Ninguna de las sugerencias mencionadas anteriormente me resolvió por sí sola, así que incluyo mi solución. Para el registro, nuestro entorno / plataforma utiliza:

• .NET Framework 4
• MVC 3
• IIS8 (estación de trabajo) e IIS7 (servidor web)

Específicamente, estaba tratando de obtener una respuesta HTTP 404 que redirigiera al usuario a nuestra página personalizada 404 (a través de la configuración de Web.config).

Primero, mi código tenía que lanzar un HttpException. Devolver un NotFoundResultdel controlador no logró los resultados que buscaba.

throw new HttpException(404, "There is no class with that subject");

Luego tuve que configurar tanto el customErrorsy httpErrornodos en el Web.config.

<customErrors mode="On" defaultRedirect="/classes/Error.aspx">
  <error statusCode="404" redirect="/classes/404.html" />
</customErrors>

...

<httpErrors errorMode="Custom" existingResponse="Auto" defaultResponseMode="ExecuteURL">
  <clear />
  <error statusCode="404" path="/classes/404.aspx" responseMode="ExecuteURL" />
</httpErrors>

Tenga en cuenta que dejé el existingResponseas Auto, que es diferente a la solución que proporcionó @sefl.

La customErrorsconfiguración parecía ser necesaria para manejar mi lanzamiento explícito HttpException, mientras que el httpErrorsnodo manejaba las URL que quedaban fuera de los patrones de ruta especificados en Globals.asax.cs.

PD: Con esta configuración no necesitaba configurar Response.TrySkipIisCustomErrors

TrySkipIisCustomErrorses solo una parte de un rompecabezas. Si usa páginas de error personalizadas pero también desea entregar contenido RESTful basado en estados 4xx, entonces tiene un problema. Configurar httpErrors.existingResponse de web.config en "Auto" no funciona, porque .net parece entregar siempre parte del contenido de la página a IIS, por lo tanto, usar "Auto" hace que no se utilicen todas (o al menos algunas) las páginas de error personalizadas. El uso de "Reemplazar" tampoco funcionará, porque la respuesta contendrá su código de estado http, pero su contenido estará vacío o lleno de una página de error personalizada. Y el "PassThrough" de hecho apaga el CEP, por lo que no se puede usar.

Entonces, si desea omitir CEP en algunos casos (al omitir me refiero a devolver el estado 4xx con algún contenido), necesitará un paso adicional: limpiar el error:

void Application_Error(object sender, EventArgs e)
{
    var httpException = Context.Server.GetLastError() as HttpException;
    var statusCode = httpException != null ? httpException.GetHttpCode() : (int)HttpStatusCode.InternalServerError;

    Context.Server.ClearError();
    Context.Response.StatusCode = statusCode;
}

Entonces, si desea usar la respuesta REST (es decir, 400 - Solicitud incorrecta) y enviar algo de contenido con ella, solo tendrá que establecer TrySkipIisCustomErrorsen algún lugar en acción y establecer existingResponseen "Auto" en la sección httpErrors en web.config. Ahora:

• cuando no hay error (la acción devuelve 4xx o 5xx) y se devuelve algún contenido, el CEP no se utiliza y el contenido se pasa al cliente;
• cuando hay un error (se lanza una excepción), el contenido devuelto por los controladores de errores se elimina, por lo que se usa el CEP.

Si desea devolver el estado con contenido vacío de su acción, se tratará como una respuesta vacía y se mostrará CEP, por lo que hay espacio para mejorar este código.

De forma predeterminada, IIS 7 utiliza mensajes de error personalizados detallados, por lo que supongo que Response.StatusCode será igual a 404.XX en lugar de solo 404.

Puede configurar IIS7 para usar los códigos de mensaje de error más simples o modificar su código manejando los mensajes de error más detallados que ofrece IIS7.

Más información disponible aquí: http://blogs.iis.net/rakkimk/archive/2008/10/03/iis7-enabling-custom-error-pages.aspx

Investigaciones posteriores revelaron que lo tenía al revés: los mensajes detallados no son predeterminados, pero tal vez se hayan activado en su caja si está viendo los diferentes mensajes de error que ha mencionado.