Reescrever cabeçalhos HTTP e URL com o Application Gateway

  • Artigo

O Application Gateway permite reescrever o conteúdo selecionado de solicitações e respostas. Com esse recurso, você pode traduzir URLs, parâmetros de cadeia de caracteres de consulta, bem como modificar cabeçalhos de solicitação e resposta. Ele também permite que você adicione condições para garantir que a URL ou os cabeçalhos especificados sejam reescritos somente quando determinadas condições forem atendidas. Estas condições baseiam-se nas informações do pedido e da resposta.

Nota

Os recursos de reconfiguração de cabeçalho HTTP e URL só estão disponíveis para o SKU do Application Gateway v2

Tipos de reescrita suportados

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 Application Gateway permite adicionar, remover ou atualizar cabeçalhos de solicitação e resposta HTTP enquanto os pacotes de solicitação e resposta se movem entre os pools de cliente e back-end.

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

img

Cabeçalhos suportados

Você pode reescrever todos os cabeçalhos em solicitações e respostas, exceto 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 meio dele.

Caminho da URL e cadeia de caracteres de consulta

Com o recurso de regravação de URL no Application Gateway, você pode:

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

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

  • Escolha 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

Use ações de regravação 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}
  • O cabeçalho da 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 suportadas
  • 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 executar uma regravação 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 do servidor do Application Gateway

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 de padrões

O Application Gateway usa expressões regulares para correspondência de padrões na condição. Você deve usar expressões compatíveis com Expressão Regular 2 (RE2) ao escrever suas condições. Se você estiver executando um Application Gateway Web Application Firewall (WAF) com o Core Rule set 3.1 ou anterior, poderá ter problemas ao usar expressões regulares compatíveis com Perl (PCRE) ao fazer asserções lookahead e lookbehind (negativas ou positivas).

Captura

Para capturar uma substring para uso posterior, coloque parênteses ao redor do subpadrão que corresponde a ela na definição de regex de condição. O primeiro par de parênteses armazena sua substring em 1, o segundo par em 2 e assim por diante. Você pode usar quantos parênteses quiser; Perl apenas 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-os todos no grupo 1

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

Nota

O uso do / prefixo e sufixo do 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 corresponde a dois dígitos.

Uma vez capturados, você pode fazer referência a eles 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}

Nota

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

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

Variáveis de servidor

O Application Gateway 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 mudam dinamicamente, por exemplo, quando uma nova página é carregada ou quando um formulário é postado. Você pode usar essas variáveis para avaliar condições de regravação e cabeçalhos de reescrita. Para usar o valor das variáveis de servidor para reescrever cabeçalhos, você precisará especificar essas variáveis na sintaxe {var_serverVariableName}

O gateway de aplicativo suporta as seguintes variáveis de servidor:

Nome da variável Descrição
add_x_forwarded_for_proxy O campo de cabeçalho de solicitação do cliente X-Forwarded-For com a variável (veja a explicação mais adiante nesta tabela) anexada a client_ip ele no formato IP1, IP2, IP3 e assim por diante. Se o campo X-Forwarded-For não estiver no cabeçalho da solicitação do cliente, a add_x_forwarded_for_proxy variável será igual à $client_ip variável. Essa variável é particularmente útil quando você deseja reescrever o cabeçalho X-Forwarded-For definido pelo Application Gateway para que o cabeçalho contenha apenas o endereço IP sem as informações da porta.
ciphers_supported Uma lista das cifras suportadas pelo cliente.
ciphers_used A cadeia de caracteres de cifras usada para uma conexão TLS estabelecida.
client_ip O endereço IP do cliente 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 da linha de solicitação, o nome do host do campo Cabeçalho da solicitação do host ou o nome do servidor correspondente 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_nome O cookie de nome .
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. Normalmente, HTTP/1.0, HTTP/1.1 ou HTTP/2.0.
query_string A lista de pares de variáveis/valores que se segue a "?" no URL solicitado. Exemplo: Na solicitação http://contoso.com:8080/article.aspx?id=123&title=fabrikam, query_string valor 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 de solicitação.
request_scheme O esquema de solicitação: http ou https.
request_uri O URI de solicitação original completo (com argumentos). Exemplo: na solicitação http://contoso.com:8080/article.aspx?id=123&title=fabrikam*, request_uri valor será /article.aspx?id=123&title=fabrikam
sent_bytes O número de bytes enviados para 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 "Ligado" se a conexão operar no modo TLS. Caso contrário, uma cadeia de caracteres vazia.
uri_path Identifica o recurso específico no host que o cliente da Web deseja acessar. Esta é a parte do URI de solicitação sem os argumentos. Exemplo: Na solicitação http://contoso.com:8080/article.aspx?id=123&title=fabrikam, uri_path valor será /article.aspx

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

O Application Gateway oferece 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 no formato PEM para uma conexão SSL estabelecida.
client_certificate_end_date A data final 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 do assunto" do certificado do cliente para uma conexão SSL estabelecida.
client_certificate_verification O resultado da verificação do certificado do cliente: SUCCESS, FAILED:<reason> ou NONE se um certificado não estiver presente.

Reescrever configuração

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 de regra de roteamento de solicitação: a configuração de regravação é associada ao ouvinte de origem por meio da regra de roteamento. Quando você usa uma regra de roteamento básica, a configuração de regravação é associada a um ouvinte de origem e é uma regravação de cabeçalho global. Quando você usa uma regra de roteamento baseada em caminho, a configuração de regravação é definida no mapa de caminho de URL. Nesse caso, aplica-se apenas à área de caminho específica de um site. Você pode criar vários conjuntos de regravação e aplicar cada conjunto de regravação a vários ouvintes. Mas você pode aplicar apenas um conjunto de regravações 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 regravação ocorrerá se a solicitação ou resposta HTTP(S) corresponder à condição de regravação. 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 lógica E.

  • Tipo de reescrita: Existem 3 tipos de regravações disponíveis:

    • Reescrevendo cabeçalhos de solicitação
    • Reescrevendo cabeçalhos de resposta
    • Reescrevendo 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 no qual a cadeia de caracteres de consulta deve ser regravada.
      • Reavaliar mapa de caminho: usado para determinar se o mapa de caminho de URL deve ser reavaliado ou não. Se mantido desmarcado, o caminho da URL original será usado para corresponder ao padrão de caminho no mapa de caminho da URL. Se definido como true, o mapa de 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 regravação.

Reescrever armadilhas comuns de configuração

  • A ativação de 'Reavaliar mapa de caminho' não é permitida para regras básicas de roteamento de solicitações. Isso é para evitar loop de avaliação infinito para uma regra de roteamento básica.

  • Precisa haver pelo menos 1 regra de reescrita condicional ou 1 regra de reescrita que não tenha 'Reavaliar mapa de caminho' habilitado para regras de roteamento baseadas em caminho para evitar loop de avaliação infinito para uma regra de roteamento baseada em caminho.

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

Usando a regravação de URL ou a regravação de cabeçalho de host com o Web Application Firewall (WAF_v2 SKU)

Quando você configura a regravação de URL ou a regravação de 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 de URL (pós-regravação). E quando você remover a regravação de URL ou a configuração de regravação de cabeçalho de host no seu Application Gateway, a avaliação do WAF será feita antes da regravação 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 reconfiguração de cabeçalho para o cabeçalho - se o valor do cabeçalho "Accept" : "text/html""Accept" for igual a "text/html", reescreva o valor em "image/png".

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

Cenários comuns para reescrita de cabeçalho

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

O Application Gateway insere um cabeçalho X-Forwarded-For em todas as solicitações antes de encaminhar as solicitações para o back-end. Este cabeçalho é uma lista separada por vírgulas de portas IP. Pode haver cenários em que os servidores back-end só precisam dos cabeçalhos para conter endereços IP. Você pode usar a regravação de cabeçalho para remover as 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 um URL de redirecionamento

A modificação de um 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 mudança na estrutura do conteúdo.

Aviso

A necessidade de modificar uma URL de redirecionamento às vezes surge no contexto de uma configuração pela qual o Application Gateway é configurado para substituir o nome do host em direção ao back-end. O nome do host visto pelo back-end é, nesse caso, diferente do nome do host visto pelo navegador. Nessa situação, o redirecionamento não usaria o nome de host correto. Esta configuração não é recomendada.

As limitações e implicações de tal configuração são descritas em Preservar o nome de host HTTP original entre um proxy reverso e seu aplicativo Web de back-end. A configuração recomendada para o Serviço de Aplicativo é seguir as instruções para "Domínio Personalizado (recomendado)" em Configurar o Serviço de Aplicativo com o Gateway de Aplicativo. Reescrever o cabeçalho do local na resposta, conforme descrito no exemplo abaixo, deve ser considerado uma solução alternativa e não aborda 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 de sua resposta que o da solicitação que recebe do gateway de aplicativo. Assim, o cliente fará a solicitação diretamente em contoso.azurewebsites.net/path2 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 para o nome de domínio do gateway de aplicativo.

Aqui estão 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 de 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 host de servidor 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 Application Gateway para definir esses cabeçalhos para todas as respostas.

Security header

Excluir cabeçalhos indesejados

Talvez você queira remover cabeçalhos que revelam informações confidenciais de uma resposta HTTP. Por exemplo, talvez você queira 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 esses cabeçalhos:

Deleting header

Verificar a presença de um cabeçalho

Você pode avaliar uma solicitação HTTP ou cabeçalho de resposta para a 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 para reconfiguração de URL

Seleção de caminho baseada em parâmetros

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 recurso de Regravação de URL e roteamento baseado em caminho. Por exemplo, se você tiver um site de compras e a categoria do produto for passada como cadeia de caracteres de consulta na URL e quiser rotear a solicitação para back-end com base na cadeia de caracteres de consulta, então:

Passo 1: Crie um mapa de caminho como mostrado na imagem abaixo

URL rewrite scenario 1-1.

Passo 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 category=shoes e tem uma ação que reescreve o caminho da URL para /listing1 e tem Reavaliar mapa de caminho habilitado

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

  • A terceira regra tem uma condição que verifica a variável query_string para category=accessories e tem uma ação que reescreve o caminho da URL para /listing3 e tem Reavaliar mapa de caminho habilitado

URL rewrite scenario 1-2.

Etapa 2 (b): Associar este conjunto de reescrita ao caminho padrão da regra baseada em 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 regravação será avaliado. Como a cadeia de caracteres de consulta não corresponderá à condição em nenhuma das 3 regras de regravação neste conjunto de regravação, nenhuma ação de regravação ocorrerá e, portanto, a solicitação será roteada inalterada para o back-end associado ao caminho padrão (que é GenericList).

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

Nota

Esse cenário pode ser estendido a qualquer valor de cabeçalho ou cookie, caminho de URL, cadeia de caracteres de consulta ou variáveis de servidor com base nas condições definidas e, essencialmente, permite rotear 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 em que o link visível do usuário deve ser simples e legível, mas o servidor de back-end precisa dos parâmetros da cadeia de caracteres de consulta para mostrar o conteúdo correto.

Nesse caso, o Application Gateway pode capturar parâmetros da URL e adicionar pares chave-valor da cadeia de caracteres de consulta daqueles da URL. Por exemplo, digamos que o usuário queira reescrever, para https://www.contoso.com/buy.aspx?category=fashion&product=shirts, https://www.contoso.com/fashion/shirts isso pode ser alcançado através da seguinte configuração de regravação de URL.

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

URL rewrite scenario 2-1.

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

URL rewrite scenario 2-2.

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

Reescrita de URL vs redirecionamento de URL

Para uma regravação de URL, o Application Gateway regrava a URL antes que a solicitação seja enviada para o back-end. Isso não mudará o que os usuários veem no navegador porque as alterações estão ocultas do usuário.

Para um redirecionamento de URL, o Application Gateway envia uma resposta de redirecionamento para o cliente com a nova URL. Isso, por sua vez, exige que o cliente reenvie sua solicitação para a nova URL fornecida no redirecionamento. O URL que o usuário vê no navegador será atualizado para o novo 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á na eliminação dos outros cabeçalhos na resposta. Isso geralmente pode acontecer com o cabeçalho Set-Cookie, uma vez que você pode ter mais de um cabeçalho Set-Cookie em uma resposta. Um desses cenários é quando você está usando um serviço de aplicativo com um gateway de aplicativo e configurou 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 neste cenário pode resultar na remoção do outro cabeçalho Set-Cookie da resposta.
  • Não há suporte para regravações quando o gateway de aplicativo é configurado para redirecionar as solicitações ou para mostrar uma página de erro personalizada.
  • Os nomes dos cabeçalhos de solicitação podem conter caracteres alfanuméricos e hífenes. Os nomes de cabeçalhos que contenham outros caracteres serão descartados quando uma solicitação for enviada para o destino de back-end.
  • Os nomes dos cabeçalhos de resposta podem conter caracteres alfanuméricos e símbolos específicos, conforme definido na RFC 7230.
  • Os cabeçalhos de conexão e atualização não podem ser reescritos
  • Não há suporte para regravações para respostas 4xx e 5xx geradas diretamente do Application Gateway

Próximos passos