Em artigos anteriores falamos sobre vários aspectos principais da reescrita de URL. No último artigo desta série, discutiremos alguns detalhes e características dos diferentes níveis de reescrita de URL.
Teoricamente, a reescrita de URL no nível IIS escrita em C ou C++ tem desempenho superior à reescrita de URL no nível ASP.NET escrita em código gerenciado. Mas acho que a diferença nesta área é insignificante na maioria dos casos, e é quase impossível que esse desempenho se torne um gargalo de desempenho. Portanto, o nível de reescrita de URL escolhido geralmente não é determinado pelos requisitos de desempenho do seu aplicativo. Então, qual nível de reescrita de URL deve ser usado? Depois de usar diferentes níveis de reescrita de URL, em que devemos prestar atenção? Estou aqui para falar sobre minhas opiniões pessoais.
Embora o componente atual de reescrita de URL possa atender à maioria das aplicações em termos de funcionalidade, em algum momento ainda precisaremos de algumas funções especiais. Por exemplo, URL Rewrite baseado no nome de domínio não é fácil de conseguir com o componente URL Rewrite atual. O ISAPI Rewrite comercial pode atualmente suportar isso. Infelizmente, o código aberto UrlRewriter.NET e IIRF têm funções insuficientes nesse sentido. Todos eles são correspondidos com base no caminho da solicitação em relação ao site, e o nome de domínio solicitado não pode ser usado como condição de correspondência. Isso exige que estendamos o componente URL Rewrite. Para a maioria dos desenvolvedores .NET, o código gerenciado é naturalmente a primeira escolha para desenvolvimento. Neste momento, pode ser necessário escolher o componente de reescrita de reescrita de URL no nível ASP.NET. No entanto, muitos exemplos de extensões podem ser encontrados na Internet, seja UrlRewriter.NET no nível ASP.NET ou IIRF no nível IIS.
Mas, na verdade, se quisermos alcançar as funções acima, também podemos fazê-lo em duas etapas. Primeiro usamos IIRF para reescrita de URL no nível IIS e, em seguida, reescrita de URL no nível ASP.NET. Por exemplo, se agora quisermos reescrever " http://jeffz.domain.com/articles " para "/ArticleList.aspx?owner=jeffz", podemos primeiro deixar o IIRF fazer a primeira reescrita de URL, com o propósito de reescrever "/articles" é reescrito para "/ArticleList.aspx".
RewriteRule ^/Articles$ /ArticleList.aspx [I, L, U]
Dessa forma, o mecanismo ASP.NET receberá diretamente uma solicitação para /ArticleList.aspx. Então, dentro do ASP.NET, podemos fazer a segunda reescrita de URL (por conveniência, ainda escrevo em Global.asax e é recomendado usar HttpModule adicional no projeto).
protegido void Application_BeginRequest ( objeto remetente, EventArgs e)
{
Contexto HttpContext = HttpContext .Current;
string host = context.Request.Url.Host;
string proprietário = host.Substring(0, host.IndexOf( '.' ));
context.RewritePath(context.Request.RawUrl + "?proprietário=" + proprietário);
}
Após duas reescritas de URL, o efeito que desejamos foi alcançado (em projetos reais, o código acima não pode ser usado diretamente porque precisa ser avaliado se existe uma Query String, etc.).
Além disso, a reescrita de URL no nível ASP.NET só pode funcionar no ASP.NET (coisa óbvia). Se você deseja que a reescrita de URL suporte outras tecnologias de servidor, como PHP, RoR, etc., você só pode usar a reescrita de URL no nível IIS). (ou outra função de reescrita de URL fornecida pela tecnologia de servidor).
Alguns caracteres especiais não podem aparecer em URLs ou, uma vez que aparecem em URLs, o significado da solicitação é alterado. Por exemplo, precisamos reescrever o URL na página de pesquisa, reescrever "/Search/xxx" para "/Search.aspx?xxx" e, em seguida, obter as palavras-chave fornecidas pelo usuário com base na string após o ponto de interrogação. Se estiver usando UrlRewriter.NET, usaremos a seguinte configuração:
< rewriter >
< reescrever url = " ^/Pesquisar/(.+)$ " para = " ~/Search.aspx?$1 " processando = " parar " />
</ rewriter >
Em circunstâncias normais, esta reescrita de URL funciona normalmente. Mas se o usuário usar "%" como palavra-chave, a situação é diferente, pois receberemos o seguinte prompt de página de erro:
Isso ocorre porque “%” não é permitido no URL. Você pode acessar vários sites e tentar solicitar alguns caminhos como "ABC%25DEF" ("%25" é seguido por "%"), e a maioria deles encontrará erros "400 Bad Request". No entanto, é legal colocar "%" na Query String - sim, não reescrevemos a palavra-chave na Query String? Por que ainda não funciona? Isso também é determinado pela forma como o ASP.NET é executado.
Bad Request é determinado na etapa 3 da figura acima, ou seja, enquanto ainda está sendo inicializado. Nossa URL Rewrite ocorre apenas no evento BeginRequest na etapa 4. Quando a solicitação contém caracteres ilegais, não temos chance de realizar a reescrita de URL.
Então, como lidamos com esse problema? Em circunstâncias normais, não será um grande problema se removermos % do cliente (alguns sites fazem isso), mas e se tivermos que mantê-lo? Em seguida, use Query String para passar parâmetros ou também podemos usar a reescrita de URL no nível do IIS. Ainda tomando o IIRF como exemplo:
RewriteRule ^/Search/(.+)$ /Search.aspx?$1 [I, L, U]
Quando a solicitação é enviada ao IIS (etapa 1) e após selecionar qual ISAPI deve ser entregue terminado para execução (Etapa 2) A reescrita de URL ocorreu antes. Após a reescrita do URL, o "%" no endereço foi transferido para a string de consulta e é naturalmente legal quando entregue ao ASP.NET para processamento.
Finalmente, vamos discutir a configuração da página de erro. Por exemplo, geralmente configuraremos uma página de erro 404 para a aplicação, para que quando o usuário acessar um recurso inexistente, possamos mostrar a ele uma página específica em vez do prompt de erro padrão. Mas neste ponto, diferentes níveis de reescrita de URL devem ser configurados usando métodos diferentes.
Se usarmos a reescrita de URL no nível ASP.NET, de modo geral, configuramos o mapeamento curinga no IIS, para que qualquer solicitação (incluindo html, jpg, etc.) seja processada pelo ASP.NET. Caso seja solicitado um recurso que não existe, um erro 404 será emitido pelo ASP.NET, portanto a página de erro 404 deverá ser configurada no web.config:
< customErrors modo = " Ligado " defaultRedirect = " GenericErrorPage.htm " >
< erro statusCode = " 404 " redirecionamento = " FileNotFound.htm " />
</ customErrors >
Se usarmos a reescrita de URL no nível IIS, não configuraremos o mapeamento curinga. Em outras palavras, o mecanismo ASP.NET só começará a funcionar quando o endereço após Rewrite for aspx (ou outras coisas que deveriam ter sido tratadas pelo ASP.NET ISAPI). Caso o usuário solicite um recurso que não existe, um erro 404 será emitido pelo IIS. Neste momento, a página de erro 404 deverá ser configurada no IIS:
Até agora, o tópico URL Rewrite foi discutido. No desenvolvimento real, você definitivamente encontrará várias situações diferentes, mas contanto que você entenda a chave do método de reescrita de URL e pense de acordo com a forma como o programa é executado, acredito que geralmente você não encontrará problemas difíceis.