Error de Coldfusion y páginas de error de IIS7.5

Para permitir que ColdFusion muestre sus errores en lugar de solo el error del servidor (código 500), he agregado a web.config según algunos hallazgos en este sitio.Error de Coldfusion y páginas de error de IIS7.5

El problema parece estar resuelto, pero ...

Cuando visito un directorio no existía en el IIS, se volvió una página "en blanco" sin ningún código de estado. Si configuro de nuevo el paso a automático, el IIS vuelve a tomar la página de error y no se muestran más errores de ColdFusion.

¿Alguien tiene una solución? Investigué un poco y "sospeché" que JWildcardhandler tal vez era el problema, pero no pude encontrar una solución a esto.

¡Muy apreciado!

Fuente

2011-02-11 Benz

Piensa que una buena idea sería mostrar las muestras de tu web.config. – Sergii

¿Está tu documento predeterminado en IIS configurado para ser index.cfm? Si está en index.aspx o index.htm, entonces podría estar intentando pasar el error 404 sin que haya un error 404 en ColdFusion. –

En las propiedades de IIS para el sitio , mira en qué está configurada la página del controlador de error 404. – eapen

En caso de que alguien se pregunta web.config de esta persona probablemente se parece a esto:

<?xml version="1.0" encoding="UTF-8"?> 
<configuration> 
    <system.webServer> 
     <httpErrors existingResponse="PassThrough" /> 
     ... 
    </system.webServer> 
</configuration>

En la versión anterior de IIS, si el script personalizado devuelve un código de error, IIS ignoró y lo dejó pasar. Pero también podría configurarlo para manejar el estado de error con scripts personalizados.

En mi antiguo servidor, si una determinada URL era un 404, IIS se creó para /404.cfm Execut, que muestra una página de error y devuelve un código de estado 404 usando <cfheader>.

Sin embargo, ahora si ese script devuelve un código de estado 404, el resultado final es que IIS devuelve un error de servidor en lugar de devolver la respuesta con el código de estado 404.

La única forma de evitar esto es usando existingResponse="PassThrough" y luego utilizando una plantilla de "plantilla no encontrada" en todo el sitio, establecida en CFAdmin.

Aquí está la parte interesante. Tengo index.cfm configurado como el índice predeterminado, y el único índice predeterminado, para mi sitio.

Si voy a /about/, y /about/index.cfm existe, entonces muestra la página, como si le hubiera pedido /about/index.cfm. Y si voy a /about/index.cfm y /about/index.cfm existe no, se ejecuta la plantilla 404 de todo el sitio.

Pero si voy a /about//about/ y no existe como una dirección URL, no lo hace intento de cargar /about/index.cfm y así desencadenar la plantilla de todo el sitio 404. En cambio, ¡muestra una página en blanco!

Por lo que puedo decir, no hay solución viable para este problema. Parece que solo las personas que escriben en .Net pueden resolver este problema, ya que pueden poner un indicador en la Respuesta que generan y que literalmente le dice a IIS "Ignorar el código de estado". Creo que Microsoft simplemente no está interesado en dar soporte a una aplicación web alternativa.

Básicamente, esta es la solución: deshacerse de existingResponse="PassThrough" y devolver los códigos de estado equivocadas.

Cualquier otra cosa va a ser muy difícil de implementar. Tenga en cuenta que esto no funciona si está haciendo una aplicación RESTful o una API. En cuyo caso, se debe crear un directorio virtual sólo para eso, para los que se puede asignar un archivo web.config costumbre que hace uso existingResponse="PassThrough". Pero si necesita poder permitir el manejo personalizado de errores y el manejo personalizado de 404, está realmente atornillado.

La buena noticia es que, aparte de API y Ajax, la única otra vez que a alguien le importará cuál es realmente el código de estado será cuando esté mirando tus encabezados de todos modos, en cuyo caso verán que estás ejecutando IIS y solo siente pena por ti.

Fuente

2011-07-08 00:30:50

Dios mío esto apesta. ¿Cualquier actualización? ¡Gracias! – Henry

Lo he conseguido a veces para 404s pero no para ningún otro código de estado. Pero nunca es realmente consistente. –

Tenemos un CMS y todas las solicitudes van a la página raíz/index.cfm. Esa páginas procesa la URL y carga plantillas basadas en eso. (Las reglas de reescritura convierten la url en una cadena de consulta). Puedo cargar encabezados personalizados cuando no puedo encontrar la página en mi DB (404). Sin embargo, cuando la URL es root/page.cfm Recuperar como Google dice 404 al igual que Firebug/Chrome. Pero cuando la URL es root/page/Fetch, Google dice que es un 301 en sí mismo, pero Firebug/Chrome todavía me dice 404 correctamente. http://stackoverflow.com/q/14368274/1229594 Cualquier idea sería apreciada. – Leeish

Mantener el traspaso en su lugar, se puede usar una reescritura para manejar la página en blanco:

RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteRule . /404.cfm [NC,L,NS]

La reescritura significa, básicamente, - si no existen archivos y directorios, redirigir a "404.cfm también incluye. un 404 cfheader en la página 404.cfm.

Fuente

2012-10-15 03:47:34

Modifiqué RewriteRule de la siguiente manera para simular el formato de URL que IIS usa al llamar al controlador 404 (que incluye la cadena de consulta "? 404; http: // original-404-url") 'RewriteRule. */error_404.cfm \? 404; http: //% {HTTP_HOST}/$ & \?% {QUERY_STRING} [NC, L, NS] ' –

Error de Coldfusion y páginas de error de IIS7.5

Respuesta

Cuestiones relacionadas