Publicar formularios en 404 + HttpHandler en IIS7:¿Por qué han desaparecido todos los datos POST?

Question

Bien, esto puede parecer un poco confuso y complicado, así que tengan paciencia.

Hemos escrito un marco que nos permite definir URL amigables.Si navega a cualquier URL arbitraria, IIS intenta mostrar un error 404 (o, en algunos casos, 403;14 o 405).Sin embargo, IIS está configurado para que cualquier cosa dirigida a esos errores específicos se envíe a un archivo .aspx.Esto nos permite implementar un HttpHandler para manejar la solicitud y hacer cosas, lo que implica encontrar una plantilla asociada y luego ejecutar lo que esté asociado con ella.

Ahora, todo esto funciona en IIS 5 y 6 y, hasta cierto punto, en IIS7, excepto por un inconveniente, que ocurre cuando publicas un formulario.

Mira, cuando publicas un formulario en una URL inexistente, IIS dice "ah, pero esa URL no existe" y arroja un error 405 "método no permitido".Dado que le estamos diciendo a IIS que redirija esos errores a nuestra página .aspx y, por lo tanto, los manejemos con nuestro HttpHandler, esto normalmente no es un problema.Pero a partir de IIS7, toda la información POST desapareció después de ser redirigida al 405.Y por eso ya no puedes hacer las cosas más triviales que involucran formas.

Para resolver esto, intentamos usar un HttpModule, que conserva los datos POST pero parece no tener una sesión inicializada en el momento adecuado (cuando es necesaria).También intentamos usar un HttpModule para todas las solicitudes, no solo las solicitudes faltantes que llegan a 404/403; 14/405, pero eso significa que cosas como imágenes, css, js, etc. están siendo manejadas por código .NET, lo cual es terriblemente ineficiente.

Lo que me lleva a la pregunta real:¿Alguien se ha encontrado alguna vez con esto? ¿Alguien tiene algún consejo o sabe qué hacer para que todo vuelva a funcionar?Hasta ahora alguien ha sugerido usar el propio Microsoft. Módulo de reescritura de URL.¿Ayudaría esto a resolver nuestro problema?

Gracias.

Answer 1

Microsoft lanzó una revisión para esto:

http://support.microsoft.com/default.aspx/kb/956578

Answer 2

Dado que IIS7 usa .net de arriba hacia abajo, no habría ninguna sobrecarga de rendimiento al usar un HttpModule. De hecho, hay varios HttpModules administrados que siempre se usan en cada solicitud.Cuando se activa el evento BeginRequest, es posible que SessionStateModule no se haya agregado a la colección de Módulos, por lo que si intenta manejar la solicitud durante este evento, no habrá información disponible sobre el estado de la sesión.Configurar la propiedad HttpContext.Handler inicializará el estado de la sesión si el controlador solicitado lo necesita, por lo que puede configurar el controlador en su elegante página 404 que implementa IRequiresSessionState.El siguiente código debería funcionar, aunque es posible que necesites escribir una implementación diferente para el método IsMissing():

using System.Web;
using System.Web.UI;

class Smart404Module : IHttpModule
{
    public void Dispose() {}

    public void Init(HttpApplication context)
    {
        context.BeginRequest += new System.EventHandler(DoMapping);
    }

    void DoMapping(object sender, System.EventArgs e)
    {
        HttpApplication app = (HttpApplication)sender;

        if (IsMissing(app.Context))
            app.Context.Handler = PageParser.GetCompiledPageInstance(
                "~/404.aspx", app.Request.MapPath("~/404.aspx"), app.Context);
    }

    bool IsMissing(HttpContext context)
    {
        string path = context.Request.MapPath(context.Request.Url.AbsolutePath);

        if (System.IO.File.Exists(path) || (System.IO.Directory.Exists(path)
            && System.IO.File.Exists(System.IO.Path.Combine(path, "default.aspx"))))
            return true;
        return false;
    }
}

Editar:Agregué una implementación de IsMissing()

Nota:En IIS7, el módulo de estado de sesión no se ejecuta globalmente de forma predeterminada.Hay dos opciones:Habilite el módulo de estado de sesión para todas las solicitudes (consulte mi comentario anterior sobre la ejecución de módulos administrados para todos los tipos de solicitudes), o puede usar la reflexión para acceder a los miembros internos dentro de System.Web.dll.

Answer 3

El problema en IIS 7 de que las variables de publicación no se pasaran a los controladores de errores personalizados se solucionó en el service pack 2 para Vista.No lo he probado en Windows Server, pero estoy seguro de que también se solucionará allí.

Answer 4

Solo una suposición:el controlador especificado en %windir%\system32\inetsrv\config\applicationhost.config de IIS7 que maneja su solicitud no permite que el verbo POST pase en absoluto y está evaluando esa regla antes de determinar si la URL no existe. .

Answer 5

Sí, definitivamente recomendaría reescribir la URL (usando IIS7 de Microsoft o una de las muchas alternativas).Esto está diseñado específicamente para proporcionar URL amigables, mientras que los documentos de error son un último recurso para las fallas, que tienden a alterar los datos entrantes, por lo que es posible que no sean lo que espera.