Modalità di corrispondenza delle richieste con una configurazione del percorso

Una route in Frontdoor di Azure definisce il modo in cui il traffico viene gestito quando una richiesta in ingresso arriva al perimetro di Frontdoor di Azure. Le impostazioni di route stabiliscono un'associazione tra un dominio e un gruppo di origine. Usando funzionalità avanzate, ad esempio Pattern to Match e Rule set, è possibile avere un controllo granulare sul traffico verso le risorse back-end.

Nota

Quando si usano i set di regole di Frontdoor, è possibile configurare una regola per eseguire l'override del gruppo di origine per una richiesta. Il gruppo di origine impostato dal set di regole sostituisce il processo di routing descritto in questo articolo.

Importante

Frontdoor di Azure (versione classica) non supporta la creazione del profilo, il nuovo onboarding del dominio o i certificati gestiti e verrà ritirato il 31 marzo 2027. Per evitare interruzioni del servizio, migrate per Frontdoor di Azure Standard o Premium. Per altre informazioni, vedere Frontdoor di Azure (versione classica) ritiro.

Quando una richiesta arriva al perimetro frontdoor di Azure (versione classica), uno dei primi passaggi consiste nel determinare come instradare la richiesta corrispondente a una risorsa back-end e quindi eseguire un'azione definita nella configurazione di routing. Questo documento illustra in che modo Frontdoor determina la configurazione di route da usare durante l'elaborazione di una richiesta.

Struttura di una configurazione di routing di Frontdoor

Una regola di routing di Front Door è costituita da due parti principali: "lato sinistro" e "lato destro". Front Door corrisponde alla richiesta in ingresso sul lato sinistro della route, mentre il lato destro definisce come viene elaborata la richiesta.

Corrispondenza in arrivo (lato sinistro)

Le proprietà seguenti determinano se la richiesta in ingresso corrisponde alla regola di routing (lato sinistro):

  • Protocolli HTTP - HTTP o HTTPS
  • Dominio : ad esempio: www.foo.com, *.bar.com
  • Percorsi - Ad esempio: /*, /users/*, /file.gif

Queste proprietà sono ampliate internamente in modo che ogni combinazione di protocollo/dominio/percorso sia un insieme di corrispondenze potenziali.

Decisione di routing (lato destro)

La decisione su come elaborare la richiesta dipende dal fatto che la memorizzazione nella cache sia abilitata per la route. Se una risposta memorizzata nella cache non è disponibile, la richiesta viene inoltrata all'origine appropriata.

Corrispondenza del percorso

Questa sezione illustra in che modo Front Door abbina le richieste alle regole di routing. Il principio di base è che Frontdoor corrisponde sempre alla richiesta più specifica valutando le proprietà "lato sinistro": protocollo, dominio e percorso, in tale ordine.

Corrispondenza di host front-end

Frontdoor di Azure usa i passaggi seguenti per trovare le corrispondenze con gli host front-end:

  1. Verificare la presenza di route con una corrispondenza precisa nell'host frontend.
  2. Se non trova una corrispondenza esatta, rifiuta la richiesta con un errore 404: Richiesta non valida.

Le tabelle seguenti illustrano tre regole di routing diverse con i relativi host front-end e percorsi:

Regola di routing Host front-end Percorso
Un foo.contoso.com /*
G foo.contoso.com /Gli utenti/*
C www.fabrikam.com, foo.adventure-works.com /*/Immagini/*

La tabella seguente mostra i risultati corrispondenti per le regole di routing nella tabella precedente:

Host frontend in arrivo Regole di routing corrispondenti
foo.contoso.com A, B
www.fabrikam.com C
images.fabrikam.com Errore 404: Richiesta non valida
foo.adventure-works.com C
contoso.com Errore 404: Richiesta non valida
www.adventure-works.com Errore 404: Richiesta non valida
www.northwindtraders.com Errore 404: Richiesta non valida

Corrispondenza del percorso

Dopo Frontdoor di Azure determina l'host front-end specifico e filtra le regole di routing possibili, seleziona le regole di routing in base al percorso della richiesta. Il servizio usa la logica seguente:

  1. Verificare la presenza di regole di routing con una corrispondenza esatta con il percorso della richiesta.
  2. Se non trova una corrispondenza esatta, cerchi una regola di routing con un percorso caratterizzato da caratteri jolly che corrisponda.
  3. Se non trova un percorso corrispondente, rifiutare la richiesta con un errore 404: Richiesta non valida.

Nota

Il carattere jolly * è valido solo per i percorsi che non hanno altri caratteri dopo. Inoltre, il carattere jolly * deve essere preceduto da una barra obliqua /. I percorsi senza caratteri jolly sono considerati percorsi di corrispondenza esatta. Un percorso che termina con una barra obliqua / è anche un percorso di corrispondenza esatta. Assicurarsi che i percorsi seguano queste regole per evitare errori.

Nota

  • I percorsi senza caratteri jolly sono considerati percorsi di corrispondenza esatta. Un percorso che termina con un / è anche una corrispondenza esatta.
  • I modelli di percorso non fanno distinzione tra maiuscole e minuscole. Ad esempio, /FOO e /foo vengono considerati duplicati e non sono consentiti nell'impostazione dei pattern da corrispondere.

Nella tabella seguente sono elencate le regole di routing con le combinazioni di host front-end e percorso:

Regola di routing Host front-end Percorso
Un www.contoso.com /
G 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 /percorso/

La tabella seguente illustra la regola di routing corrispondente a una richiesta in ingresso nel perimetro di Frontdoor di Azure:

Richiesta in arrivo Route corrispondente
www.contoso.com/ Un
www.contoso.com/a G
www.contoso.com/ab C
www.contoso.com/abc D
www.contoso.com/abzzz G
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 G
www.contoso.com/path/ H
www.contoso.com/path/zzz G

Avviso

Se non sono presenti regole di routing per un front-end host a corrispondenza esatta senza un percorso di instradamento catch-all (/*), non verrà associata alcuna regola di routing.

Configurazione di esempio:

Itinerario Padrone di casa / Ospitante / Conduttore (depending on the intended context) Percorso
Un profile.contoso.com /API/*

Tabella corrispondente:

Richiesta in ingresso Route corrispondente
profile.domain.com/other Nessuno. Errore 404: Richiesta non valida

Decisione di routing

Quando Frontdoor di Azure corrisponde a una regola di routing, decide come elaborare la richiesta. Se è disponibile una risposta memorizzata nella cache, invia la risposta al client.

Se si configura un set di rule per la regola di routing corrispondente, Frontdoor di Azure lo elabora in ordine. I set di regole possono eseguire l'override di una route indirizzando il traffico a un gruppo di origine specifico. Se non si definisce un set di regole, Frontdoor di Azure inoltra la richiesta al gruppo di origine senza modifiche.

Se Frontdoor di Azure (versione classica) non ha una risposta memorizzata nella cache, verifica la presenza di una configurazione di riscrittura URL. Se non si definisce un percorso di inoltro personalizzato, Frontdoor di Azure inoltra la richiesta al back-end appropriato nel pool back-end configurato. Se si definisce un percorso di inoltro personalizzato, Frontdoor di Azure aggiorna di conseguenza il percorso della richiesta e lo inoltra al back-end.

Passaggi successivi

  • Last updated on