Reescrita de URL (1): IIS por ASP.NET

Autor：Eve Cole Data da Última Atualização：2009-06-29 23:46:48

A reescrita de URL é aceita há muito tempo pela maioria dos desenvolvedores e existem inúmeros componentes e artigos sobre reescrita de URL na Internet. No entanto, sempre sinto que ainda estou insatisfeito, então, no final, não pude deixar de escrever esta série. de artigos. Esses artigos não falarão sobre o valor e a importância da reescrita de URL, mas apenas sobre conteúdo puramente técnico. O artigo não fornecerá uma análise detalhada da implementação, mas combinará minha experiência para explicar este tópico do ponto de vista da aplicação. O que você já sabe, o que ainda não sabe, o que foi mencionado em outro lugar, ou o que ainda não foi mencionado, espero que a “revisita de coisas antigas” nesta série de artigos não o deixe entediado, e pode ajudá-lo a entender todos os aspectos do ASP.NET. Se você encontrar problemas com a reescrita de URL no futuro, se conseguir pensar nesses artigos, acho que vou rir alto em meus sonhos.

Para compreender completamente os tópicos discutidos posteriormente neste artigo, devemos compreender brevemente o processo de comunicação entre IIS e ASP.NET. O que estou explicando aqui é o servidor IIS 6. Quanto ao IIS 5 e IIS 7, pode-se dizer que o primeiro foi eliminado, enquanto o "modo clássico" do último é exatamente igual ao IIS 6, e o novo "modo pipeline" na verdade fala sobre alguns conceitos em ASP. NET e IIS. Integração profunda. Acredito que se você entender IIS 6 e ASP.NET, não terá problemas no modo integrado do IIS 7.

Primeiro, vamos dar uma olhada em um diagrama esquemático simples, mostrando várias etapas principais em todo o processo do IIS, desde o recebimento da solicitação até o retorno da resposta:

O IIS recebe a solicitação.
O seletor seleciona uma ISAPI para tratar a solicitação com base nas características da URL e na configuração no IIS - agora é natural escolher ASP.NET ISAPI.
O mecanismo de execução ASP.NET recebe a solicitação e inicializa os dados (como construir vários objetos).
Comece a acionar vários eventos de Pipeline, começando naturalmente com BeginRequest.
Após vários eventos de Pipeline, o ASP.NET seleciona um Handler ou HandlerFactory adequado para a solicitação atual de acordo com a configuração (exceto em circunstâncias especiais, como a saída direta dos resultados e o encerramento da solicitação no evento anterior).
Após ser processado pelo Handler, ele passa por diversos eventos do Pipeline e termina com EndRequest.
Resposta de saída.

Se você deseja executar a reconfiguração de URL em um aplicativo ASP.NET, geralmente chama o método RewritePath de HttpContext no evento BeginRequest para reposicionar a solicitação em uma URL de destino. Por exemplo, podemos substituir o método Application_BeginRequest em Global.asax para conseguir isso:

A razão pela qual Rewrite é executado em BeginRequest é porque este evento é o primeiro acionado entre todos os eventos de Pipeline. Após o reposicionamento neste momento, algumas propriedades no HttpContext atual também foram alteradas de acordo (como HttpContext.Request.Path). Dessa forma, a lógica do manipulador dos seguintes eventos do Pipeline será afetada. Por exemplo, quando as permissões precisam ser determinadas com base em um diretório, o caminho "localizado" será usado em vez da solicitação recebida pelo ASP.NET. Naturalmente, a mudança mais "significativa" é a escolha do Handler. Por exemplo, no exemplo acima, realocamos a solicitação para o arquivo "CustomerList.aspx", para que o mecanismo ASP.NET selecione o System.Web.UI. correspondente a *.aspx A classe PageHandlerFactory trata de solicitações.

classe pública Global : System.Web .
{
    protegido void Application_BeginRequest ( objeto remetente, EventArgs e)
    {
        Contexto HttpContext = HttpContext .Current;

        if (context.Request.Path.Equals( "/Clientes" ,
            StringComparison.InvariantCultureIgnoreCase ))
        {
            context.RewritePath( "~/CustomerList.aspx" );
        }
    }
}

Por último, há dois conceitos que precisam ser diferenciados, a saber, "ASP.NET Pipeline" e "Web Forms". Ambos são modelos importantes em ASP.NET, mas as diferenças ainda são muito grandes:

Pipeline ASP.NET: Assim como toda solicitação recebida por uma aplicação ASP.NET, ela será processada através deste "pipeline". Este é um modelo de nível ASP.NET.
Web Forms: Durante a execução do ASP.NET Pipeline, uma das etapas é selecionar um Handler (ou HandlerFactory) adequado para tratar a solicitação. Se for uma página aspx, o ASP.NET escolherá a classe System.Web.UI.PageHandlerFactory, na qual o modelo WebForms é finalmente formado .

Na verdade, a palavra “forma” na frase acima pode não ser precisa. Porque os Web Forms provavelmente deveriam ser um mecanismo de execução e um modelo que pode ser usado de forma independente, e System.Web.UI.PageHandlerFactory usa apenas esse modelo. Quando escrevemos aplicações ASP.NET, podemos usar este modelo em outros locais de acordo com nossas necessidades. Por exemplo, no artigo " Técnica: Usando Controle de Usuário para Geração de HTML ", usamos ascx como modelo em um Manipulador Genérico para gerar conteúdo.