Publicação de formulários para um 404 + HttpHandler no IIS7: falta porque tem todos os dados POST desaparecido?

Question

OK, isso pode parecer um pouco confuso e complicado, para ter comigo.

Nós escrevemos uma estrutura que nos permite definir URLs amigáveis. Se você navegar a qualquer URL arbitrário, o IIS tenta exibir um erro 404 (ou, em alguns casos, 403; 14 ou 405). No entanto, o IIS é configurado para que qualquer coisa dirigida a esses erros específicos é enviado para um arquivo .aspx. Isso nos permite implementar um HttpHandler para manipular a solicitação e fazer coisas, que envolve encontrar a um modelo associado e, em seguida, a execução de tudo o que está associado a ele.

Agora, tudo isso funciona no IIS 5 e 6 e, em certa medida, no IIS7 -. Mas para uma captura, o que acontece quando você postar um formulário

Veja, quando você postar um formulário para um URL inexistente, o IIS diz "ah, mas isso url não existe" e lança um erro 405 "método não permitido". Desde que nós estamos dizendo o IIS para redirecionar esses erros para nossa página .aspx e, portanto, manuseá-lo com a nossa HttpHandler, isso normalmente não é um problema. Mas a partir de IIS7, todas as informações POST desapareceu depois de ser redirecionado para o 405. E para que você não pode fazer a mais trivial das coisas que envolvem formas.

Para resolver isso, tentei usar um HttpModule, que preserva dados POST, mas parece não ter uma sessão iniciada no momento certo (quando necessário). Também tentei usar um HttpModule para todas as solicitações, não apenas os pedidos que faltam que atingiram 404/403;. 14/405, mas isso significa que coisas como imagens, css, js etc estão sendo manipulados por código .NET, que é terrivelmente ineficiente

O que me traz à questão real: alguém já encontrou este, e alguém tem algum conselho ou saber o que fazer para conseguir as coisas funcionando novamente? Até agora, alguém sugeriu o uso próprio URL Reescrevendo módulo . Será que isso ajuda a resolver o nosso problema?

Graças.

Answer 1

A Microsoft lançou uma correcção para este:

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

Answer 2

Desde IIS7 usa .net de cima para baixo, não haveria qualquer sobrecarga de usar um HttpModule desempenho, Na verdade, existem vários Managed HttpModules que são sempre utilizados em cada solicitação. Quando o evento BeginRequest é acionado, o SessionStateModule pode não ter sido adicionados à coleção Modules, por isso, se você tentar lidar com o pedido durante este evento nenhuma sessão informação de estado estarão disponíveis. Definir a propriedade HttpContext.Handler irá inicializar o estado da sessão se o manipulador solicitado precisa dele, assim você pode apenas definir o manipulador a sua fantasia página 404 que implementa IRequiresSessionState. O código a seguir deve fazer o truque, embora você pode precisar de escrever uma aplicação diferente para o IsMissing () método:

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;
    }
}

Edit: Eu adicionei uma implementação de IsMissing ()

Nota: No IIS7, o módulo de estado de sessão não funciona globalmente por padrão. Existem duas opções: Ativar o módulo de estado de sessão para todos os pedidos (ver o meu comentário acima sobre executando módulos gerenciados para todos os tipos de solicitação), ou você pode usar a reflexão para acessar membros internos dentro System.Web.dll

.

Answer 3

O problema no IIS 7 de variáveis ??post não sendo repassados ??para manipuladores de erro personalizadas é corrigido no Service Pack 2 para o Vista. Já não tentei no Windows Server, mas eu tenho certeza que ele será corrigido lá também.

Answer 4

Apenas um palpite: o manipulador especificado no IIS7 é% windir% \ system32 \ inetsrv \ config \ ApplicationHost.config que está a lidar com o seu pedido não está permitindo que o POST verbo para passar em tudo, e que está avaliando essa regra antes de determinar se o URL não existe.

Answer 5

Sim, eu recomendaria definitivamente a reescrita de URL (usando o Microsoft IIS7 um ou uma das muitas alternativas). Este é projetado especificamente para fornecer URLs amigáveis, enquanto documentos de erro são um recuo de última hora para falhas, o que tende a munge os dados recebidos por isso não pode ser o que você espera.