Reescritura de los encabezados HTTP y direcciones URL con Application Gateway

Application Gateway le permite volver a escribir contenido seleccionado en solicitudes y respuestas. Con esta característica, puede traducir direcciones URL, parámetros de cadena de consulta y modificar encabezados de solicitud y respuesta. También puede agregar condiciones para asegurarse de que la dirección URL o los encabezados especificados solo se reescribirán cuando se cumplan determinadas 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 a un cliente y servidor pasar información adicional con una solicitud o respuesta. Al reescribir estos encabezados, puede realizar tareas importantes, entre las que se incluyen:

• Agregar campos de encabezado relacionados con la seguridad, como HSTS y X-XSS-Protection
• Eliminación de campos de encabezado de respuesta que podrían revelar información confidencial
• Eliminación de la información del puerto en los encabezados X-Forwarded-For

Puede volver a escribir 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 aprender a reescribir 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:

• Vuelva a escribir el nombre de host, la ruta de acceso y la cadena de consulta de la dirección URL de la 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 aprender a reescribir la dirección URL con Application Gateway mediante Azure Portal, consulte aquí.

Comprensión de las reescrituras en Application Gateway

Un conjunto de reescritura consiste en una colección conformada por una regla de enrutamiento, una condición y una acción.

• Asociación de reglas de enrutamiento de solicitudes: La configuración de reescritura se asocia a una escucha de origen a través de su regla de enrutamiento. Cuando se usa una regla de enrutamiento del tipo Basic, la configuración de reescritura se asocia a su agente de escucha y funciona como reescritura global. Cuando usas una regla de enrutamiento basada en rutas, defines la configuración de reescritura según el mapa de rutas del 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 configuración es opcional. En función de las condiciones que defina, Application Gateway evalúa el contenido de las solicitudes y respuestas HTTP(S). La siguiente "acción de reescritura" se produce 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. Es decir, es una operación AND lógica. 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 le 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 el valor de un encabezado de solicitud capturado, especifique la sintaxis como {http_req_headerName}.
  • Valor del encabezado de respuesta: para usar el valor de un 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 permite hacer coincidir y 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 sobre 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 de coincidencias de valores de encabezado {capt_header_value_matcher} no se admite actualmente a través del portal. Por lo tanto, debe usar un método que no sea portal para las operaciones PUT si usa este campo.

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

• URL de la ruta: Nuevo valor para establecer como ruta.
• 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 no activa esta opción, se utiliza la ruta original de la URL para que coincida con el patrón de ruta en el mapa de rutas de la URL. Si establece esta opción en true, el mapa de ruta de acceso URL se vuelve a evaluar para comprobar la coincidencia 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

Application Gateway admite la coincidencia de patrones y la captura en Condición y Acción. En Acción, admite la coincidencia de patrones y la captura solo para un encabezado específico.

Coincidencia de patrones

Application Gateway usa expresiones regulares para la coincidencia de patrones. Use 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: use esta configuración para que coincida con los valores de un encabezado o una variable de servidor. Para hacer coincidir un patrón en "Condiciones", use la propiedad "pattern".
• Acción: la coincidencia de patrones en el Conjunto de Acciones solo está disponible para el encabezado de respuesta Set-Cookie. Para hacer coincidir un patrón para Set-Cookie en una acción, use la HeaderValueMatcher propiedad . Si se captura, su valor se puede usar como {capt_header_value_matcher}. Dado que puede haber varios Set-Cookie encabezados, la coincidencia de patrones aquí le permite buscar una cookie específica. Por ejemplo, en una versión específica del agente de usuario, se quiere reescribir el set-cookie encabezado de respuesta 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, es posible que se produzcan problemas al usar expresiones regulares compatibles con Perl (PCRE) al realizar aserciones lookahead y lookbehind (negativas o positivas).

Sintaxis para capturar

Puede usar patrones para capturar una subcadena 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 quiera. Perl define más variables numeradas para representar estas cadenas capturadas. Puede encontrar algunos ejemplos 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 / como prefijo y sufijo en el patrón no debe especificarse para hacer coincidir el valor. 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 usar todo el valor, 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.
cifrados_soportados	Una lista de cifrados admitidos por el cliente.
algoritmos_de_cifrado_utilizados	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.
puerto_cliente	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.
cliente_usuario	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.
método_http	Método usado para realizar la solicitud de URL. Por ejemplo, GET, POST, etc.
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	Lista de pares variable-valor que sigue en la dirección URL solicitada después de ?. 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.
esquema_de_solicitud	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 (bytes enviados)	El número de bytes enviados a un cliente.
puerto_del_servidor	El puerto del servidor que ha aceptado una solicitud.
protocolo_de_conexión_ssl	El protocolo de una conexión TLS establecida.
SSL habilitado	"On" si la conexión funciona en modo TLS. No puede ser 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 del URL original antes de cualquier tipo de 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 haría con otras variables de servidor.

Nombre de la variable	Descripción
certificado_de_cliente	Certificado de cliente, en formato PEM, para una conexión SSL establecida.
fecha_de_finalización_del_certificado_del_cliente	Fecha de finalización del certificado de cliente.
client_certificate_fingerprint	Huella digital SHA1 del certificado de cliente para una conexión SSL establecida.
emisor_de_certificado_de_cliente	Cadena del "nombre distintivo del emisor" del certificado de cliente para una conexión SSL establecida.
número_de_serie_del_certificado_del_cliente	Número de serie del certificado de cliente para una conexión SSL establecida.
fecha de inicio del certificado de cliente	Fecha de inicio del certificado de cliente.
sujeto_del_certificado_del_cliente	Cadena del "nombre distintivo del firmante" del certificado de cliente para una conexión SSL establecida.
verificación_de_certificado_de_cliente	Resultado de la comprobación del certificado de cliente: SUCCESS, FAILED:<reason> o NONE si un certificado no estaba 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, puede redirigir originalmente los clientes a una ruta de acceso como "/blog", pero ahora quiere enviarlos a "/updates" debido a un cambio en la estructura de contenido.

Advertencia

Es posible que tenga que modificar una dirección URL de redireccionamiento al configurar Application Gateway para invalidar el nombre de host hacia el back-end. En esta configuración, el back-end ve un nombre de host diferente al del explorador. El redireccionamiento no usa el nombre de host correcto. Esta configuración no se recomienda.

Para obtener más información sobre las limitaciones e implicaciones de esta configuración, consulte Conservar el nombre de host HTTP original entre un proxy inverso y su aplicación web back-end. Para obtener la configuración recomendada para App Service, consulte "Dominio personalizado (recomendado)" en Configuración de App Service con Application Gateway. La reescritura del encabezado de ubicación en la respuesta, tal como se describe en el ejemplo siguiente, debe considerarse una solución alternativa y no aborda 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 compruebe si el encabezado de ubicación de 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. Escriba {http_resp_Location_1}://contoso.com{http_resp_Location_2} como valor de 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 puede 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 servidores 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, use una combinación de la funcionalidad de reescritura de direcciones URL y el enrutamiento basado en rutas.

Cree un conjunto de reescritura con una condición que compruebe si hay un parámetro específico (cadena de consulta, encabezado, etc.) y luego realice una acción en la que cambie la ruta de acceso de la URL (asegúrese de que Reevaluation path map está habilitado). Asocie el conjunto de reescritura a una regla basada en ruta. 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.

Por lo tanto, el conjunto de reescrituras le permite comprobar un parámetro específico y asignarle una nueva ruta, y la regla basada en rutas le permite asignar grupos de backend a dichas rutas. Siempre que se habilite "Volver a evaluar el mapa de rutas de acceso", las rutas de tráfico se definirán según la ruta de acceso 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 donde el vínculo visible para el usuario es sencillo y legible, pero el servidor back-end necesita los parámetros de cadena de consulta para mostrar el contenido correcto.

En ese caso, Application Gateway puede capturar parámetros de la dirección URL y agregar pares clave-valor de consulta de esos parámetros a la dirección URL. Por ejemplo, si el usuario quiere volver a escribir https://www.contoso.com/fashion/shirts en https://www.contoso.com/buy.aspx?category=fashion&product=shirts, puede lograr este objetivo a través de la siguiente configuración de reescritura de dirección URL.

Condición : si la variable uri_path de servidor 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 la dirección URL con Application Gateway mediante Azure Portal.

Problemas comunes de la configuración de la reescritura

• No se puede habilitar "Volver a evaluar la asignación de rutas de acceso" para reglas básicas de enrutamiento de solicitudes. Esta restricción impide un bucle de evaluación infinito para una regla de enrutamiento básica.

• En el caso de las reglas de enrutamiento basadas en rutas de acceso, necesita al menos una regla de reescritura condicional o una regla de reescritura sin tener habilitada la opción "Volver a evaluar la asignación de rutas de acceso". Este requisito impide un bucle de evaluación infinito para una regla de enrutamiento basada en rutas de acceso.

• Si un bucle se crea dinámicamente en función de las entradas del cliente, las solicitudes entrantes finalizan con un código de error 500. 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). Al quitar la configuración de reescritura de URL o encabezado de host en Application Gateway, la evaluación de WAF se produce antes de la reescritura del encabezado. Este ordenamiento garantiza que las reglas de WAF se apliquen a la solicitud final que recibe el grupo de servidores de back-end.

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

Solo con la reescritura de encabezado configurada, la evaluación del WAF se produce 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 produce en "Accept" : "image/png".

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

Para una reescritura de direcciones URL, Application Gateway vuelve a escribir la dirección URL antes de enviar la solicitud al back-end. Esta acción no cambia lo que ven los usuarios en el explorador porque los cambios están ocultos del 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. Esa respuesta requiere que el cliente vuelva a enviar su solicitud a la nueva dirección URL proporcionada en el redireccionamiento. 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 contienen otros caracteres se descartan cuando se envía 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 X-Original-Host, Connection y upgrade, los encabezados.
• Las reescrituras no se admiten para las respuestas 4xx y 5xx generadas directamente desde 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