Reescrever cabeçalhos HTTP e URL com o Gateway de Aplicativo

  • Artigo

O Gateway de Aplicativo permite que você reescreva o conteúdo selecionado de solicitações e respostas. Com esse recurso, você pode converter URLs, parâmetros de cadeia de caracteres de consulta, bem como modificar cabeçalhos de solicitação e resposta. Ele também permite adicionar condições para garantir que o URL ou os cabeçalhos especificados sejam reescritos apenas quando determinadas condições forem atendidas. Essas condições se baseiam nas informações de solicitação e resposta.

Observação

Os recursos de reescrita de cabeçalho HTTP e de URL estão disponíveis somente para a SKU do Gateway de Aplicativo v2

Tipos de reescrita compatíveis

Cabeçalhos de solicitação e resposta

Os cabeçalhos HTTP permitem que um cliente e um servidor passem informações adicionais com uma solicitação ou resposta. Ao reescrever esses cabeçalhos, você pode realizar tarefas importantes, como adicionar campos de cabeçalho relacionados à segurança, como HSTS/X-XSS-Protection, remover campos de cabeçalho de resposta que podem revelar informações confidenciais e remover informações de porta de cabeçalhos X-Forwarded-For.

O Gateway de Aplicativo permite adicionar, remover ou atualizar solicitações HTTP e cabeçalhos de resposta, enquanto os pacotes de solicitação e resposta são transferidos entre os pools de cliente e de back-end.

Para saber como reescrever cabeçalhos de solicitação e de resposta com o Gateway de Aplicativo usando o portal do Azure, consulte aqui.

img

Cabeçalhos compatíveis

Você pode reescrever todos os cabeçalhos em solicitações e respostas, exceto para os cabeçalhos Conexão e Atualização. Você também pode usar o gateway de aplicativo para criar cabeçalhos personalizados e adicioná-los às solicitações e respostas que estão sendo roteadas por ele.

Caminho de URL e cadeia de caracteres de consulta

Com a capacidade de reescrita de URL no Gateway de Aplicativo, você pode:

  • Reescrever o nome do host, o caminho e a cadeia de caracteres de consulta da URL de solicitação

  • Escolha reescrever a URL de todas as solicitações em um ouvinte ou apenas aquelas solicitações que correspondem a uma ou mais das condições definidas. Essas condições são baseadas nas propriedades de solicitação (cabeçalho da solicitação e variáveis do servidor).

  • Escolher rotear a solicitação (selecione o pool de back-end) com base na URL original ou na URL reescrita

Para saber como reescrever a URL com o Gateway de Aplicativo usando o portal do Azure, consulte aqui.

Diagram that describes the process for rewriting a URL with Application Gateway.

Ações de reescrita

Você usa ações de reescrita para especificar a URL, cabeçalhos de solicitação ou cabeçalhos de resposta que deseja reescrever e o novo valor para o qual pretende reescrevê-los. O valor de uma URL ou de um cabeçalho novo ou existente pode ser definido para estes tipos de valores:

  • Texto
  • Cabeçalho da solicitação. Para especificar um cabeçalho de solicitação, você precisa usar a sintaxe {http_req_headerName}
  • Cabeçalho de resposta. Para especificar um cabeçalho de resposta, você precisa usar a sintaxe {http_resp_headerName}
  • Variável de servidor. Para especificar uma variável de servidor, você precisa usar a sintaxe {var_serverVariable}. Consulte a lista de variáveis de servidor compatíveis
  • Uma combinação de texto, um cabeçalho de solicitação, um cabeçalho de resposta e uma variável de servidor.

Condições de reescrita

Você pode usar condições de reescrita, uma configuração opcional, para avaliar o conteúdo de solicitações e respostas HTTP(S) e realizar uma reescrita somente quando uma ou mais condições forem atendidas. O gateway de aplicativo usa esses tipos de variáveis para avaliar o conteúdo de solicitações e respostas:

  • Cabeçalhos HTTP na solicitação
  • Cabeçalhos HTTP na resposta
  • Variáveis de servidor do Gateway de Aplicativo

Você pode usar uma condição para avaliar se uma variável especificada está presente, se uma variável especificada corresponde a um valor específico ou se uma variável especificada corresponde a um padrão específico.

Correspondência padrão

O Gateway de Aplicativo usa expressões regulares para correspondência de padrões na condição. Você deve usar expressões compatíveis com RE2 (Expressão Regular 2) ao escrever suas condições. Se você estiver executando um WAF (Firewall de Aplicativo Web) do Gateway de Aplicativo com o Conjunto de Regras Principais 3.1 ou anterior, poderá encontrar problemas ao usar Expressões Regulares Compatíveis com Perl (PCRE) ao fazer declarações lookahead e lookbehind (negativas ou positivas).

Capturando

Para capturar uma subcadeia de caracteres para uso posterior, coloque parênteses em volta do subpadrão correspondente na definição de regex da condição. O primeiro par de parênteses armazena sua subcadeia de caracteres em 1, o segundo par em 2 e assim por diante. Você pode usar quantos parênteses desejar; o Perl continua definindo mais variáveis ​​numeradas para você representar essas cadeias de caracteres capturadas. Alguns exemplos de ref:

  • /(\d)(\d)/ # Corresponder dois dígitos, capturando-os nos grupos 1 e 2

  • /(\d+)/ # Corresponder um ou mais dígitos, capturando todos eles no grupo 1

  • /(\d+)/ # Corresponder um dígito uma ou mais vezes, capturando o último no grupo 1

Observação

Uso de / para prefixo e sufixo o padrão não deve ser especificado no padrão para corresponder ao valor. Por exemplo, (\d) (\d) corresponderá a dois dígitos. /(\d) (\d)/ não corresponderá a dois dígitos.

Depois de capturados, você pode referenciá-los no conjunto de ações usando o seguinte formato:

  • Para uma captura de cabeçalho de solicitação, você deve usar {http_req_headerName_groupNumber}. Por exemplo, {http_req_User-Agent_1} ou {http_req_User-Agent_2}
  • Para uma captura de cabeçalho de resposta, você deve usar {http_resp_headerName_groupNumber}. Por exemplo, {http_resp_Location_1} ou {http_resp_Location_2}
  • Para uma variável de servidor, você deve usar {var_serverVariableName_groupNumber}. Por exemplo, {var_uri_path_1} ou {var_uri_path_2}

Observação

O caso da variável de condição precisa corresponder ao caso da variável de captura. Por exemplo, se a variável de condição for User-Agent, a variável de captura precisará ser para User-Agent (ou seja, {http_req_User-Agent_2}). Se a variável de condição for user-agent, a variável de captura precisará ser para user-agent (ou seja, {http_req_user-agent_2}).

Se você quiser usar o valor inteiro, não deverá mencionar o número. Basta usar o formato {http_req_headerName} etc. sem o groupNumber.

Variáveis de servidor

O Gateway de Aplicativo usa variáveis de servidor para armazenar informações úteis sobre o servidor, a conexão com o cliente e a solicitação atual na conexão. Exemplos de informações armazenadas incluem o endereço IP do cliente e o tipo de navegador da Web. As variáveis de servidor são alteradas dinamicamente, por exemplo, quando uma nova página é carregada ou quando um formulário é postado. Você pode usar essas variáveis para avaliar as condições de reescrita e reescrever cabeçalhos. Para usar o valor de variáveis de servidor para reescrever cabeçalhos, você precisará especificar essas variáveis na sintaxe {var_serverVariableName}

O Gateway de Aplicativo dá suporte às seguintes variáveis de servidor:

Nome da variável Descrição
add_x_forwarded_for_proxy O campo de cabeçalho de solicitação de cliente X-Forwarded-For com a variável client_ip (consulte a explicação mais adiante nesta tabela) anexada a ele no formato IP1, IP2, IP3 e assim por diante. Se o campo X-Forwarded-For não estiver no cabeçalho de solicitação do cliente, a variável add_x_forwarded_for_proxy será igual à variável $client_ip. Essa variável é particularmente útil quando você deseja reescrever o cabeçalho X-Forwarded-For definido pelo Gateway de Aplicativo para que o cabeçalho contenha apenas o endereço IP sem as informações da porta.
ciphers_supported Uma lista das criptografias que têm suporte do cliente.
ciphers_used A cadeia de caracteres de criptografias usadas para uma conexão TLS estabelecida.
client_ip O endereço IP do cliente a partir do qual o gateway de aplicativo recebeu a solicitação. Se houver um proxy reverso antes do gateway de aplicativo e do cliente de origem, client_ip retornará o endereço IP do proxy reverso.
client_port A porta do cliente.
client_tcp_rtt Informações sobre a conexão TCP do cliente. Disponível em sistemas que suportam a opção de soquete TCP_INFO.
client_user Quando a autenticação HTTP é usada, o nome de usuário fornecido para autenticação.
host Nesta ordem de precedência: o nome do host na linha de solicitação, o nome do host no campo de cabeçalho de solicitação de Host ou o nome do servidor que corresponde a uma solicitação. Exemplo: na solicitação http://contoso.com:8080/article.aspx?id=123&title=fabrikam, o valor do host será contoso.com
cookie_name O cookie name.
http_method O método usado para fazer a solicitação de URL. Por exemplo, GET ou POST.
http_status O status da sessão. Por exemplo, 200, 400 ou 403.
http_version O protocolo de solicitação. Geralmente, HTTP/1.0, HTTP/1.1 ou HTTP/2.0.
query_string A lista de pares variável/valor que seguem o "?" na URL solicitada. Exemplo: na solicitação http://contoso.com:8080/article.aspx?id=123&title=fabrikam, o valor de query_string será id=123&title=fabrikam
received_bytes O comprimento da solicitação (incluindo a linha da solicitação, o cabeçalho e o corpo da solicitação).
request_query Os argumentos na linha da solicitação.
request_scheme O esquema de solicitação: http ou https.
request_uri A URI da solicitação original completa (com argumentos). Exemplo: na solicitação http://contoso.com:8080/article.aspx?id=123&title=fabrikam*, o valor de request_uri será /article.aspx?id=123&title=fabrikam
sent_bytes O número de bytes enviados a um cliente.
server_port A porta do servidor que aceitou uma solicitação.
ssl_connection_protocol O protocolo de uma conexão TLS estabelecida.
ssl_enabled "Ativado" se a conexão opera no modo TLS. Caso contrário, uma cadeia de caracteres vazia.
uri_path Identifica o recurso específico no host que o cliente Web deseja acessar. Essa é a parte da URI de solicitação sem os argumentos. Exemplo: na solicitação http://contoso.com:8080/article.aspx?id=123&title=fabrikam, o valor de uri_path será /article.aspx

Variáveis do servidor de autenticação mútua

O Gateway de Aplicativo dá suporte às seguintes variáveis de servidor para cenários de autenticação mútua. Use essas variáveis de servidor da mesma maneira que acima com as outras variáveis de servidor.

Nome da variável Descrição
client_certificate O certificado do cliente em formato PEM para uma conexão SSL estabelecida.
client_certificate_end_date A data de término do certificado do cliente.
client_certificate_fingerprint A impressão digital SHA1 do certificado do cliente para uma conexão SSL estabelecida.
client_certificate_issuer A cadeia de caracteres "DN do emissor" do certificado do cliente para uma conexão SSL estabelecida.
client_certificate_serial O número de série do certificado do cliente para uma conexão SSL estabelecida.
client_certificate_start_date A data de início do certificado do cliente.
client_certificate_subject A cadeia de caracteres "DN da entidade" do certificado do cliente para uma conexão SSL estabelecida.
client_certificate_verification O resultado da verificação do certificado do cliente: ÊXITO, FALHA:<reason> ou NENHUM se um certificado não estiver presente.

Configuração da reescrita

Para configurar uma regra de reescrita, você precisa criar um conjunto de regras de reescrita e adicionar a configuração da regra de reescrita nele.

Um conjunto de regras de reescrita contém:

  • Associação da regra de roteamento da solicitação: A configuração da reescrita está associada ao ouvinte de origem por meio da regra de roteamento. Quando você usa uma regra de roteamento básica, a configuração de reescrita é associada a um ouvinte de origem e é uma reescrita de cabeçalho global. Quando você usa uma regra de roteamento com base em caminho, a configuração de reescrita é definida no mapa de caminho da URL. Nesse caso, ela se aplica somente à área de caminho específico de um site. Você pode criar vários conjuntos de reescrita e aplicar cada conjunto de reescrita a vários ouvintes. Mas você pode aplicar apenas um conjunto de reescrita a um ouvinte específico.

  • Condição de reescrita: é uma configuração opcional. As condições de reescrita avaliam o conteúdo das solicitações e respostas HTTP(S). A ação de reescrita ocorrerá se a solicitação ou resposta HTTP(S) corresponder à condição de reescrita. Se você associar mais de uma condição a uma ação, a ação ocorrerá somente quando todas as condições forem atendidas. Em outras palavras, a operação é uma operação AND lógica.

  • Tipo de reescrita: há 3 tipos de reescritas disponíveis:

    • Reescrita de cabeçalhos de solicitação
    • Reescrita de cabeçalhos de resposta
    • Reescrita de componentes de URL
      • Caminho da URL: o valor para o qual o caminho deve ser reescrito.
      • Cadeia de caracteres de consulta de URL: o valor para o qual a cadeia de caracteres de consulta deve ser reescrita.
      • Reavaliar o mapa do caminho: usado para determinar se o mapa do caminho da URL deve ser reavaliado ou não. Se mantido desmarcado, o caminho da URL original será usado para corresponder ao padrão do caminho no mapa do caminho da URL. Se definido como true, o mapa do caminho da URL será reavaliado para verificar a correspondência com o caminho reescrito. Habilitar essa opção ajuda a rotear a solicitação para um pool de back-end diferente após a reescrita.

Reescrever as armadilhas comuns da configuração

  • Habilitar 'Reavaliar o mapa do caminho' não é permitido para regras básicas de roteamento de solicitação. Isso evita um loop infinito de avaliação para uma regra básica de roteamento.

  • Deve haver, pelo menos, uma regra de reescrita condicional ou uma regra de reescrita que não tenha 'Reavaliar mapa do caminho' habilitado para as regras de roteamento baseadas em caminho a fim de evitar um loop infinito de avaliação para uma regra de roteamento baseada em caminho.

  • As solicitações de entrada seriam encerradas com um código de erro 500 caso um loop fosse criado dinamicamente com base nas entradas do cliente. O Gateway de Aplicativo continuará a atender outras solicitações sem qualquer degradação nesse cenário.

Usando a reescrita de URL ou a reescrita de cabeçalho de host com o Firewall do Aplicativo Web (WAF_v2 SKU)

Quando você configurar a reescrita de URL ou a reescrita do cabeçalho de host, a avaliação do WAF acontecerá após a modificação do cabeçalho da solicitação ou dos parâmetros da URL (pós-reescrita). E quando você remover a configuração da reescrita de URL ou da reescrita do cabeçalho de host no seu Gateway de Aplicativo, a avaliação do WAF será feita antes da reescrita do cabeçalho (pré-reescrita). Essa ordem garante que as regras do WAF sejam aplicadas à solicitação final que seria recebida pelo seu pool de back-end.

Por exemplo, digamos que você tenha a seguinte regra de reescrita de cabeçalho para o cabeçalho "Accept" : "text/html" - se o valor do cabeçalho "Accept" for igual a "text/html", reescreva o valor para "image/png".

Aqui, com apenas a reescrita de cabeçalho configurada, a avaliação do WAF será feita em "Accept" : "text/html". Mas quando você configurar a reescrita de URL ou a reescrita do cabeçalho de host, a avaliação do WAF será feita em "Accept" : "image/png".

Cenários comuns de reescrita de cabeçalho

Remover informações da porta do cabeçalho X-Forwarded-For

O Gateway de Aplicativo insere um cabeçalho X-Forwarded-For em todas as solicitações antes de encaminhar as solicitações ao back-end. Esse cabeçalho é uma lista separada por vírgulas de portas IP. Pode haver cenários nos quais os servidores back-end só precisam que os cabeçalhos contenham endereços IP. Você pode usar a reescrita de cabeçalho para remover informações da porta do cabeçalho X-Forwarded-For. Uma maneira de fazer isso é definir o cabeçalho para a variável de servidor add_x_forwarded_for_proxy. Como alternativa, você também pode usar a variável client_ip:

Remove port

Modificar uma URL de redirecionamento

A modificação de uma URL de redirecionamento pode ser útil em determinadas circunstâncias. Por exemplo: os clientes foram originalmente redirecionados para um caminho como "/blog", mas agora devem ser enviados para "/updates" devido a uma alteração na estrutura de conteúdo.

Aviso

Às vezes, a necessidade de modificar uma URL de redirecionamento é exibida no contexto de uma configuração na qual o Gateway de Aplicativo está configurado para substituir o nome do host em direção ao back-end. O nome do host como visto pelo back-end é nesse caso diferente do nome do host, como visto pelo navegador. Nessa situação, o redirecionamento não usará o nome de host correto. Esta configuração não é recomendada.

As limitações e as implicações dessa configuração são descritas em Preservar o nome do host HTTP original entre um proxy reverso e o aplicativo Web de back-end. A configuração recomendada para Serviço de Aplicativo é seguir as instruções para "Custom Domain (recomendado)" em Configurar Serviço de Aplicativo com Gateway de Aplicativo. A reescrita do cabeçalho de local na resposta, conforme descrito no exemplo abaixo, deve ser considerada uma solução alternativa e não resolve a causa raiz.

Quando o serviço de aplicativo envia uma resposta de redirecionamento, ele usa o mesmo nome de host no cabeçalho do local da sua resposta e na solicitação que recebe do gateway de aplicativo. Portanto, o cliente fará a solicitação diretamente para contoso.azurewebsites.net/path2 em vez de passar pelo gateway de aplicativo (contoso.com/path2). Ignorar o gateway de aplicativo não é desejável.

Você pode resolver esse problema definindo o nome do host no cabeçalho do local como o nome de domínio do gateway de aplicativo.

Veja aqui as etapas para substituir o nome do host:

  1. Crie uma regra de reescrita com uma condição que avalie se o cabeçalho do local na resposta contém azurewebsites.net. Insira o padrão (https?):\/\/.*azurewebsites\.net(.*)$.
  2. Execute uma ação para reescrever o cabeçalho do local para que ele tenha o nome do host do gateway de aplicativo. Faça isso inserindo {http_resp_Location_1}://contoso.com{http_resp_Location_2} como o valor do cabeçalho. Como alternativa, você também pode usar a variável de servidor host para definir o nome do host para corresponder à solicitação original.

Modify location header

Implementar cabeçalhos HTTP de segurança para evitar vulnerabilidades

Você pode corrigir várias vulnerabilidades de segurança implementando os cabeçalhos necessários na resposta do aplicativo. Esses cabeçalhos de segurança incluem X-XSS-Protection, Strict-Transport-Security e Content-Security-Policy. Você pode usar o Gateway de Aplicativo para definir esses cabeçalhos para todas as respostas.

Security header

Excluir cabeçalhos indesejados

Talvez você queira remover os cabeçalhos que revelam informações confidenciais de uma resposta HTTP. Por exemplo, o ideal é remover informações como o nome do servidor back-end, o sistema operacional ou os detalhes da biblioteca. Você pode usar o gateway de aplicativo para remover estes cabeçalhos:

Deleting header

Verificar a presença de um cabeçalho

Você pode avaliar um cabeçalho de solicitação ou de resposta HTTP quanto à presença de um cabeçalho ou variável de servidor. Essa avaliação é útil quando você deseja executar uma reescrita de cabeçalho somente quando um determinado cabeçalho está presente.

Checking presence of a header

Cenários comuns de reescrita de URL

Seleção de caminho baseado em parâmetro

Para realizar cenários em que você deseja escolher o pool de back-end com base no valor de um cabeçalho, parte da URL ou cadeia de caracteres de consulta na solicitação, você pode usar a combinação de capacidade de Reescrita de URL e roteamento baseado em caminho. Por exemplo, se você tiver um site de compras, a categoria do produto for passada como uma cadeia de caracteres de consulta na URL e você quiser rotear a solicitação para o back-end com base na cadeia de caracteres de consulta:

Etapa 1: Crie um mapa de caminho conforme mostrado na imagem abaixo

URL rewrite scenario 1-1.

Etapa 2 (a): Crie um conjunto de reescrita que tenha 3 regras de reescrita:

  • A primeira regra tem uma condição que verifica a variável query_string para categoria=sapatos e tem uma ação que reescreve o caminho da URL para /listing1 e tem a opção Reavaliar o mapa de caminho habilitada

  • A segunda regra tem uma condição que verifica a variável query_string para categoria=bags e tem uma ação que reescreve o caminho da URL para /listing2 e tem a opção Reavaliar o mapa de caminho habilitada

  • A terceira regra tem uma condição que verifica a variável query_string para categoria=acessórios e tem uma ação que reescreve o caminho da URL para /listing3 e tem a opção Reavaliar o mapa de caminho habilitada

URL rewrite scenario 1-2.

Etapa 2 (b): Associar esse conjunto de reescrita ao caminho padrão da regra com base no caminho acima

URL rewrite scenario 1-3.

Agora, se o usuário solicitar contoso.com/listing?category=any, ele será correspondido com o caminho padrão, já que nenhum dos padrões de caminho no mapa de caminho (/listing1, /listing2, /listing3) corresponderá. Como você associou o conjunto de reescrita acima a esse caminho, esse conjunto de reescrita será avaliado. Como a cadeia de consulta não corresponderá à condição em nenhuma das três regras de reescrita nesse conjunto de reescrita, nenhuma ação de reescrita ocorrerá e, portanto, a solicitação será encaminhada inalterada para o back-end associado ao caminho padrão (que é GenericList).

Se o usuário solicitar contoso.com/listing?category=shoes, o caminho padrão será correspondido novamente. No entanto, nesse caso, a condição na primeira regra será correspondida e, portanto, a ação associada à condição será executada, o que reescreverá o caminho da URL para /listing1 e reavaliará o mapa do caminho. Quando o mapa do caminho for reavaliado, a solicitação agora corresponderá ao caminho associado ao padrão /listing1 e a solicitação será direcionada para o back-end associado a esse padrão, que é ShoesListBackendPool.

Observação

Esse cenário pode ser estendido para qualquer cabeçalho ou valor de cookie, caminho de URL, cadeia de caracteres de consulta ou variáveis de servidor com base nas condições definidas e, essencialmente, permite que você roteie solicitações com base nessas condições.

Reescrever parâmetros de cadeia de caracteres de consulta com base na URL

Considere um cenário de um site de compras no qual o link visível ao usuário deve ser simples e legível, mas o servidor back-end precisa dos parâmetros da cadeia de caracteres de consulta para mostrar o conteúdo correto.

Nesse caso, o Gateway de Aplicativo pode capturar parâmetros da URL e adicionar pares chave-valor de cadeia de caracteres de consulta a partir daqueles da URL. Por exemplo, digamos que o usuário deseja reescrever, https://www.contoso.com/fashion/shirts para https://www.contoso.com/buy.aspx?category=fashion&product=shirts. Isso pode ser feito por meio da configuração de reescrita de URL a seguir.

Condição - Se a variável de servidor uri_path for igual ao padrão /(.+)/(.+)

URL rewrite scenario 2-1.

Ação - Defina o caminho da URL para buy.aspx e a cadeia de caracteres de consulta para category={var_uri_path_1}&product={var_uri_path_2}

URL rewrite scenario 2-2.

Para obter um guia passo a passo para obter o cenário descrito acima, consulte Reescrever URL com o Gateway de Aplicativo usando o portal do Azure

Reescrita de URL versus Redirecionamento de URL

No caso da reescrita de URL, o Gateway de Aplicativo reescreve a URL antes que a solicitação seja enviada ao back-end. Isso não vai alterar o que os usuários veem no navegador, pois as alterações ficam ocultas do usuário.

No caso do redirecionamento de URL, o Gateway de Aplicativo envia uma resposta de redirecionamento ao cliente com a nova URL. Isso, por sua vez, exige que o cliente reenvie sua solicitação para a nova URL fornecida no redirecionamento. A URL que o usuário vê no navegador será atualizada para a nova URL.

Rewrite vs Redirect.

Limitações

  • Se uma resposta tiver mais de um cabeçalho com o mesmo nome, reescrever o valor de um desses cabeçalhos resultará no descarte dos outros cabeçalhos na resposta. Em geral, isso pode acontecer com o cabeçalho Set-Cookie, pois você pode ter mais de um cabeçalho Set-Cookie em uma resposta. Um cenário desse tipo é quando você está usando um serviço de aplicativo com um gateway de aplicativo e configurou a afinidade de sessão baseada em cookie no gateway de aplicativo. Nesse caso, a resposta conterá dois cabeçalhos Set-Cookie: um usado pelo serviço de aplicativo, por exemplo Set-Cookie: ARRAffinity=ba127f1caf6ac822b2347cc18bba0364d699ca1ad44d20e0ec01ea80cda2a735;Path=/;HttpOnly;Domain=sitename.azurewebsites.net, e outro para afinidade de gateway de aplicativo, por exemplo, Set-Cookie: ApplicationGatewayAffinity=c1a2bd51lfd396387f96bl9cc3d2c516; Path=/. Reescrever um dos cabeçalhos Set-Cookie nesse cenário pode resultar na remoção do outro cabeçalho Set-Cookie da resposta.
  • Não há suporte para reescritas quando o gateway de aplicativo está configurado para redirecionar as solicitações ou para mostrar uma página de erro personalizada.
  • Os nomes de cabeçalho de solicitação podem conter caracteres alfanuméricos e hifens. Os nomes de cabeçalhos que contiverem outros caracteres serão descartados quando uma solicitação for enviada para o destino de back-end.
  • Os nomes de cabeçalhos podem conter qualquer caractere alfanumérico e símbolos específicos, conforme definido no RFC 7230.
  • Os cabeçalhos de conexão e atualização não podem ser reescritos
  • Não há suporte para reescritas em respostas 4xx e 5xx geradas diretamente do Gateway de Aplicativo

Próximas etapas