Reescritura de los encabezados HTTP y direcciones URL con Application Gateway

Application Gateway permite volver a escribir el contenido seleccionado de las solicitudes y las respuestas. Con esta característica, puede traducir direcciones URL, consultar parámetros de cadena y modificar encabezados de solicitud y respuesta. También permite agregar las condiciones necesarias para asegurarse de que los encabezados especificados y las direcciones URL se reescriben solo cuando se cumplen ciertas condiciones. Estas condiciones se basan en la información de solicitud y respuesta.

Las características de reescritura de direcciones URL y encabezado HTTP solo están disponibles para la SKU de Application Gateway v2.

Encabezados de respuesta y solicitud

Application Gateway permite agregar, quitar o actualizar los encabezados de solicitud y respuesta HTTP, mientras los paquetes de solicitud y respuesta se mueven entre los grupos back-end y de cliente. Los encabezados HTTP permiten que el cliente y el servidor pasen información adicional con la solicitud o la respuesta. Al reescribir estos encabezados, puede realizar tareas importantes, como agregar campos de encabezado relacionados con la seguridad (como HSTS y X-XSS-Protection), quitar campos de encabezado de respuesta que pueden revelar información confidencial o eliminar información de puertos de los encabezados X-Forwarded-For.

Puede reescribir todos los encabezados en solicitudes y respuestas, excepto los encabezados Connection y Upgrade. También puede usar la puerta de enlace de aplicaciones para crear encabezados personalizados y agregarlos a las solicitudes y respuestas que se enrutan a través de ella. Para obtener información sobre cómo volver a escribir los encabezados de solicitud y respuesta con Application Gateway mediante Azure Portal, consulte aquí.

Ruta de acceso URL y cadena de consulta

Con la funcionalidad de reescritura de direcciones URL en Application Gateway, puede:

• Volver a escribir el nombre de host, la ruta de acceso y la cadena de consulta de la dirección URL de solicitud.

• Elija volver a escribir la dirección URL de todas las solicitudes en un agente de escucha o solo las solicitudes que coincidan con una o varias de las condiciones establecidas. Estas condiciones se basan en las propiedades de solicitud (solicitud, encabezado, y variables de servidor).

• Elija la opción de enrutar la solicitud (seleccione el grupo de back-end) en función de la dirección URL original o la dirección URL reescrita.

Para obtener información sobre cómo reescribir la dirección URL con Application Gateway mediante Azure Portal, consulte aquí.

Reconocimiento de las reescrituras en Application Gateway

Un conjunto de reescritura es una colección de una regla de enrutamiento, condición y acción.

• Asociación de reglas de enrutamiento de solicitudes: La configuración de reescritura está asociada a un agente de escucha de origen a través de su regla de enrutamiento. Cuando se usa una regla de enrutamiento del tipo Básico, la configuración de reescritura está asociada a su cliente de escucha y funciona como reescritura global. Cuando se usa una regla de enrutamiento basada en Rutas de acceso, la configuración de reescritura se define según el mapa de ruta de acceso de la dirección URL. En este último caso, solo se aplica a un área de ruta de acceso específica de un sitio. Puede aplicar un conjunto de reescritura a varias reglas de enrutamiento, pero una regla de enrutamiento solo puede tener una reescritura asociada.

• Condición de reescritura: Esta es una configuración opcional. En función de las condiciones que defina, Application Gateway evaluará el contenido de las solicitudes y respuestas HTTP(S). La siguiente "acción de reescritura" se producirá si la solicitud o respuesta HTTP(S) coincide con esta condición. Si asocia más de una condición con una acción, la acción se produce solo cuando se cumplen todas las condiciones. En otras palabras, es una operación AND. Puede usar condiciones de reescritura para evaluar el contenido de las solicitudes y respuestas HTTP(S). Esta configuración opcional permite realizar una reescritura solo cuando se cumplen una o varias condiciones. La puerta de enlace de aplicaciones utiliza estos tipos de variables para evaluar el contenido de las respuestas y las solicitudes:

  Puede elegir los siguientes tipos para buscar una condición:

  • Encabezado HTTP (solicitud y respuesta)
  • Variables de Servidor admitidas

  Una condición permite evaluar si existe un encabezado o una variable especificados mediante la coincidencia de sus valores mediante texto o un patrón Regex. Para las configuraciones avanzadas de reescritura, también puede capturar el valor de encabezado o variable de servidor para su uso posterior en Acción de reescritura. Obtenga más información sobre el patrón y la captura.

• Acción de reescritura: el conjunto de acciones de reescritura permite reescribir encabezados (solicitud o respuesta) o los componentes de la dirección URL.

  Una acción puede tener los siguientes tipos de valor o sus combinaciones:

  • Texto.
  • Valor del encabezado de solicitud: para usar un valor de encabezado de solicitud capturado, especifique la sintaxis como {http_req_headerName}.
  • Valor del encabezado de respuesta: para usar un valor de encabezado de respuesta capturado de la condición anterior, especifique la sintaxis como {http_resp_headerName}. El bloque Acción de reescritura también admite el campo "Buscador de coincidencias de valor de encabezado" para el encabezado Set-Cookie. Este campo opcional le permite hacer coincidir así como capturar el valor de un encabezado específico cuando existen varios encabezados Set-Cookie con el mismo nombre. Para manipular el valor capturado de esa cookie específica, puede usar {capt_header_value_matcher}. Obtenga más información acerca de la captura en Conjunto de acciones.
  • Variable de servidor: para usar una variable de servidor, especifique la sintaxis como {var_serverVariable}. Lista de variables de servidor admitidas.

Nota:

El uso del campo del buscador de coincidencias de valores de encabezado {capt_header_value_matcher} no se admite actualmente desde el portal. Por tanto, deberá seguir usando un método que no sea del portal para las operaciones PUT, si usa este campo.

Cuando se usa una acción para reescribir una dirección URL, se admiten las siguientes operaciones:

• Ruta de acceso URL: nuevo valor que se va a establecer como ruta de acceso.
• Cadena de consulta URL: nuevo valor al que se debe volver a escribir la cadena de consulta.
• Volver a evaluar la asignación de ruta de acceso: especifique si el mapa de ruta de acceso de dirección URL debe volver a evaluarse después de reescribir. Si se deja desactivado, se usará la ruta de dirección URL original para hacer coincidir el patrón de ruta de acceso en el mapa de ruta de acceso de direcciones URL. Si se establece en true, el mapa de ruta de acceso de direcciones URL se volverá a evaluar para comprobar si coincide con la ruta de acceso reescrita. Si se habilita este modificador, ayuda a enrutar la solicitud a otro grupo de back-end posterior a la reescritura.

Coincidencia y captura de patrones

La coincidencia y captura de patrones se admiten en Condición y acción (en Acción, solo se admite para un encabezado específico).

Detección de patrones

Application Gateway usa expresiones regulares para la coincidencia de patrones. Debe usar expresiones compatibles con la expresión regular 2 (RE2) al escribir la sintaxis de coincidencia de patrones.

Puede usar la coincidencia de patrones en Condición y Acción.

• Condición: se usa para hacer coincidir los valores de una variable de servidor o encabezado. Para que coincida con un patrón en "Condiciones", use la propiedad "patrón".
• Acción: la coincidencia de patrones en Conjunto de acciones solo está disponible para el encabezado de respuesta "Set-Cookie". Para que coincida con un patrón para Set-Cookie en una acción, use la propiedad "HeaderValueMatcher". Si se captura, su valor se puede usar como {capt_header_value_matcher}. Como puede haber varias Set-Cookie, una coincidencia de patrones aquí le permite buscar una cookie específica. Ejemplo: Para una determinada versión del agente de usuario, quiere reescribir el encabezado de respuesta set-cookie para "cookie2" con max-age=3600 (una hora). En este caso, puede usar
  • Condición - Tipo: Encabezado de solicitud, Nombre de encabezado: user-agent, Patrón que debe coincidir: *2.0
  • Acción: Tipo de reescritura: Encabezado de respuesta, Tipo de acción: Set, Nombre del encabezado: Set-Cookie, Header Value Matcher: cookie2=(.*), Valor de encabezado: cookie2={capt_header_value_matcher_1}; Max-Age=3600

Nota:

Si ejecuta un firewall de aplicaciones web (WAF) de Application Gateway con el conjunto de reglas principal 3.1 o versiones anteriores, puede encontrarse con problemas al usar expresiones regulares compatibles con Perl (PCRE) al realizar aserciones lookahead y lookbehind (negativas o positivas).

Sintaxis para capturar

Los patrones también se pueden usar para capturar una subcadenilla para su uso posterior. Coloque paréntesis alrededor de un subproceso en la definición de expresión regular. El primer par de paréntesis almacena su subcadena en 1, el segundo par en 2 y así sucesivamente. Puede usar tantos paréntesis como desee. Perl simplemente mantiene la definición de más variables numeradas para que represente estas cadenas capturadas. Puede encontrar algún ejemplo en esta Guía de programación de Perl.

• (\d)(\d) # Coincide con dos dígitos y los captura en los grupos 1 y 2
• (\d+) # Coincide con uno o varios dígitos, y los captura todos en el grupo 1
• (\d)+ # Coincide con un dígito una o varias veces, y captura el último en el grupo 1

Una vez capturado, puede usarlos en el valor conjunto de acciones con el siguiente formato:

• Para una captura de encabezado de solicitud, debe usar {http_req_headerName_groupNumber}. Por ejemplo, {http_req_User-Agent_1} o {http_req_User-Agent_2}
• Para una captura de encabezado de respuesta, debe usar {http_resp_headerName_groupNumber}. Por ejemplo, {http_resp_Location_1} o {http_resp_Location_2}. Mientras que para un encabezado de respuesta Set-Cookie capturado a través de la propiedad "HeaderValueMatcher", debe usar {capt_header_value_matcher_groupNumber}. Por ejemplo, {capt_header_value_matcher_1} o {capt_header_value_matcher_2}.
• En el caso de una variable de servidor, debe usar {var_serverVariableName_groupNumber}. Por ejemplo, {var_uri_path_1} o {var_uri_path_2}

Nota:

• El uso de / para prefijar y sufijar el patrón no debe especificarse en el valor del patrón de coincidencia. Por ejemplo, (\d)(\d) coincidirá con dos dígitos. /(\d)(\d)/ no coincide con dos dígitos.
• Las mayúsculas y minúsculas de la variable de condición deben coincidir con las mayúsculas y minúsculas de la variable de captura. Por ejemplo, si mi variable de condición es User-Agent, mi variable de captura debe ser para User-Agent (es decir, {http_req_User-Agent_2}). Si mi variable de condición se define como user-agent, mi variable de captura debe ser para user-agent (es decir, {http_req_user-agent_2}).
• Si desea utilizar el valor entero, no debe mencionar el número. Simplemente, use el formato {http_req_headerName}, etc. sin groupNumber.

Variables de servidor

App Gateway usa variables de servidor para almacenar información útil sobre el servidor, la conexión con el cliente y la solicitud actual en la conexión. La dirección IP del cliente y el tipo de explorador web son ejemplos de la información almacenada. Las variables de servidor cambian dinámicamente, por ejemplo, cuando se carga una página nueva o cuando se publica un formulario. Puede usar estas variables para evaluar las condiciones de reescritura y volver a escribir los encabezados. Para usar el valor de las variables de servidor para reescribir encabezados, debe especificar estas variables en la sintaxis {var_serverVariableName}

Application Gateway admite las siguientes variables de servidor:

Nombre de la variable	Descripción
add_x_forwarded_for_proxy	El campo de encabezado de solicitud de cliente X-Forwarded-For con la variable client_ip (consulte la explicación más adelante en esta tabla) anexada a él en el formato IP1, IP2, IP3 y así sucesivamente. Si el campo X-Forwarded-For no se encuentra en el encabezado de solicitud de cliente, la variable add_x_forwarded_for_proxy es igual que la variable $client_ip. Esta variable es útil cuando desea volver a escribir el encabezado X-Forwarded-For establecido por Application Gateway para que el encabezado contenga solo la dirección IP sin la información del puerto.
ciphers_supported	Una lista de cifrados admitidos por el cliente.
ciphers_used	La cadena de cifrados que se usa para una conexión TLS establecida.
client_ip	La dirección IP del cliente desde la que la puerta de enlace de la aplicación recibió la solicitud. Si hay un proxy inverso antes de la puerta de enlace de aplicaciones y el cliente de origen, client_ip devuelve la dirección IP del proxy inverso.
client_port	Puerto del cliente.
client_tcp_rtt	Información sobre la conexión TCP de cliente. Está disponible en los sistemas que admiten la opción de socket TCP_INFO.
client_user	Al usar la autenticación HTTP, el nombre de usuario proporcionado para la autenticación.
host	En este orden de prioridad: nombre de host de la línea de la solicitud, nombre de host del campo de encabezado de la solicitud del “Host” o bien el nombre del servidor que coincida con una solicitud. Ejemplo: En la solicitud http://contoso.com:8080/article.aspx?id=123&title=fabrikam, el valor de host es contoso.com
cookie_name	El cookie de nombre.
http_method	Método usado para realizar la solicitud de URL. Por ejemplo, GET o POST.
http_status	Estado de la sesión. Por ejemplo, 200, 400 o 403.
http_version	Protocolo de solicitud. Normalmente, HTTP/1.0, HTTP/1.1 o HTTP/2.0.
query_string	La lista de pares de variable-valor que aparecen después de “?” en la dirección URL solicitada. Ejemplo: En la solicitud http://contoso.com:8080/article.aspx?id=123&title=fabrikam, el valor de query_string es id=123&title=fabrikam
received_bytes	La longitud de la solicitud (incluida la línea de la solicitud, el encabezado y el cuerpo de la solicitud).
request_query	Los argumentos en la línea de la solicitud.
request_scheme	El esquema de la solicitud: HTTP o HTTPS.
request_uri	El URI original completo de la solicitud (con argumentos). Ejemplo: En la solicitud http://contoso.com:8080/article.aspx?id=123&title=fabrikam*, el valor de request_uri es /article.aspx?id=123&title=fabrikam
sent_bytes	El número de bytes enviados a un cliente.
server_port	El puerto del servidor que ha aceptado una solicitud.
ssl_connection_protocol	El protocolo de una conexión TLS establecida.
ssl_enabled	"On" si la conexión funciona en modo TLS. De lo contrario, una cadena vacía.
uri_path	Identifica el recurso específico en el host al que el cliente web quiere acceder. La variable hace referencia a la ruta de acceso de dirección URL original, antes de cualquier manipulación. Esta es la parte del URI de solicitud sin los argumentos. Por ejemplo, en la solicitud http://contoso.com:8080/article.aspx?id=123&title=fabrikam, el valor de uri_path es /article.aspx.

Variables de servidor de autenticación mutua

Application Gateway admite las siguientes variables de servidor para los escenarios de autenticación mutua. Use estas variables de servidor como se describió anteriormente con las demás variables de servidor.

Nombre de la variable	Descripción
client_certificate	Certificado de cliente, en formato PEM, para una conexión SSL establecida.
client_certificate_end_date	Fecha de finalización del certificado de cliente.
client_certificate_fingerprint	Huella digital SHA1 del certificado de cliente para una conexión SSL establecida.
client_certificate_issuer	Cadena del "nombre distintivo del emisor" del certificado de cliente para una conexión SSL establecida.
client_certificate_serial	Número de serie del certificado de cliente para una conexión SSL establecida.
client_certificate_start_date	Fecha de inicio del certificado de cliente.
client_certificate_subject	Cadena del "nombre distintivo del firmante" del certificado de cliente para una conexión SSL establecida.
client_certificate_verification	Resultado de la comprobación del certificado de cliente: SUCCESS, FAILED:<motivo>, o NONEsi no había un certificado presente.

Escenarios comunes de la reescritura de encabezados

Eliminación de la información del puerto desde el encabezado X-Forwarded-For

Application Gateway inserta un encabezado X-Forwarded-For en todas las solicitudes antes de reenviar las solicitudes al back-end. Este encabezado es una lista de puertos IP separados por comas. Puede haber situaciones en las que los servidores back-end solo necesiten que los encabezados contengan direcciones IP. Puede usar la reescritura de encabezados para quitar la información del puerto desde el encabezado X-Forwarded-For. Una manera de hacerlo es establecer el encabezado en la variable de servidor add_x_forwarded_for_proxy: Como alternativa, también puede usar la variable client_ip:

Modificación de una dirección URL de redirección

La modificación de una dirección URL de redireccionamiento puede ser útil en determinadas circunstancias. Por ejemplo: si los clientes se redirigieron originalmente a una ruta de acceso como "/blog", pero ahora se deben enviar a "/updates" debido a un cambio en la estructura de contenido.

Advertencia

La necesidad de modificar una dirección URL de redireccionamiento aparece a veces en el contexto de una configuración en la que Application Gateway se configura para invalidar el nombre de host hacia el back-end. En ese caso, el nombre de host tal como lo ve el back-end es diferente del nombre de host tal como lo ve el explorador. En esta situación, el redireccionamiento no usaría el nombre de host correcto. Esta configuración no es la recomendada.

Las limitaciones e implicaciones de esta configuración se describen en Conservar el nombre de host HTTP original entre un proxy inverso y su aplicación web back-end. La configuración recomendada para App Service es seguir las instrucciones de Custom Domain (recommended) (Dominio personalizado [recomendado]) en Configurar App Service con Application Gateway. La reescritura del encabezado de ubicación en la respuesta como se describe en el ejemplo siguiente debe considerarse una solución alternativa y no soluciona la causa principal.

Cuando el servicio de aplicaciones envía una respuesta de redireccionamiento, usa el mismo nombre de host en el encabezado de ubicación de su respuesta que el que aparece en la solicitud que recibe de la puerta de enlace de aplicaciones. Por lo tanto, el cliente realiza la solicitud directamente a contoso.azurewebsites.net/path2 en lugar de pasar por la puerta de enlace de aplicaciones (contoso.com/path2). No es conveniente omitir la puerta de enlace de aplicaciones.

Para resolver este problema, puede establecer el nombre de host en el encabezado de ubicación en el nombre de dominio de la puerta de enlace de aplicaciones.

Estos son los pasos para reemplazar el nombre de host:

1. Cree una regla de reescritura con una condición que evalúe si el encabezado de ubicación en la respuesta contiene azurewebsites.net. Escriba el patrón (https?):\/\/.*azurewebsites\.net(.*)$.

2. Realice una acción para volver a escribir el encabezado de ubicación de modo que tenga el nombre de host de la puerta de enlace de aplicaciones. Para ello, escriba {http_resp_Location_1}://contoso.com{http_resp_Location_2} como valor del encabezado. O bien, puede usar la variable de servidor host para establecer el nombre de host de modo que coincida con la solicitud original.

   

Implementación de los encabezados HTTP de seguridad para evitar las vulnerabilidades

Puede corregir varias vulnerabilidades de seguridad si implementa los encabezados necesarios en la respuesta de la aplicación. Estos encabezados de seguridad incluyen X-XSS-Protection Strict-Transport-Security y Content-Security-Policy. Puede usar Application Gateway para establecer estos encabezados para todas las respuestas.

Eliminación de los encabezados no deseados

Es posible que desee quitar los encabezados que revelen información confidencial de una respuesta HTTP. Por ejemplo, es posible que quiera quitar información como el nombre del servidor back-end, el sistema operativo o los detalles de la biblioteca. Puede usar la puerta de enlace de aplicaciones para quitar estos encabezados:

No es posible crear una regla de reescritura para eliminar el encabezado de host. Si intenta crear una regla de reescritura con el tipo de acción establecido en eliminar y el encabezado establecido en host, se producirá un error.

Comprobación de la presencia de un encabezado

Puede evaluar un encabezado de respuesta o de solicitud HTTP para comprobar la presencia de una variable de servidor o encabezado. Esta evaluación es útil cuando desea realizar una reescritura de encabezado solo si está presente un encabezado determinado.

Escenarios comunes de la reescritura de direcciones URL

Selección de ruta basada en parámetros

Para lograr escenarios en los que quiera elegir el grupo de back-end en función del valor de un encabezado, parte de la dirección URL o la cadena de consulta de la solicitud, puede usar una combinación de funcionalidad de reescritura de URL y enrutamiento basado en rutas de acceso.

Para ello, cree un conjunto de reescritura con una condición que compruebe un parámetro específico (cadena de consulta, encabezado, etc.) y a continuación, realice una acción en la que cambie la ruta de acceso URL (asegúrese de que Vuelva a evaluar la asignación de ruta de acceso esté habilitada). A continuación, el conjunto de reescritura debe asociarse a una regla basada en ruta de acceso. La regla basada en la ruta de acceso debe contener las mismas rutas de URL especificadas en el conjunto de reescritura y su correspondiente grupo de servidores.

Así, el conjunto de reescritura permite a los usuarios comprobar un parámetro específico y asignarle una nueva ruta, y la regla basada en la ruta de acceso permite a los usuarios asignar grupos de servidores a esas rutas. Mientras esté activada la opción "Reevaluar asignación de rutas de acceso", el tráfico se encaminará en función de la ruta especificada en el conjunto de reescritura.

Para obtener un ejemplo de caso de uso mediante cadenas de consulta, consulte Enrutamiento del tráfico mediante la selección de ruta de acceso basada en parámetros en el portal.

Reescritura de los parámetros de cadena de consulta en función de la dirección URL

Considere un escenario de un sitio web de compras en el que el vínculo visible del usuario deba ser sencillo y legible, pero el servidor back-end necesite los parámetros de la cadena de consulta para mostrar el contenido correcto.

En ese caso, Application Gateway puede capturar los parámetros de la dirección URL y agregar pares de clave-valor de cadena de consulta a partir de los de la dirección URL. Por ejemplo, supongamos que el usuario desea reescribir https://www.contoso.com/fashion/shirts a https://www.contoso.com/buy.aspx?category=fashion&product=shirts; para ello, puede usar la siguiente configuración de reescritura de direcciones URL.

Condición: si la variable de servidor uri_path es igual al patrón /(.+)/(.+)

Acción: establezca la ruta de acceso de la dirección URL en buy.aspx y la cadena de consulta en category={var_uri_path_1}&product={var_uri_path_2}

Para obtener una guía paso a paso para lograr el escenario descrito anteriormente, consulte Reescritura de dirección URL con Application Gateway mediante Azure Portal

Problemas comunes de la configuración de la reescritura

• No se permite habilitar "Volver a evaluar la asignación de rutas de acceso" para las reglas básicas de enrutamiento de solicitudes. Esto es para evitar los bucles de evaluación infinitos para una regla de enrutamiento básica.

• Debe haber al menos 1 regla de reescritura condicional o una regla de reescritura que no tenga habilitada la opción "Volver a evaluar el mapa de rutas" para las reglas de enrutamiento basadas en rutas de acceso para evitar un bucle de evaluación infinito para una regla de enrutamiento basada en rutas de acceso.

• Las solicitudes entrantes terminarían con un código de error 500 en caso de que un bucle se creara dinámicamente a partir de las entradas del cliente. Application Gateway sigue atendiendo otras solicitudes sin ninguna degradación en este escenario.

Uso de la reescritura de URL o la reescritura de encabezado host con Web Application Firewall (SKU WAF_v2)

Al configurar la reescritura de direcciones URL o la reescritura del encabezado de host, la evaluación de WAF se produce después de la modificación del encabezado de solicitud o los parámetros de dirección URL (posterior a la reescritura). Y al quitar la configuración de reescritura de encabezado de host o URL en Application Gateway, la evaluación de WAF se realiza antes de volver a escribir el encabezado (reescritura previa). Este orden garantiza que las reglas de WAF se hayan aplicado a la solicitud final que recibe el grupo de back-end.

Por ejemplo, supongamos que tiene la siguiente regla de reescritura de encabezado para el encabezado "Accept" : "text/html". Si el valor de encabezado "Accept" es igual a "text/html", se reescribirá el valor como "image/png".

Aquí, con solo la reescritura de encabezado configurada, la evaluación de WAF se realiza en "Accept" : "text/html". Pero al configurar la reescritura de direcciones URL o la reescritura del encabezado de host, la evaluación de WAF se realiza en "Accept" : "image/png".

Reescritura de direcciones URL frente a redirección de direcciones URL

En el caso de la reescritura de URL, Application Gateway reescribe la dirección URL antes de que la solicitud se envíe al back-end. Esto no cambiará lo que los usuarios ven en el explorador, porque los cambios se ocultan al usuario.

En el caso de la redirección de direcciones URL, Application Gateway envía una respuesta de redirección al cliente con la nueva dirección URL. Esto, a su vez, requiere que el cliente reenvíe su solicitud a la nueva dirección URL proporcionada en la redirección. La dirección URL que ve el usuario en el explorador se actualiza a la nueva dirección URL.

Limitaciones

• No se admiten las reescrituras cuando la puerta de enlace de aplicaciones está configurada para redirigir las solicitudes o para mostrar una página de error personalizada.
• Los nombres de encabezado de solicitud pueden contener caracteres alfanuméricos y guiones. Los nombres de encabezado que contengan otros caracteres se descartarán cuando se envíe una solicitud al destino de back-end.
• Los nombres de encabezado de respuesta solo pueden contener caracteres alfanuméricos y símbolos específicos definidos en RFC 7230.
• No se pueden volver a escribir los encabezados de conexión y de actualización
• Las reescrituras no se admiten para las respuestas 4xx y 5xx generadas directamente a partir de Application Gateway

Pasos siguientes

• Obtenga información sobre cómo reescribir encabezados HTTP con Application Gateway mediante Azure Portal
• Obtenga información sobre cómo reescribir la dirección URL con Application Gateway mediante Azure Portal