Como modificar cabeçalhos de resposta HTTP
por Ruslan Yakushev
Esta seção da documentação se aplica à versão 2.0 do Módulo de reescrita de URL do IIS 7.
Este passo a passo orienta você sobre como usar o Módulo de Regravação de URL v 2.0 para definir cabeçalhos de resposta HTTP.
Pré-requisitos
Este passo a passo requer os seguintes pré-requisitos:
- IIS 7 ou superior com serviço de função do ASP.NET habilitado;
- versão Release Candidate do Módulo de Regravação de URL 2.0 instalada;
- Passo a passo concluído no Proxy Reverso com Regravação de URL v2 e Application Request Routing.
Introdução
O Módulo de Regravação de URL 2.0 fornece suporte para a reescrita baseada em regras dos cabeçalhos HTTP de resposta. Um cenário de uso muito comum para definir os cabeçalhos de resposta é modificar a resposta de redirecionamento gerada por um aplicativo por trás de um balanceador de carga ou um proxy reverso. Por exemplo, quando um aplicativo por trás de um proxy reverso retorna uma resposta de redirecionamento, o cabeçalho local HTTP na resposta pode não representar o endereço voltado para a Internet, mas sim um endereço de aplicativo interno. O Módulo de Reescrita de URL 2.0 pode ser usado no servidor proxy reverso para modificar o cabeçalho Local na resposta. O cenário é representado no seguinte diagrama:
- Um cliente HTTP faz uma solicitação para uma página da Web
http://www.contoso.com/webmail/oldpage.aspx
. - O servidor proxy reverso usa a Regravação de URL 2.0 e o Application Request Routing para encaminhar a solicitação para um servidor de conteúdo interno com base no nome da pasta no caminho de URL solicitado. Por exemplo:
http://webmail/oldpage.aspx
; - O aplicativo Web em execução no servidor de conteúdo emite uma resposta de redirecionamento (HTTP/1.1 301) apontando um cliente HTTP para
http://webmail/newpage.aspx
; - O servidor proxy reverso usa a Regravação de URL 2.0 para substituir o local de redirecionamento baseado interno na resposta pelo local de redirecionamento baseado na Internet:
http://www.contoso.com/webmail/newpage.aspx
.
Como configurar um cenário passo a passo
Para configurar o cenário passo a passo, conclua o passo a passo sobre Proxy Reverso com Reescrita de URL v2 e Application Request Routing. No final desse passo a passo, você deve ter um site de proxy reverso que roteia solicitações para dois aplicativos de conteúdo: webmail e payroll.
Para este passo a passo, você precisará adicionar uma lógica de redirecionamento ao aplicativo webmail. No cenário da vida real, isso provavelmente seria um redirecionamento iniciado pelo código do aplicativo Web, mas, para simplificar, neste passo a passo, você usará uma regra de redirecionamento no Módulo de Reescrita de URL.
Crie um arquivo chamado web.config na seguinte pasta:
%SystemDrive%\inetpub\webmail
Abra o arquivo em um editor de texto, cole o seguinte código XML dentro e salve o arquivo:
<?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <rewrite> <rules> <rule name="Redirect" stopProcessing="true"> <match url="^index\.aspx$" /> <action type="Redirect" url="default.aspx" /> </rule> </rules> </rewrite> </system.webServer> </configuration>
Essa é uma regra que redirecionará todas as solicitações de index.aspx para default.aspx.
Agora abra um navegador da Web e faça uma solicitação http://localhost/webmail/index.aspx
. Observe que o navegador foi redirecionado para http://localhost:8081/default.aspx
, que é basicamente uma URL interna usada pelo aplicativo Web de webmail. Agora você configurará as regras de Regravação de URL para modificar o cabeçalho local HTTP nas respostas de redirecionamento HTTP para que o navegador seja redirecionado para uma URL adequada: http://localhost/webmail/default.aspx
.
Modificando a regra de entrada para preservar o cabeçalho de host
Para poder modificar o cabeçalho local HTTP, é necessário preservar o valor original do cabeçalho de host HTTP. A regra de reescrita de saída usa o valor preservado ao modificar a resposta. Para preservar o valor original, armazene-o em uma variável de servidor temporária ORIGINAL_HOST.
- Na página de exibição de recurso de Reescrita de URL principal, selecione Exibir Variáveis de Servidor no painel Ações no lado direito:
- Na página Variáveis de Servidor Permitidas, selecione Adicionar e, em seguida, insira o nome da variável de servidor que será usada para armazenar temporariamente o valor do cabeçalho de host HTTP. Por exemplo, ORIGINAL_HOST:
- Selecione OK para salvar as alterações e, em seguida, retorne à página de exibição de recurso de Reescrita de URL principal. Depois disso, selecione a regra de entrada "Proxy Reverso para webmail" e selecione Editar.
- Na página Editar Regra de Entrada, expanda a caixa de grupo "Variáveis de Servidor" e, em seguida, selecione Adicionar e insira "ORIGINAL_HOST" para o nome da variável do servidor e "{HTTP_HOST}" para o "Valor":
Criando uma regra de saída para modificar o cabeçalho de resposta HTTP
Agora você criará uma regra de reescrita de saída que reescreve o cabeçalho local HTTP em respostas de redirecionamento para adicionar de volta a pasta do aplicativo ao caminho da URL e substituir o nome do host.
- Na página principal do modo de exibição de recurso Regravação de URL, selecione "Adicionar Regras" e, em seguida, selecione "Regra em Branco" na categoria "Regras de Saída".
- Na página "Editar Regra de Saída", nomeie a regra como "Cabeçalho de Local de Reescrita".
- Na lista suspensa "Pré-condição", escolha "<Criar Nova Pré-Condição>".
- Na caixa de diálogo "Adicionar Pré-Condição", nomeie a pré-condição como "IsRedirection"
- Selecione "Adicionar" e, em seguida, insira {RESPONSE_STATUS} como uma entrada de condição e "3\d\d" como o padrão. Essa pré-condição é usada para verificar se a resposta tem um código de status de redirecionamento, como 301, 302, 307 e assim por diante. A caixa de diálogo de pré-condição deve ser semelhante à seguinte:
- Selecione OK para retornar à página Editar Regra de Saída.
- Na caixa de grupo Correspondência, use a lista suspensa Escopo correspondente para selecionar Variável de Servidor.
- Insira RESPONSE_Location para o "Nome da variável" e "^http://[^/]+/(.*)" para o "Padrão". Isso configura a regra para operar no cabeçalho HTTP de resposta "Local" e corresponder seu valor a um padrão regex que armazena o caminho da URL em uma referência inversa.
- Expanda a caixa de grupo "Condições", selecione "Adicionar" e insira {ORIGINAL_HOST} como uma entrada de condição e ".+" como um padrão de condição. Essa condição verifica se a variável de servidor temporário ORIGINAL_HOST existe e tem um valor não vazio.
- Selecione Adicionar mais uma vez e adicione outra condição. Defina a entrada de condição como {URL} e o padrão como "^/(webmail|payroll)/.*". Essa expressão regular é usada para corresponder aos caminhos de URL que começam com /webmail ou /payroll. Além disso, o parêntese dentro do padrão captura a parte da cadeia de caracteres de URL correspondente, de modo que ela possa ser reutilizada ao construir a URL de substituição.
- Por fim, na caixa de grupo "Ação", escolha a ação "Reescrever" e insira "
http://{ORIGINAL_HOST}/{C:1}/{R:1}
" como um valor. Essa ação substitui o valor do cabeçalho local HTTP por uma cadeia de caracteres construída usando o nome do host da variável de servidor, a referência inversa de condição que contém o prefixo da pasta de caminho de URL e a referência inversa da regra que contém o caminho da URL atual no cabeçalho Local.
A página completa deve ser semelhante à seguinte:
Como testar a regra
Para testar se as regras funcionam corretamente, abra um navegador da Web e faça uma solicitação para http://localhost/webmail/index.aspx
. O navegador deve ser redirecionado para http://localhost/webmail/default.aspx
:
Resumo
Nesse passo a passo:
- Você aprendeu a usar vários novos recursos na Regravação de URL 2.0 para implementar um cenário de proxy reverso totalmente funcional.
- Você configurou a regra de entrada para encaminhar as solicitações para um servidor de conteúdo de back-end e definir uma variável de servidor temporária.
- Em seguida, você definiu uma regra de saída que modifica o cabeçalho local HTTP na resposta de redirecionamento gerada pelo aplicativo Web do servidor de conteúdo de back-end.