Cómo hacer coincidir las solicitudes con una configuración de ruta

  • Artículo

Una ruta en Azure Front Door define cómo se administra el tráfico cuando la solicitud entrante llega al borde de Azure Front Door. Mediante la configuración de la ruta, se define una asociación entre un dominio y un grupo de origen. Mediante el uso de características avanzadas como Patrón de coincidencia y Conjuntos de reglas, puede tener un control granular sobre el tráfico a los recursos de back-end.

Nota

Cuando se usan los conjuntos de reglas de Front Door, puede configurar una regla para invalidar el grupo de origen de una solicitud. El grupo de origen establecido por el conjunto de reglas invalida el proceso de enrutamiento descrito en este artículo.

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 antes de marzo de 2027. Para obtener más información, consulte Retirada de Azure Front Door (clásico).

Cuando llega una solicitud al perímetro de Azure Front Door (clásico), una de las primeras cosas que Front Door hace es determinar cómo enrutar la solicitud coincidente a un recurso back-end y, a continuación, realizar una acción definida en la configuración de enrutamiento. El siguiente documento explica el modo en que Front Door determina qué configuración de enrutamiento se usará al procesar una solicitud.

Estructura de una configuración de enrutamiento de Front Door

Una regla de enrutamiento de Front Door se compone de dos partes principales: el "lado izquierdo" y el "lado derecho". Front Door hace coincidir la solicitud entrante con el lado izquierdo de la ruta, mientras que el lado derecho define cómo se procesa la solicitud.

Coincidencia de entrada (lado izquierdo)

Las propiedades siguientes determinan si la solicitud entrante coincide con la regla de enrutamiento (o el lado izquierdo):

  • Protocolos HTTP: HTTP o HTTPS
  • Dominio: Por ejemplo: www.foo.com, *.bar.com
  • Rutas de acceso: Por ejemplo: /*, /users/*, /file.gif

Estas propiedades se expanden de forma interna para que cada combinación de protocolo, dominio y ruta de acceso sea un conjunto de posible coincidencia.

Decisión de enrutamiento (lado derecho)

La decisión de cómo procesar la solicitud depende de si el almacenamiento en caché está habilitado para la ruta. Si una respuesta almacenada en caché no está disponible, la solicitud se reenvía al origen adecuado.

Búsqueda de coincidencia de ruta

Esta sección se centra en cómo Front Door coincide con una regla de enrutamiento. El concepto básico es que siempre Front Door coincide con la solicitud más específica fijándose solo en el "lado izquierdo". Front Door primero se basa en el protocolo, luego en el dominio y por último en la ruta de acceos.

Coincidencia de host de front-end

Azure Front Door usa la siguiente lógica para buscar coincidencias con los hosts de front-end:

  1. Determine si hay alguna ruta con una coincidencia exacta en el host de front-end.
  2. Si no hay ninguna coincidencia exacta de hosts de front-end, se rechaza la solicitud y se envía un error 400: Solicitud incorrecta.

En las tablas siguientes se muestran tres reglas de enrutamiento diferentes con el host de front-end y las rutas de acceso:

Regla de enrutamiento Hosts de front-end Path
Un foo.contoso.com /*
B foo.contoso.com /users/*
C www.fabrikam.com, foo.adventure-works.com /*, /images/*

En la tabla siguiente se muestran los resultados coincidentes de las reglas de enrutamiento anteriores:

Host de front-end entrante Reglas de enrutamientos que coinciden
foo.contoso.com A, B
www.fabrikam.com C
images.fabrikam.com Error 400: Bad Request
foo.adventure-works.com C
contoso.com Error 400: Bad Request
www.adventure-works.com Error 400: Bad Request
www.northwindtraders.com Error 400: Bad Request

Coincidencia de ruta de acceso

Una vez que Front Door determina el host de front-end específico y filtra las posibles reglas de enrutamiento, Front Door selecciona las reglas de enrutamiento en función de la ruta de acceso de la solicitud. Se usa una lógica similar a los hosts de front-end para buscar coincidencias con la ruta de acceso de la solicitud:

  1. Determine si hay reglas de enrutamiento con una coincidencia exacta con la ruta de acceso de la solicitud.
  2. Si no hay una ruta de acceso coincidente exacta, Front Door busca una regla de enrutamiento con una ruta de acceso con caracteres comodín que coincida.
  3. Si no se encuentran reglas de enrutamiento con una ruta coincidente, la solicitud se rechaza y se envía un error 400: Solicitud incorrecta.

Nota:

El carácter comodín * solo es válido para las rutas de acceso que no tienen ningún otro carácter después de él. Además, el carácter comodín * debe ir precedido de una barra diagonal /. Las rutas de acceso sin un carácter comodín se consideran rutas de coincidencia exacta. Una ruta de acceso que termina en una barra diagonal / también es de coincidencia exacta. Asegúrese de que las rutas de acceso siguen estas reglas para evitar errores.

Nota:

  • Las rutas de acceso sin un carácter comodín se consideran con coincidencia exacta. Si una ruta de acceso termina en /, se considera una coincidencia exacta.
  • Los patrones de coincidencia de las rutas de acceso no distinguen mayúsculas de minúsculas, lo que significa que las rutas con un uso diferente de mayúsculas y minúsculas se tratan como duplicados. Por ejemplo, tendrá el mismo host y el mismo protocolo con las rutas de acceso /FOO y /foo. Estas rutas de acceso se consideran duplicadas, lo que no se permite en la configuración de los patrones de coincidencia.

La tabla siguiente es una lista de reglas de enrutamiento, host de front-end y combinación de rutas de acceso:

Regla de enrutamiento Host de front-end Path
Un www.contoso.com /
N www.contoso.com /*
C www.contoso.com /ab
D www.contoso.com /abc
E www.contoso.com /abc/
F www.contoso.com /abc/*
G www.contoso.com /abc/def
H www.contoso.com /path/

En la tabla siguiente se muestra la regla de enrutamiento a la que se hace coincidir la solicitud entrante al llegar al borde de Front Door:

Solicitud entrante Ruta coincidente
www.contoso.com/ A
www.contoso.com/a N
www.contoso.com/ab C
www.contoso.com/abc D
www.contoso.com/abzzz N
www.contoso.com/abc/ E
www.contoso.com/abc/d F
www.contoso.com/abc/def G
www.contoso.com/abc/defzzz F
www.contoso.com/abc/def/ghi F
www.contoso.com/path N
www.contoso.com/path/ H
www.contoso.com/path/zzz N

Advertencia

Si no hay ninguna regla de enrutamiento para un host de front-end con coincidencia exacta con una ruta de acceso de ruta comodín (/*), entonces no será una coincidencia con una regla de enrutamiento.

Configuración de ejemplo:

Enrutar Host Path
Un profile.contoso.com /api/*

Tabla de búsqueda de coincidencias:

Solicitud entrante Ruta coincidente
profile.domain.com/other Ninguno. Error 400: Bad Request

Decisión de enrutamiento

Una vez que Front Door ha coincidido con una única regla de enrutamiento, debe elegir cómo procesar la solicitud. Si Azure Front Door tiene una respuesta almacenada en caché disponible para la regla de enrutamiento coincidente, la solicitud se envía de vuelta al cliente.

Por último, Azure Front Door evalúa si tiene un conjunto de reglas configurado para la regla de enrutamiento coincidente. Si no se define ningún conjunto de reglas, la solicitud se reenvía al grupo de origen sin ningún cambio. De lo contrario, los conjuntos de reglas se procesan en el orden configurado. Los conjuntos de reglas pueden invalidar una ruta al forzar el tráfico a un grupo de origen específico.

Si Front Door (classic) no tiene una respuesta almacenada en caché para la regla de enrutamiento coincidente, evalúa si la reescritura de URL está configurada para la regla de enrutamiento coincidente. Si no hay ninguna ruta de acceso de reenvío personalizada, la solicitud se reenvía al back-end adecuado del grupo de back-end configurado sin cambios. Si se ha definido una ruta de reenvío personalizada, la ruta de acceso de la solicitud se actualiza según lo definido en la ruta de acceso de reenvío personalizada y, a continuación, se reenvía al back-end.

Pasos siguientes