Reescrever cabeçalhos HTTP e URL com o Gateway de Aplicativo
O Gateway de Aplicativo permite que você reescreva o conteúdo selecionado de solicitações e respostas. Com esse recurso, você pode traduzir URLs, parâmetros de cadeia de caracteres de consulta e 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.
Os recursos de reescrita de cabeçalho HTTP e de URL estão disponíveis somente para o SKU do Gateway de Aplicativo v2.
Cabeçalhos de solicitação e resposta
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. 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.
Você pode reescrever todos os cabeçalhos em solicitações e respostas, exceto para os cabeçalhos Connection e Upgrade. 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. Para saber como reescrever cabeçalhos de solicitação e de resposta com o Gateway de Aplicativo usando o portal do Azure, consulte aqui.
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 que você definir. 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.
Noções básicas sobre reescritas no Gateway de Aplicativo
Um conjunto de reescrita é uma coleção de regra de roteamento, condição e ação.
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 do tipo Básico, a configuração de reescrita é associada ao ouvinte e funciona como uma reescrita global. Quando você usa uma regra de roteamento com base em caminho, a configuração de reescrita é definida de acordo com o mapa de caminho da URL. Nesse caso, ela se aplica somente à área de caminho específico de um site. Você pode aplicar um conjunto de reescrita a várias regras de roteamento, mas uma regra de roteamento pode ter apenas uma regra de reescrita associada a ela.
Condição de reescrita: é uma configuração opcional. Com base nas condições definidas, o Gateway de Aplicativo avaliará o conteúdo das solicitações e respostas HTTP(S). A "ação de reescrita" subsequente ocorrerá se a solicitação ou resposta HTTP(S) corresponder a essa condiçã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, é uma operação AND lógica. Você pode usar condições de reescrita para avaliar o conteúdo de solicitações e respostas HTTP(S). Essa configuração opcional permite que você execute uma reescrita apenas 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:
Você pode escolher os seguintes tipos para procurar uma condição:
- Cabeçalho HTTP (Solicitação e Resposta)
- Variáveis de servidor compatíveis
Uma Condição permite que você avalie se existe uma variável ou cabeçalho especificado, correspondendo os valores deles por meio de texto ou um padrão Regex. Para configurações avançadas de reescrita, você também pode capturar o valor de cabeçalho ou variável de servidor para uso posterior em Ação de Reescrita. Saiba mais sobre padrão e captura.
Ação de Reescrita: o conjunto de ações de reescrita permite que você reescreva Cabeçalhos (Solicitação ou Resposta) ou os componentes da URL.
Uma ação pode ter os seguintes tipos de valor ou combinações deles:
- Text.
- Valor do cabeçalho de solicitação – para usar um valor de cabeçalho de solicitação capturado, especifique a sintaxe como
{http_req_headerName}. - Valor do cabeçalho de resposta – para usar um valor de cabeçalho de resposta capturado da Condição anterior, especifique a sintaxe como
{http_resp_headerName}. Você pode usar{capt_header_value_matcher}quando o valor é capturado do cabeçalho de resposta "Set-Cookie" do Conjunto de Ações. Saiba mais sobre a captura em Conjunto de ações. - Variável de servidor – Para usar uma variável de servidor, especifique a sintaxe como
{var_serverVariable}. Lista de variáveis de servidor compatíveis.
Ao usar uma Ação para reescrever uma URL, há suporte para as seguintes operações:
- Caminho da URL: o novo valor a ser definido como o caminho.
- Cadeia de caracteres de consulta da URL: o valor para o qual a cadeia de caracteres de consulta precisa ser reescrita.
- Reavaliar o mapa do caminho: especifique se o mapa do caminho da URL precisa ser reavaliado após a reescrita. 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 verdadeiro, 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.
Captura e padrões correspondentes
Há suporte para correspondência e captura de padrão em Condição e Ação (em Ação, ele tem suporte apenas para um cabeçalho específico).
Correspondência de padrões
O Gateway de Aplicativo usa expressões regulares para padrões correspondentes na condição. Você deve usar expressões compatíveis com RE2 (Expressão Regular 2) ao escrever sua sintaxe de padrões correspondentes.
Você pode usar padrões correspondentes em Condição e também em Ação.
- Condição: isso é usado para corresponder aos valores de um cabeçalho ou variável de servidor. Para corresponder a um padrão em "Conditions", use a propriedade "pattern".
- Ação: os padrões correspondentes em Conjunto de Ações só está disponível para o cabeçalho de resposta "Set-Cookie". Para corresponder a um padrão para Set-Cookie em uma ação, use a propriedade "HeaderValueMatcher". Se capturado, seu valor pode ser usado como {capt_header_value_matcher}. Como pode haver vários Set-Cookie, uma correspondência de padrões aqui permite que você procure um cookie específico. Exemplo: para uma determinada versão do usuário-agente, você deseja reescrever o cabeçalho de resposta set-cookie para "cookie2" com max-age=3600 (uma hora). Nesse caso, você pode usar
- Condição – Tipo: Cabeçalho da solicitação, Nome do cabeçalho: user-agent, Padrão para corresponder: *2.0
- Ação – Tipo de reescrita: Cabeçalho de resposta, Tipo de ação: Set, Nome do cabeçalho: Set-Cookie, Correspondente de Valor de Cabeçalho: cookie2={capt_header_value_matcher_1}; Max-Age=3600
Observação
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).
Sintaxe para captura
Os padrões também podem ser usados para capturar uma sub-cadeia de caracteres para uso posterior. Coloque parênteses em torno de um sub-padrão na definição regex. 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. Você pode encontrar alguns exemplos nestas diretrizes de programação em Perl.
- /(\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
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_Local_1} ou {http_resp_Local_2}. Enquanto para um cabeçalho de resposta Set-Cookie capturado por meio da propriedade "HeaderValueMatcher", você precisa usar {capt_header_value_matcher_groupNumber}. Por exemplo, {capt_header_value_matcher_1} ou {capt_header_value_matcher_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
- 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.
- 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 reescrever cabeçalhos usando variáveis de servidor, especifique 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 é útil para reescrever o cabeçalho X-Forwarded-For definido pelo Gateway de Aplicativo para que o cabeçalho contenha apenas o endereço IP, sem informações de 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 de host é 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 é 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 é /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. A variável refere-se ao caminho do URL original, antes de qualquer manipulação. Essa é a parte da URI de solicitação sem os argumentos. Por exemplo, na solicitação http://contoso.com:8080/article.aspx?id=123&title=fabrikam, o valor uri_path é /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. |
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:
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:
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(.*)$.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 servidorhostpara definir o nome do host para corresponder à solicitação original.
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.
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:
Não é possível criar uma regra de reescrita para excluir o cabeçalho de host. Se você tentar criar uma regra de reescrita com o tipo de ação definido como "excluir" e o cabeçalho definido como "host", isso resultará em um erro.
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.
Cenários comuns de reescrita de URL
Seleção de caminho baseado em parâmetro
Para obter cenários em que você escolhe 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 uma combinação de capacidade de reescrita de URL e roteamento baseado em caminho.
Para fazer isso, crie um conjunto de reescrita com uma condição que verifica um parâmetro específico (cadeia de caracteres de consulta, cabeçalho etc.) e, em seguida, execute uma ação em que isso altera o caminho da URL (verifique se Reavaliar o mapa do caminho está habilitado). Em seguida, o conjunto de reescrita deve ser associado a uma regra baseada em caminho. A regra baseada em caminho deve conter os mesmos caminhos de URL especificados no conjunto de reescrita e no pool de back-end correspondente.
Assim, o conjunto de reescrita permite que os usuários verifiquem um parâmetro específico e atribuam a ele um novo caminho, e a regra baseada em caminho permite que os usuários atribuam pools de back-end a esses caminhos. Se "Reavaliar o mapa do caminho" estiver habilitado, o tráfego será roteado com base no caminho especificado no conjunto de reescrita.
Para obter um exemplo de caso de uso usando cadeias de caracteres de consulta, consulte Rotear o tráfego usando a seleção de caminho baseado em parâmetro no portal.
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 /(.+)/(.+)
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}
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
Reescrever as armadilhas comuns da configuração
Não é permitido habilitar a opção "Reavaliar o mapa do caminho" para as regras básicas de roteamento de solicitações. 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 sem a opção "Reavaliar mapa do caminho" habilitada para as regras de roteamento baseadas em caminho. Isso evita 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 degradações 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, o WAF avaliará a solicitação 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 do cabeçalho de host no seu Gateway de Aplicativo, o WAF fará a avaliação 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, o WAF fará a avaliação em "Accept" : "text/html". Mas quando você configurar a reescrita de URL ou a reescrita do cabeçalho de host, o WAF fará a avaliação em "Accept" : "image/png".
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.
Limitações
- 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