Modalità di corrispondenza delle richieste con una configurazione di route

  • Articolo

Una route in Frontdoor di Azure definisce il modo in cui il traffico viene gestito quando la richiesta in ingresso arriva al perimetro frontdoor di Azure. Tramite le impostazioni di route, viene definita 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 (classico) verrà ritirato il 31 marzo 2027. Per evitare interruzioni del servizio, è importante eseguire la migrazione dei profili di Frontdoor di Azure (classico) al livello Standard o Premium di Frontdoor di Azure entro marzo 2027. Per altre informazioni, vedere Ritiro di Frontdoor di Azure (classico).

Quando una richiesta arriva all'edge di Frontdoor di Azure (versione classica), una delle prime operazioni eseguite da Frontdoor consiste nel determinare come instradare la richiesta corrispondente a una risorsa back-end e quindi eseguire un'azione definita nella configurazione di routing. Il documento seguente 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 frontdoor è costituita da due parti principali, il "lato sinistro" e il "lato destro". Frontdoor corrisponde alla richiesta in ingresso sul lato sinistro della route, mentre il lato destro definisce la modalità di elaborazione della richiesta.

Corrispondenza in ingresso (lato sinistro)

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

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

Queste proprietà vengono espanse internamente in modo che ogni combinazione di protocollo/dominio/percorso sia un set di corrispondenze potenziale.

Decisione di routing (lato destro)

La decisione di 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 route

Questa sezione è incentrata sul modo in cui Frontdoor corrisponde a una regola di routing. Il concetto di base è che Frontdoor corrisponde sempre alla richiesta più specifica esaminando solo il "lato sinistro". Frontdoor corrisponde prima in base al protocollo, quindi al dominio e all'ultimo percorso.

Corrispondenza di host front-end

Frontdoor di Azure usa la logica seguente per trovare le corrispondenze con gli host front-end:

  1. Determinare se sono presenti route con una corrispondenza esatta nell'host front-end.
  2. Se non sono presenti corrispondenze esatte degli host front-end, la richiesta viene rifiutata e viene inviato un errore 404: Richiesta non valida.

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

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

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

Host front-end in ingresso Regole di routing corrispondenti
foo.contoso.com A, B
www.fabrikam.com A
images.fabrikam.com Errore 404: Richiesta non valida
foo.adventure-works.com A
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 che Frontdoor determina l'host front-end e i filtri specifici per le regole di routing possibili, Frontdoor seleziona quindi le regole di routing in base al percorso della richiesta. Per trovare una corrispondenza con il percorso della richiesta viene usata una logica simile agli host front-end:

  1. Determinare se sono presenti regole di routing con una corrispondenza esatta con il percorso della richiesta.
  2. Se non esiste un percorso esatto corrispondente, Frontdoor cerca una regola di routing con un percorso con caratteri jolly corrispondente.
  3. Se non sono presenti regole di routing con un percorso corrispondente, la richiesta viene rifiutata e viene inviato un errore 404: Richiesta non valida.

Nota

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

Nota

  • Tutti i percorsi senza caratteri jolly vengono considerati percorsi di corrispondenza esatta. Se un percorso termina in , /questo viene considerato una corrispondenza esatta.
  • I modelli per trovare le corrispondenze tra maiuscole e minuscole non fanno distinzione tra maiuscole e minuscole, ovvero i percorsi con maiuscole e minuscole diverse vengono considerati duplicati. Ad esempio, si ha lo stesso host usando lo stesso protocollo con percorsi /FOO e /foo. Questi percorsi sono considerati duplicati che non sono consentiti nell'impostazione Criteri di corrispondenza.

La tabella seguente è un elenco di regole di routing, host front-end e combinazione di percorso:

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

Nella tabella seguente viene illustrata la regola di routing a cui viene trovata la corrispondenza tra la richiesta in ingresso quando arriva al perimetro frontdoor:

Richiesta in ingresso Route corrispondente
www.contoso.com/ Un
www.contoso.com/a G
www.contoso.com/ab A
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 host front-end esatto senza un percorso di route catch-all (/*), non verrà trovata alcuna regola di routing.

Configurazione di esempio:

Itinerario Host 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

Dopo che Frontdoor corrisponde a una singola regola di routing, deve scegliere come elaborare la richiesta. Se frontdoor di Azure dispone di una risposta memorizzata nella cache per la regola di routing corrispondente, la richiesta viene servita al client.

Infine, Frontdoor di Azure valuta se è stato configurato o meno un set di regole per la regola di routing corrispondente. Se non viene definito alcun set di regole, la richiesta viene inoltrata al gruppo di origine senza modifiche. In caso contrario, i set di regole vengono elaborati nell'ordine configurato. I set di regole possono eseguire l'override di una route forzando il traffico verso un gruppo di origine specifico.

Se Frontdoor (versione classica) non ha una risposta memorizzata nella cache per la regola di routing corrispondente, valuta se la riscrittura url è configurata per la regola di routing corrispondente. Se non è presente alcun percorso di inoltro personalizzato, la richiesta viene inoltrata al back-end appropriato nel pool back-end configurato senza modifiche. Se è stato definito un percorso di inoltro personalizzato, il percorso della richiesta viene aggiornato come definito nel percorso di inoltro personalizzato e quindi viene inoltrato al back-end.

Passaggi successivi