Compartir a través de


Reescritura de URL

Azure Front Door admite la reescritura de URL para cambiar la ruta de acceso de la solicitud que se enruta a su origen. La reescritura de URL le permite establecer 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.

Con esta característica, puede redirigir a los usuarios finales a un origen diferente en función de sus tipos de dispositivo o del tipo de archivo solicitado. La acción de reescritura de URL se puede encontrar en una configuración de conjunto de reglas.

Captura de pantalla de la acción de reescritura de URL en la configuración de un conjunto de reglas.

Patrón de origen

El patrón de origen es la ruta de acceso URL de la solicitud inicial que desea reemplazar. Actualmente, el patrón de origen usa una coincidencia basada en el prefijo. Para una coincidencia con todas las ruta de acceso de las direcciones URL, puede definir una barra (/) como valor de patrón de origen.

Para el patrón de origen en una acción de reescritura de URL, solo se tiene en cuenta la ruta de acceso después de que los patrones coincidan en la configuración de la ruta. Por ejemplo, tiene el siguiente formato de dirección URL entrante contoso.com/pattern-to-match/source-pattern, el conjunto de reglas solo considera /source-pattern como el patrón de origen que se va a reescribir. El formato de la dirección URL de salida después de que se aplique la reescritura de URL es contoso.com/pattern-to-match/destination.

En caso de que sea necesario quitar el segmento /pattern-to-match de la dirección URL, establezca la ruta de acceso de origen del grupo de origen en la configuración de la ruta en /.

Destination

Ruta de acceso de destino usada para reemplazar el patrón de origen. Por ejemplo, si la ruta de acceso de la dirección URL de la solicitud es contoso.com/foo/1.jpg, el patrón de origen es /foo/, y el destino es /bar/, el contenido se sirve desde contoso.com/bar/1.jpg desde el origen.

Conservar la ruta de acceso sin coincidencia

Conservar la ruta de acceso no coincidente permite anexar el resto de la ruta después del patrón de origen a la nueva ruta de acceso. Cuando conservar la ruta de acceso no coincidente se establece en No (valor predeterminado), se elimina el resto de la ruta después del patrón de origen.

Conservar la ruta de acceso sin coincidencia Patrón de origen Destination Solicitud entrante Contenido servido desde el origen
/ /foo/ contoso.com/sub/1.jpg /foo/sub/1.jpg
/sub/ /foo/ contoso.com/sub/image/1.jpg /foo/image/1.jpg
No /sub/ /foo/2.jpg contoso.com/sub/image/1.jpg /foo/2.jpg

Importante

Azure Front Door (clásico) se retirará el 31 de marzo de 2027. Para evitar cualquier interrupción del servicio, es importante migrar los perfiles de Azure Front Door (clásico) al nivel Estándar o Premium de Azure Front Door para marzo de 2027. Para obtener más información, consulte retirada de Azure Front Door (clásico).

Azure Front Door (clásico) admite la reescritura de URL mediante la configuración de una ruta de acceso de reenvío personalizada al configurar la regla de tipo de enrutamiento de reenvío. De forma predeterminada, si solo se define una barra diagonal (/*), Front Door copia la ruta de acceso de dirección URL entrante a la dirección URL usada en la solicitud reenviada. El encabezado host usado en la solicitud reenviada se configura para el back-end seleccionado. Para más información, consulte Encabezado de host de back-end.

La parte sólida de la reescritura de direcciones URL es que la ruta de reenvío personalizada copia en la ruta de reenviada cualquier parte de la ruta entrante que coincida con una ruta comodín.

La siguiente tabla muestra un ejemplo de una solicitud entrante y la ruta de acceso reenviada correspondiente cuando se utiliza una ruta de acceso de reenvío personalizada de /fwd/ para una ruta de acceso coincidente con un carácter comodín. La parte a/b/c de la ruta de acceso representa la parte que reemplaza el carácter comodín.

Ruta de acceso de dirección URL entrante Ruta de acceso de coincidencia Ruta de acceso de reenvío personalizada Ruta de acceso reenviada
/foo/a/b/c /foo/* /fwd/ /fwd/a/b/c

Ejemplo de reescritura de direcciones URL

Considere la posibilidad de una regla de enrutamiento con la siguiente combinación de hosts de front-end y rutas de acceso configuradas:

Hosts Rutas de acceso
www.contoso.com /*
/foo
/foo/*
/foo/bar/*

La primera columna de la tabla siguiente muestra ejemplos de solicitudes entrantes y la segunda muestra cuál sería la ruta coincidente más específica definida. Las tres columnas siguientes de la tabla son ejemplos de rutas de acceso de reenvío personalizadas.

Por ejemplo, se puede leer en la segunda fila, que para una solicitud entrante de www.contoso.com/sub, si la ruta de reenvío personalizada es /, la ruta reenviada sería /sub. Si la ruta de reenvío personalizada era /fwd/, la ruta de acceso reenviada es /fwd/sub. Las partes destacadas de las rutas de acceso representan las porciones que forman parte de la coincidencia de caracteres comodín.

Solicitud entrante Ruta de acceso de coincidencia más específica / /fwd/ /foo/ /foo/bar/
www.contoso.com/ /* / /fwd/ /foo/ /foo/bar/
www.contoso.com/sub /* /sub /fwd/sub /foo/sub /foo/bar/sub
www.contoso.com/a/b/c /* /a/b/c /fwd/a/b/c /foo/a/b/c /foo/bar/a/b/c
www.contoso.com/foo /foo / /fwd/ /foo/ /foo/bar/
www.contoso.com/foo/ /foo/* / /fwd/ /foo/ /foo/bar/
www.contoso.com/foo/bar /foo/* /bar /fwd/bar /foo/bar /foo/bar/bar

Nota:

Azure Front Door (classic) solo admite la reescritura de direcciones URL de una ruta de acceso estática a otra. La conservación de la ruta de acceso sin coincidencia se admite en Azure Front Door Estándar y Premium. Para más información, consulte Conservar la ruta de acceso sin coincidencia.

Configuración opcional

Hay valores opcionales adicionales que también puede especificar para cualquier configuración de regla de enrutamiento:

  • Configuración de caché: si la opción está deshabilitada o no se ha especificado, las solicitudes que coincidan con esta regla de enrutamiento no intenta usar el contenido almacenado en caché y, en su lugar, lo capturan siempre desde el back-end. Para más información, consulte Almacenamiento en caché con Azure Front Door.

Pasos siguientes