Media CDN offre funzionalità avanzate di routing HTTP che consentono di mappare il traffico a origini e configurazioni perimetrali specifiche a un livello granulare.
Configura una regola di route
Configura una regola di routing per un servizio Media CDN.
Console
Nella console Google Cloud, vai alla pagina Media CDN.
Per aprire la pagina Dettagli del servizio per cui vuoi configurare una regola di route, fai clic sul nome del servizio.
Per passare alla modalità di modifica, fai clic sul pulsante Modifica.
Per andare alla sezione Routing (Inoltro), fai clic su Avanti.
Specifica almeno una regola host. Fai clic su Aggiungi regola host. Poi esegui la seguenti:
In Host, specifica almeno un host per la corrispondenza.
In Descrizione, fornisci una breve descrizione della regola host.
In alternativa, per modificare una regola host, fai clic sulla freccia per espanderla.
Specifica almeno una regola di route. Fai clic su Aggiungi regola di percorso.
In alternativa, per modificare una regola di percorso, fai clic su
Modifica nella riga corrispondente.Nel riquadro Modifica regola di route, per Priorità, imposta un valore per la priorità del route.
Per Descrizione, fornisci una breve descrizione che possa aiutare a identificare la regola in un elenco di regole.
Nella sezione Corrispondenza, specifica almeno una condizione di corrispondenza. Clic Aggiungi una condizione di corrispondenza. Poi:
- In Tipo di corrispondenza, seleziona un'opzione di corrispondenza del percorso.
In Corrispondenza del percorso, specifica i nomi, i percorsi o i modelli. Valuta la possibilità di utilizzare la corrispondenza di pattern con caratteri jolly.
Se necessario, seleziona anche Attiva la distinzione tra maiuscole e minuscole per il valore del percorso.
(Facoltativo) Seleziona Intestazioni corrispondenti e Corrispondenza parametri di ricerca. Poi, fai clic sui pulsanti pertinenti per aggiungere intestazioni e parametri di query. Per ogni opzione, specifica nome, tipo di corrispondenza e valore.
Per ulteriori informazioni, consulta Corrispondenza con intestazioni e parametri di query.
Per salvare la condizione di corrispondenza, fai clic su Fine.
Per Azione principale, seleziona una delle seguenti opzioni:
Recupero da un'origine: per indirizzare le richieste a un'origine specifica, seleziona questa opzione e poi un'origine.
Reindirizzamento URL: per reindirizzare le richieste, seleziona questa opzione. Quindi, specifica il tipo di reindirizzamento, il percorso il codice di stato.
Se vuoi, seleziona le opzioni per reindirizzare tutte le risposte a HTTPS, o rimuovere la query.
Fai clic su Configurazioni avanzate.
Nella sezione Azione intestazione, fai clic su Aggiungi un elemento.
Seleziona un tipo di azione e poi specifica un'intestazione come coppia di nome e valore. Poi fai clic su Fine.
Nella sezione Azione del percorso, fai clic su Aggiungi un elemento.
Specifica un tipo di azione e le relative opzioni. Poi fai clic su Fine.
Per Filtro del metodo HTTP, seleziona Personalizza filtro del metodo HTTP.
Quindi seleziona i metodi HTTP che vuoi venga inviato tramite proxy alla tua origine.
Per salvare la regola di route, fai clic su Salva.
Per salvare le modifiche apportate al servizio, fai clic su Aggiorna servizio.
gcloud e YAML
Esportare la configurazione di Media CDN in un file YAML. Utilizza il comando
gcloud edge-cache services export
.gcloud edge-cache services export SERVICE_NAME \ --destination=FILENAME.yaml
Sostituisci quanto segue:
SERVICE_NAME
: il nome del servizioFILENAME
: il nome del file YAML
Aggiorna il file YAML con la configurazione richiesta come descritto nelle sezioni di questa pagina.
Per aggiornare il servizio, importa la configurazione di Media CDN dal file YAML. Utilizza la Comando
gcloud edge-cache services import
.gcloud edge-cache services import SERVICE_NAME \ --source=FILENAME.yaml
Richieste con corrispondenza
Una configurazione Media CDN contiene un insieme di route definite
Percorsi
per un
EdgeCacheService
risorsa.
Queste route associano le richieste in base (almeno) a un host. Per ulteriori dettagli su come
il traffico è diretto a un'origine, vedi
HostRule
e PathMatcher
.
Ogni route è in grado di definire la propria configurazione CDN, riscritture, reindirizzamenti
Criteri CORS, intestazioni HTTP personalizzate e mappatura delle origini.
Le route possono condividere le origini.
Ad esempio, puoi instradare le richieste di manifest a un'origine specifica e definire un TTL della cache di breve durata e un regolamento sulla cache negativa. Le richieste di segmenti possono essere suddivise in un'altra origine utilizzando intestazioni e parametri di query per suddividere utenti o tipi di manifest specifici.
L'esempio seguente mostra come indirizzare le richieste che corrispondono a un'intestazione specifica
parametro di query e prefisso del percorso per l'host media.example.com
:
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 10 origin: staging-live-origin matchRules: - prefixMatch: /vod/ headerMatches: - headerName: "x-staging-client" presentMatch: true queryParameterMatches: - name: "live" exactMatch: "yes" routeAction: cdnPolicy: defaultTtl: 5s
Corrispondenza percorso
Media CDN supporta la corrispondenza completa (esatta), con prefisso e con caratteri jolly. La corrispondenza dei percorsi può essere combinata con la corrispondenza basata su host, intestazioni e parametri di query per creare regole di routing delle richieste granulari.
Di seguito sono riportati tre modi per trovare una corrispondenza in base al percorso dell'URL.
Campo | Descrizione | Esempio |
---|---|---|
matchRules[].fullPathMatch
|
La condizione fullPathMatch corrisponde al percorso completo dell'URL,
che non include la stringa di query. Devi specificare le barre diagonali
finali, se pertinenti.
|
Una route con una regola di corrispondenza Un |
matchRules[].prefixMatch
|
La condizione prefixMatch corrisponde al prefisso del percorso dell'URL. URL
che iniziano con la stessa corrispondenza di stringa.
|
Una route con una regola di corrispondenza |
matchRules[].pathTemplateMatch
|
La condizione pathTemplateMatch supporta
operatori con caratteri jolly, che ti consentono di associare pattern URL e percorsi
segmenti, nonché di acquisire variabili con nome per riscrivere gli URL.
|
Una route con regola di corrispondenza
Sia Per altri esempi, consulta corrispondenza pattern. |
Per ulteriori dettagli, consulta la specifica API per
MatchRule
Ad esempio, per trovare una corrispondenza per tutte le richieste che iniziano con /stream/
, crea una regola di routing simile alla seguente:
name: prod-service routing: hostRules: - hosts: - media.example.com - *.vod.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 matchRules: - prefixMatch: /stream/
Questo esempio include esplicitamente la barra finale nella regola di corrispondenza:
- Richiesta per
media.example.com/stream/id/1234/hls/manifest.m3u8
corrispondenze su questo percorso. - Una richiesta a
media.example.com/stream-eu/id/4567/hls/manifest.m3u8
non corrisponde a questo percorso.
Nel secondo caso, Media CDN restituisce un errore HTTP 404
,
a meno che non ci fosse un altro percorso o un percorso completo
configurato.
Per indicazioni su come funziona la precedenza per le route con prefissi simili, consulta la sezione Ordinamento e priorità route.
Corrispondenza di pattern (con caratteri jolly)
La corrispondenza dei pattern consente di abbinare più parti di un URL, compresi gli URL parziali e i suffissi (estensioni dei file), utilizzando la sintassi dei caratteri jolly.
Puoi anche associare uno o più componenti del percorso a variabili denominate in un
pathTemplateMatch
campo e poi fare riferimento a queste variabili durante la riscrittura dell'URL in
un campo pathTemplateRewrite
. In questo modo puoi riordinare e rimuovere i componenti dell'URL prima che la richiesta venga inviata all'origine.
L'esempio seguente mostra come puoi trovare una corrispondenza su due diversi suffissi URL:
# EdgeCacheService.routing.pathMatchers[] routeRules: - priority: 1 description: "Match video segments" matchRules: - pathTemplateMatch: "/**.ts" - pathTemplateMatch: "/**.m4s" origin: prod-video-storage
La sintassi supportata include quanto segue.
Operatore | Corrisponde a | Esempio |
---|---|---|
*
|
Corrisponde a un singolo componente del percorso, fino al separatore di percorso successivo: /
|
/videos/*/*/*.m4s corrispondenze
/videos/123414/hls/1080p5000_00001.m4s .
|
**
|
Corrisponde a zero o più segmenti di percorso. Se presente, deve essere l'ultimo operatore. |
/**.mpd corrispondenze
/content/123/india/dash/55/manifest.mpd .
|
{name} or {name=*}
|
Una variabile denominata corrispondente a un segmento di percorso.
Corrisponde a un singolo componente del percorso, fino al separatore di percorso successivo:
|
/content/{format}/{lang}/{id}/{file}.vtt corrisponde a
/content/hls/en-us/12345/en_193913.vtt e acquisisce
format="hls" , lang="en-us" , id="12345"
e file="en_193913" come variabili.
|
{name=videos/*}
|
Una variabile denominata che corrisponde a più di un segmento di percorso. Il componente del percorso
videos/* corrispondente viene acquisito come variabile denominata.
|
/videos/{language=lang/*}/* corrisponde
/videos/lang/en/video.m4s e compila la variabile di percorso
language con il valore lang/en .
|
{name=**}
|
Una variabile denominata che corrisponde a zero o più segmenti di percorso. Se presente, deve essere l'ultimo operatore. |
|
Note:
- Se non stai riscrivendo un URL, utilizza gli operatori
*
e**
più semplici. - Quando utilizzi le variabili per acquisire i componenti del percorso, le parti dell'URL che non vengono acquisite da una variabile non possono essere richiamate in un
pathTemplateRewrite
successivo. Per un esempio, consulta la sezione relativa alla acquisizione delle variabili di percorso. - Non puoi fare riferimento a variabili in un
pathTemplateRewrite
successivo che non esistono nelpathTemplateMatch
nello stesso percorso. - Le variabili sono sensibili alle maiuscole, con
{FORMAT}
,{forMAT}
e{format}
che rappresentano variabili e valori diversi. - Puoi specificare fino a 10 operatori (caratteri jolly o variabili) in una corrispondenza.
I campi
pathTemplateMatch
epathTemplateRewrite
non devono superare i 255 caratteri.
Esempio: corrispondenza per estensione del file
L'esempio seguente mostra un caso d'uso comune per gli operatori di caratteri jolly: corrispondenza di tutti i componenti del percorso fino a un suffisso.
In questo caso, segui questi passaggi:
- Recupera i manifest video (playlist) che terminano con
.m3u8
e.mpd
dal manifest, applicando un breve TTL di 5 secondi a queste risposte cambiano con regolarità. - Recupera i segmenti video che terminano con
.ts
e.m4s
dall'origine del segmento e applicare un TTL più lungo (1 giorno) a queste risposte.
Questo approccio viene spesso utilizzato quando si utilizza SSAI (Server-Side Ad Injection) DAI (inserimento di annunci dinamici) e per i video live in cui il file manifest è vengono aggiornate a intervalli di alcuni secondi.
La seguente configurazione mostra come configurare il routing Media CDN per supportare questa funzionalità:
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: # the first route only matches video manifests - priority: 1 matchRules: - pathTemplateMatch: "/**.m3u8" # "**" matches all path segments - pathTemplateMatch: "/**.mpd" origin: manifest-origin routeAction: cdnPolicy: cacheMode: FORCE_CACHE_ALL defaultTtl: 5s # the second route matches video segments, fetches them # from a separate origin server, caching them for a longer # duration (1 day). - priority: 2 matchRules: - pathTemplateMatch: "/**.ts" - pathTemplateMatch: "/**.m4s" origin: segment-origin routeAction: cdnPolicy: cacheMode: FORCE_CACHE_ALL defaultTtl: 86400s
Esempio: acquisire le variabili di percorso
L'esempio seguente mostra come utilizzare le variabili con nome per descrivere una o più componenti del percorso di conversione.
Queste variabili possono essere utilizzate in un pathTemplateRewrite
per riscrivere il percorso precedente
alla richiesta inviata all'origine, oppure per fare in modo che
Autodescrittivo: pathTemplateMatch
.
routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 matchRules: # Matches a request of "/us/en/hls/123139139/segments/00001.ts" - pathTemplateMatch: "/{country}/{lang}/{format}/{id}/{file=**}" origin: my-origin routeAction: urlRewrite: # Rewrites to "/123139139/hls/segments/00001.ts" pathTemplateRewrite: "/{id}/{format}/{file}"
In particolare:
- Ogni variabile
{name}
acquisisce un singolo segmento di percorso. Un segmento di percorso è costituito da tutti i caratteri tra una coppia di/
("barre") in un percorso dell'URL. - Una variabile
{name=**}
acquisisce tutti i segmenti del percorso rimanenti. in questo maiuscole/minuscole, corrisponde sia asegments/00001.ts
sia amaster.m3u8
. - In
pathTemplateRewrite
sulla stessa strada, fai riferimento a alcune delle variabili acquisite inpathTemplateMatch
. In modo esplicito ometti le variabili{country}
e{lang}
perché non corrispondono alle struttura di directory sull'origine.
In questo esempio si verifica quanto segue:
- Un URL richiesta in entrata di
/us/en/hls/123139139/segment_00001.ts
corrisponde apathTemplateMatch
ed è riscritto in/123139139/hls/segment_00001.ts
prima di essere inviato all'origine. - Un URL di richiesta in entrata
/us/123139139/master.m3u8
non corrisponde allapathTemplateMatch
e riceve una risposta HTTP404 (Not Found)
. - Un URL di richiesta in arrivo di
/br/es/dash/c966cbbe6ae3/subtitle_00001.vtt
corrisponde anche apathTemplateMatch
e viene riscritto in/c966cbbe6ae3/dash/subtitle_00001.vtt
prima di essere inviato all'origine.
Per scoprire di più su come la corrispondenza con caratteri jolly interagisce con la riscrittura degli URL, consulta: nella sezione rewrite.
Corrispondenza host
Ogni servizio può corrispondere a più nomi host, con ogni insieme di nomi host contenenti il proprio gruppo di route (note come matcher di percorso). Nel caso più comune, tutti i nomi host per un servizio sono mappati a un singolo insieme di route condivise con un di host e un matcher di percorso singolo.
name: prod-service routing: hostRules: - hosts: - media.example.com - *.vod.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: # list of routes for the configured hosts - priority: 999 matchRules: - prefixMatch: / origin: DEFAULT_ORIGIN
Agli host che non corrispondono viene mostrata una pagina HTTP 404
predefinita. Per accettare qualsiasi host,
puoi includere il carattere jolly *
come voce hostRules[].hosts[]
.
Puoi anche definire gruppi di percorsi (ad esempio raggruppandoli per paese o per contenuti dal vivo/su richiesta). Poiché ogni servizio ha un unico criterio di sicurezza, in genere consigliamo di avere un servizio per ogni mercato (geografia) o carico di lavoro.
Note:
- Le intestazioni host (o HTTP/2
:authority
) che contengono una porta sono implicitamente confrontato con un host configurato. Non è necessario specificare esplicitamente le porte. - Se la richiesta avviene tramite HTTP, una voce
hostRules[].hosts[]
di*.vod.example.com
corrisponde aus.vod.example.com
eus.vod.example.com:80
. - Se la richiesta avviene tramite HTTPS (TLS), una voce
hostRules[].hosts[]
di*.vod.example.com
corrisponde aus.vod.example.com:443
.
Per ulteriori dettagli, consulta la specifica API per
HostRule
Trova corrispondenze in base a intestazioni e parametri di ricerca
Puoi configurare i percorsi in modo che corrispondano a nomi di intestazioni e parametri di query specifici, nonché alla presenza di un valore dell'intestazione (prefisso, suffisso o corrispondenza esatta).
La corrispondenza dei parametri di query e delle intestazioni è un "AND" logico: la richiesta deve corrispondere a tutti i parametri di query e alle chiavi (e ai valori, se specificati) delle intestazioni per corrispondere al percorso specificato.
Ad esempio, se vuoi inoltrare le richieste con un nome e un valore di campo dell'intestazione specifici a un'origine denominata alternate-origin
, configura le condizioni di corrispondenza in routeRules[].matchRules[].headerMatches[]
:
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 origin: alternate-origin matchRules: - prefixMatch: "/videos/" headerMatches: - headerName: "x-device-name" exactMatch: "roku"
In questo esempio, le richieste con /videos/
all'inizio dell'URL e l'intestazione x-device-name: roku
corrispondono a questo percorso. Le richieste che non contengono questo nome di intestazione o che hanno un valore diverso non corrispondono a questo percorso.
Per ulteriori dettagli, consulta la specifica dell'API per
HeaderMatch
.
Analogamente, per la corrispondenza con i parametri di query, specifica uno o più
queryParameterMatches
come segue:
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 origin: eu-live-origin-prod matchRules: - prefixMatch: "/videos/" queryParameterMatches: - name: "playback_type" exactMatch: "live" - name: "geo" exactMatch: "eu"
In questo esempio, una richiesta del client
https://cdn.example.com/videos/1234/abcd/xyz.m3u8?playback_type=live&geo=eu
corrisponde a questo percorso.
Per ulteriori dettagli, consulta la specifica dell'API per
QueryParameterMatcher
.
Definire un percorso catch-all (predefinito)
Per impostazione predefinita, Media CDN restituisce un errore HTTP 404 (Not Found)
se una richiesta
non corrisponde a nessuno dei route configurati.
Per configurare una route catch-all, per un determinato pathMatcher
(raccolta di
route), procedi nel seguente modo:
- Crea un
routeRule
con la priorità più bassa (numero più alto), ad esempio 999, che è la priorità del route più bassa possibile. - Configura
matchRule
con una corrispondenza del prefisso di/
(corrisponde a tutte le richieste percorsi di addestramento). - Configura (uno di) un
origin
o unurlRedirect
sul percorso.
Ad esempio, per configurare una route catch-all che indirizza tutte le richieste senza corrispondenza
a un'origine predefinita denominata my-origin
, crea una nuova route con priority: 999
e un matchRules[].prefixMatch
di /
come segue:
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 999 origin: my-origin matchRules: - prefixMatch: /
Se vuoi, puoi riscrivere l'URL prima del recupero dell'origine o reindirizzare a una pagina predefinita (ad esempio la pagina di destinazione) anziché inviare la richiesta "così com'è" all'origine.
Ordinamento e priorità route
Ogni percorso in un array di routeRules[]
deve avere un priority
associato.
Le route più specifiche devono essere impostate su una priorità più alta (numero inferiore). R
una route corrispondente a un prefisso di /stream/
con priorità 1 impedisce che venga
percorso più specifico di /stream/live/eu/
con una priorità pari a 5 rispetto a qualsiasi
richieste.
- La route con priorità più alta è "1" e quella più bassa è "999".
- Non puoi configurare due o più routeRules con la stessa priorità. Priorità di ogni regola deve essere impostato su un numero compreso tra 1 e 999 inclusi.
- La definizione di un percorso completo consente di inviare tutte richieste non corrispondenti a un'origine o un reindirizzamento predefinita a una pagina di destinazione o a un endpoint.
Nell'esempio seguente, puoi vedere che il percorso /live/us/
non sarà mai
corrisponde perché la route /live/
ha una priorità più alta:
routeRules: - priority: 1 description: "Live routes" matchRules: - prefixMatch: /live/ routeAction: cdnPolicy: defaultTtl: 5s - priority: 2 description: "U.S based live streams" matchRules: # This would never be matched, as the /live/ prefixMatch at priority 1 # would always take precedence. - prefixMatch: /live/us/ routeAction: cdnPolicy: defaultTtl: 5s - priority: 999 description: "Catch-all route" matchRules: - prefixMatch: /
Per risolvere il problema, assegna una priorità più alta al percorso più specifico (più lungo):
routeRules: - priority: 1 description: "U.S based live streams" matchRules: # The more specific (longer) match is at a higher priority, and now # matches requests as expected. - prefixMatch: /live/us/ routeAction: cdnPolicy: defaultTtl: 5s - priority: 2 description: "Live routes" matchRules: - prefixMatch: /live/ routeAction: cdnPolicy: defaultTtl: 5s - priority: 999 description: "Catch-all route" matchRules: - prefixMatch: /
In questo modo, il percorso più specifico può corrispondere correttamente alle richieste. Una richiesta
preceduto da /live/eu/
ricadrà comunque sul percorso /live/
in
priorità 2.
Filtro del metodo
Per impostazione predefinita, Media CDN esegue il proxy solo per GET
, HEAD
e OPTIONS
alla tua origine e filtra i metodi che possono modificare la tua origine.
Puoi ignorare questo comportamento predefinito per una regola di route specifica specificando
i metodi di cui vuoi eseguire il proxy per l'origine. Oltre a GET
, HEAD
e
OPTIONS
, Media CDN supporta PUT
, POST
, DELETE
e
PATCH
.
Per configurare il supporto di una serie di metodi per una regola di route, specifica un
Sezione routeMethods
che ha un valore allowed_methods
per ogni metodo.
routeRules: - priority: 5 description: "Video uploads" routeMethods: allowedMethods: ["PUT", "POST", "OPTIONS"] matchRules: - pathTemplateMatch: "/uploads/**.ts" origin: prod-video-storage - priority: 10 description: "Video serving" routeMethods: allowedMethods: ["GET", "HEAD"] matchRules: - pathTemplateMatch: "/videos/**.ts" origin: prod-video-storage
Normalizzazione del percorso
La normalizzazione dei percorsi descrive in che modo Media CDN combina più di un URL in un'unica rappresentazione canonica in base a diversi scenari.
La normalizzazione dei percorsi può migliorare direttamente le percentuali di successo della cache riducendo il numero di URL delle richieste che rappresentano gli stessi contenuti e mitigando gli errori relativi all'origine per le origini che prevedono percorsi normalizzati.
Le richieste in arrivo vengono normalizzate come segue:
- Più barre consecutive vengono unite in un'unica barra. Ad esempio, un
Il percorso dell'URL di
/videos///12345/manifest.mpd
è normalizzato in/videos/12345/manifest.mpd
. - I segmenti del percorso sono normalizzati in base
RFC 3986 Sezione 6.2.2.3.
Ad esempio, il percorso
/a/b/c/./../../g
viene normalizzato in/a/g
in base all'algoritmo "rimuovi segmenti con puntini" definito in RFC 3986. Questa normalizzazione avviene prima del controllo della cache o dell'inoltro della richiesta all'origine. - Le richieste non presentano una codifica percentuale normalizzata. Ad esempio, un URL con un carattere barra codificato in percentuale (
%2F
) non viene decodificato nella forma non codificata.
Gli URL fanno distinzione tra maiuscole e minuscole e non vengono normalizzati tra maiuscole e minuscole. Molti URL contengono codifiche Base64 sensibili alle maiuscole, inclusi gli URL con di richieste firmate.
Riscritture e reindirizzamenti
Le sezioni seguenti forniscono esempi su come riscrivere le richieste e configurare i reindirizzamenti.
Riscrivere gli URL delle richieste
Media CDN supporta le riscritture di host e percorso. Le riscritture modificano l'URL inviato all'origine e ti consentono di modificare gli host e i percorsi in base alle tue esigenze. Le riscritture dell'host e del percorso si trovano a livello di route e ti consentono di definire quali richieste specifiche devono essere riscritte in base a qualsiasi comparatore, tra cui percorso, parametro di query e intestazione della richiesta.
Per ulteriori dettagli, consulta la specifica dell'API per
RouteAction.UrlRewrite
.
Di seguito sono riportati tre modi per riscrivere una richiesta:
Campo | Descrizione |
---|---|
urlRewrite.pathPrefixRewrite
|
Riscrive il percorso, rimuovendo il prefisso specificato nel
In una singola regola del percorso è possibile specificare solo uno tra |
urlRewrite.pathTemplateRewrite
|
Solo uno tra |
urlRewrite.hostRewrite
|
Riscrive l'host prima che la richiesta venga inviata al server di origine. |
Note:
- Gli URL riscritti non modificano la chiave della cache. La chiave della cache si basa sull'URL della richiesta inviato dal client.
- La riscrittura avviene dopo la corrispondenza della route e la convalida della richiesta firmata. Route non vengono corrispondenti nuovamente a un'altra regola di corrispondenza.
Esempio: rimuovere un prefisso di percorso
Ad esempio, per riscrivere un URL di richiesta del client da /vod/videos/hls/1234/abc.ts
a
/videos/hls/1234/abc.ts
(rimuovendo /vod
dal percorso), puoi usare lo
Funzionalità pathPrefixRewrite
:
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 origin: my-origin matchRules: - prefixMatch: "/vod/videos/" routeAction: urlRewrite: pathPrefixRewrite: "/videos/"
Un pathPrefixRewrite
sostituisce l'intero componente del percorso corrispondente
matchRules[].prefixMatch
con il valore pathPrefixRewrite
.
Per riscrivere un nome host (ad esempio cdn.example.com
in
my-bucket.s3.us-west-2.amazonaws.com
), puoi configurare quanto segue:
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 origin: my-origin matchRules: - prefixMatch: "/videos/" routeAction: urlRewrite: hostRewrite: "my-bucket.s3.us-west-2.amazonaws.com"
In questo caso, l'URL della richiesta di origine cambierà da
Da cdn.example.com/videos/*
a my-bucket.s3.us-west-2.amazonaws.com/videos/*
.
Puoi anche combinare le riscritture dell'host e del percorso in un'unica route.
Esempio: utilizzare le variabili per riscrivere gli URL
Per utilizzare pathTemplateMatch
e pathTemplateRewrite
per riscrivere parti di un
URL richiesta in entrata, consulta le variabili di acquisizione
.
Richieste di reindirizzamento
Media CDN supporta tre tipi di reindirizzamenti:
- Reindirizzamenti dell'host, che reindirizzano solo l'host (dominio), mantenendo invariati il percorso e i parametri di query.
- Reindirizzamenti di percorso, che sostituiscono il percorso per intero.
- I reindirizzamenti dei prefissi dei percorsi, che sostituiscono solo il prefisso corrispondente.
Reindirizza per impostazione predefinita a HTTP 301 (Moved Permanently)
, ma può essere configurato per
restituiscono codici di stato del reindirizzamento diversi per ogni percorso.
La seguente configurazione è un esempio di reindirizzamento basato su prefisso,
in cui reindirizzi gli utenti che visitano https://cdn.example.com/on-demand/*
a
https://cdn.example.com/streaming/*
.
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 10 matchRules: - prefixMatch: "/on-demand/" urlRedirect: # The prefix matched in matchRules.prefixMatch is replaced # by this value prefixRedirect: "/streaming/" redirectResponseCode: TEMPORARY_REDIRECT # corresponds to a HTTP 307
Questo esempio modifica anche il reindirizzamento in un reindirizzamento temporaneo, che impedisce ai client (ad esempio i browser) di memorizzarlo nella cache. Questo può essere utile se prevedi di lo cambieremo nel prossimo futuro.
I valori redirectResponseCode
supportati sono riportati nella tabella seguente.
Codice di risposta reindirizzamento | Codice di stato HTTP |
---|---|
MOVED_PERMANENTLY_DEFAULT |
HTTP 301 (spostato in modo permanente) |
FOUND |
HTTP 302 (trovato) |
SEE_OTHER |
HTTP 303 (vedi altro) |
TEMPORARY_REDIRECT |
HTTP 307 (reindirizzamento temporaneo) |
PERMANENT_REDIRECT |
HTTP 308 (Reindirizzamento permanente) |
Note:
- Un percorso può indirizzare il traffico a un'origine o restituire un reindirizzamento al
client. Non puoi impostare sia
origin
siaurlRedirect
campi contemporaneamente. - I percorsi che reindirizzano a HTTPS richiedono che al servizio sia associato almeno un certificato SSL.
Per ulteriori dettagli, consulta la specifica API per
RouteRule.UrlRedirect
Reindirizza tutte le richieste a HTTPS
Per reindirizzare tutte le richieste a HTTPS (anziché a HTTP), puoi configurare ciascuno dei tuoi servizi in modo che reindirizzi automaticamente tutte le richieste dei client a HTTPS. Ai client che si connettono tramite HTTP viene inviata una risposta 301 (Permanent Redirect)
HTTP con l'intestazione Location
impostata sullo stesso URL utilizzando "https://" anziché "http://".
gcloud
gcloud edge-cache services update MY_SERVICE \ --require-tls
Request issued for: [MY_SERVICE] Updated service [MY_SERVICE].
Il comando restituisce una descrizione del servizio. Ora è impostato requireTls
a true
.
name: MY_SERVICE requireTls: true
Puoi anche scegliere di impostare Rigorosa sicurezza per i trasporti come intestazione della risposta per indirizzare i clienti a connettersi sempre direttamente HTTPS.
Usa backend di archiviazione di terze parti
Media CDN supporta la connessione a endpoint HTTP accessibili pubblicamente esterni a Google Cloud, inclusi i bucket di archiviazione AWS S3, Azure Blob Storage e altri provider di archiviazione. Questa operazione può essere utile se hai un'architettura multicloud o se non hai ancora eseguito la migrazione dei dati in Cloud Storage utilizzando Storage Transfer Service.
Una configurazione dell'origine minima che configura un bucket ospitato virtuale in AWS S3:
name: MY_S3_ORIGIN originAddress: BUCKET-NAME.s3.REGION.amazonaws.com
Se non utilizzi un nome bucket che corrisponde ai nomi host configurati per
EdgeCacheService
risorse, devi anche configurare una riscrittura dell'host per le route
associati a questa o a queste origini. In caso contrario, l'intestazione Host impostata dalla richiesta del cliente viene utilizzata durante il recupero dall'origine.
Ad esempio, per mappare tutte le richieste con il prefisso del percorso /legacy/
alla tua
un bucket esterno, puoi configurare un hostRewrite
e un
pathPrefixRewrite
per rimuovere questo prefisso dalla richiesta di origine:
routeRules: - description: legacy backend matchRules: - prefixMatch: "/legacy/" routeAction: urlRewrite: hostRewrite: BUCKET-NAME.s3.REGION.amazonaws.com pathPrefixRewrite: / cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 3600s
Per ulteriori informazioni su come viene impostata l'intestazione host sulle richieste di origine, vedi le intestazioni della richiesta di origine documentazione.
Condivisione delle risorse tra origini (CORS)
La condivisione delle risorse tra origini (CORS) è un approccio incentrato sul browser per effettuare in sicurezza richieste cross-origin.
I criteri CORS consentono di impostare automaticamente le intestazioni CORS, ad esempio
Access-Control-Allow-Origins
, in base a un criterio di singola route.
Configura CORS
Media CDN ti consente di definire un criterio CORS su una route per un
EdgeCacheService
.
Un criterio CORS definisce queste regole con un insieme comune di intestazioni HTTP. Puoi
Impostare intestazioni CORS comuni nelle risposte, come
Access-Control-Allow-Origin
, Access-Control-Max-Age
,
e Access-Control-Allow-Headers
. Queste intestazioni ti consentono di effettuare chiamate cross-origin ai tuoi servizi Media CDN che potrebbero essere ospitati su un dominio (origine) diverso dal frontend del tuo sito web e potrebbero impedire le richieste cross-origin che non consenti esplicitamente.
Ad esempio, player.example.com
e api.example.com
sono origini diverse
(nel senso del browser) e potresti volere che la tua applicazione frontend
effettui richieste a api.example.com
per recuperare la playlist successiva o aggiornare una
elencazione di contenuti correlati. Analogamente, player.example.com
potrebbe dover contattare cdn.example.com
per recuperare le playlist e i segmenti video:cdn.example.com
deve indicare che è tutto a posto e cheplayer.example.com
è un allowed origin
, nonché eventuali altre regole
(intestazioni consentite, possibilità di includere i cookie).
Per fare un altro esempio, se vuoi consentire stream.example.com
come origine
e un'intestazione X-Client-ID
nelle richieste CORS, puoi configurare un corsPolicy
su una
come segue:
corsPolicy: maxAge: 600 allowOrigins: ["stream.example.com"] allowHeaders: ["X-Client-ID"]
Un corsPolicy
è configurato in
routing.pathMatchers[].routeRules[].routeAction.corsPolicy
in un
EdgeCacheService. Ogni routeRule
può definire un corsPolicy
diverso in base alle esigenze o non definirne nessuno.
Se definisci un valore corsPolicy
e imposti anche un'intestazione di risposta personalizzata utilizzando i campi corsPolicy
in un percorso con lo stesso nome, l'intestazione di risposta personalizzata ha la precedenza sul valore corsPolicy
e viene utilizzata al suo posto.
Se la risposta dell'origine imposta intestazioni HTTP e hai impostato un valore corsPolicy
, vengono utilizzati i valori corsPolicy
. I valori non vengono compressi
o combinati per evitare di inviare valori di intestazione non validi a un client o
di impostare involontariamente un criterio più permissivo del previsto.
Il valore speciale {origin_request_header}
viene compilato con l'intestazione HTTP Origin
nella richiesta del client. Può essere impostato come valore di intestazione della risposta personalizzata su un
per l'intestazione Access-Control-Allow-Origin
.
Per ulteriori dettagli, consulta l'API
specifiche per
RouteAction.CORSPolicy
Campi dei criteri CORS
La tabella seguente descrive i campi contenuti in un criterio CORS.
Campo | Descrizione | Esempio |
---|---|---|
allowOrigins |
Imposta l'intestazione della risposta
Ad esempio, se i tuoi contenuti video vengono pubblicati da
|
Access-Control-Allow-Origins: https://stream.example.com
|
maxAge |
Imposta l'intestazione di risposta Alcuni browser limitano questo tempo a 2 ore o meno, anche se viene specificato il valore massimo (86.400 s). |
Access-Control-Max-Age: 7200
|
allowMethods |
Imposta l'intestazione della risposta Per impostazione predefinita, Media CDN supporta solo i metodi |
Access-Control-Allow-Methods: GET, OPTIONS, HEAD
|
allowHeaders |
Imposta l'intestazione Questa operazione è spesso richiesta dai video player, che devono accedere ad alcune intestazioni delle risposte per i contenuti video quando vengono richiesti multiorigine. |
Access-Control-Allow-Headers: Content-Type, If-Modified-Since,
Range, User-Agent
|
exposeHeaders |
Imposta l'intestazione della risposta Questo è spesso richiesto dai video player, che potrebbero dover accedere a intestazioni di risposta specifiche per i contenuti video quando richiedono contenuti cross-origin. |
Access-Control-Expose-Headers: Date, Cache-Status, Content-Type,
Content-Length
|
allowCredentials |
Imposta l'intestazione della risposta Questa intestazione viene omessa se impostata su false. |
Access-Control-Allow-Credentials: true
|
disabled |
Disattiva corsPolicy senza rimuoverlo. Prima del periodo di pubblicazione
OPTIONS richieste sono inviate tramite proxy all'origine.
|
N/D |
Esempio di corsPolicy
L'esempio di configurazione seguente mostra una configurazione di base di corsPolicy
:
routeRules: - priority: 1 matchRules: - prefixMatch: /stream/ routeAction: cdnPolicy: defaultTtl: 3600s corsPolicy: allowOrigins: - "https://stream.example.com" - "https://stream-staging.example.com" maxAge: 86400s # some browsers might only honor up to 7200s or less allowMethods: - "GET" - "HEAD" - "OPTIONS" allowHeaders: - "Content-Type" - "If-Modified-Since" - "Range" - "User-Agent" exposeHeaders: - "Content-Type" - "Content-Length" - "Date"
Risolvere i problemi relativi al routing
Se alcune richieste non recuperano i risultati corrispondenti o restituiscono errori, controlla la seguenti:
- Un percorso deve avere un
matchRule
con esattamente uno dei valoriprefixMatch
,fullPathMatch
opathTemplateMatch
definito. L'API restituisce un errore se uno di questi campi. - Assicurati che il campo
priority
di ogni route sia impostato correttamente: alle route più specifiche (più lunghe) deve essere assegnata una priorità più alta rispetto alle corrispondenze di route più brevi e più ampie. - Per impostazione predefinita, sono supportate solo le richieste
GET
,HEAD
eOPTIONS
. Per configurare il supporto per altri metodi, vedi Metodi di routing. I metodi non abilitati per un determinato route vengono rifiutati con un errore HTTP405 (Method Not Allowed)
. - Le richieste
GET
HTTP con un corpo o qualsiasi richiesta con trailer vengono rifiutate con un errore HTTP400
, perché il corpo delle richieste non è consentito inGET
richieste. - La corrispondenza del parametro di query e dell'intestazione è un "AND" logico: la richiesta deve corrispondere a tutte le chiavi (e ai valori, se specificati) del parametro di query o dell'intestazione per corrispondere al percorso specificato.
Passaggi successivi
- Consulta la documentazione sulla configurazione della memorizzazione nella cache.
- Scopri come connetterti a origini diverse.
- Configurare i certificati TLS (SSL) per il tuo completamente gestito di Google Cloud.
- Configura le richieste firmate per autenticare l'accesso ai contenuti.