Media CDN offre funzionalità di routing HTTP avanzate che consentono di mappare il traffico a configurazioni perimetrali e origini specifiche a un livello granulare.
Richieste di corrispondenza
Una configurazione Media CDN contiene un insieme di route definite nella sezione Routing per una risorsa EdgeCacheService
.
Queste route associano le richieste in base (almeno) a un host. Per maggiori dettagli su come
il traffico viene indirizzato a un'origine, consulta
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 criterio di memorizzazione nella 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 instradare le richieste che corrispondono a un'intestazione, a un parametro di query e a un prefisso di percorso specifici 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 percorso con caratteri jolly. La corrispondenza dei percorsi può essere combinata con la corrispondenza basata su host, intestazione e parametri di query per creare regole granulari di routing delle richieste.
Di seguito sono riportati tre modi per trovare una corrispondenza con un percorso 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 finali, se pertinenti.
|
Una route con regola di corrispondenza Un |
matchRules[].prefixMatch
|
La condizione prefixMatch corrisponde al prefisso del percorso dell'URL; gli URL che iniziano con la stessa stringa corrispondono.
|
Una route con una regola di corrispondenza |
matchRules[].pathTemplateMatch
|
La condizione pathTemplateMatch supporta operatori con caratteri jolly, che ti consentono di abbinare pattern URL e segmenti di percorso complessi, nonché acquisire variabili con nome per la riscrittura degli URL.
|
Una route con una regola di corrispondenza Sia Per altri esempi, consulta la sezione corrispondenza dei pattern. |
Per maggiori dettagli, consulta la specifica API per MatchRule
.
Ad esempio, per trovare corrispondenze di tutte le richieste che iniziano con /stream/
, crea una regola di route 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:
- Una richiesta a
media.example.com/stream/id/1234/hls/manifest.m3u8
corrisponde a questo percorso. - Una richiesta indirizzata a
media.example.com/stream-eu/id/4567/hls/manifest.m3u8
non corrisponde a questa route.
Nel secondo caso, Media CDN restituisce un errore HTTP 404
, a meno che non sia stata configurata un'altra route o una route cartch-all.
Per indicazioni su come funziona la predecenza per le route con prefissi simili, consulta la sezione Priorità e ordinamento delle route.
Corrispondenza di pattern (con caratteri jolly)
La corrispondenza dei pattern consente di abbinare più parti di un URL, inclusi URL parziali ed estensioni dei file, mediante la sintassi con caratteri jolly.
Puoi anche associare uno o più componenti del percorso a variabili denominate in un campo pathTemplateMatch
per poi fare riferimento a queste variabili quando riscrivi l'URL in un campo pathTemplateRewrite
. In questo modo puoi riordinare e rimuovere i componenti dell'URL prima che la richiesta venga inviata alla tua origine.
L'esempio seguente mostra come trovare corrispondenze per due suffissi URL diversi:
# 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 corrisponde a
/videos/123414/hls/1080p5000_00001.m4s .
|
**
|
Corrisponde a zero o più segmenti di percorso. Se presente, deve essere l'ultimo operatore. |
/**.mpd corrisponde a
/content/123/india/dash/55/manifest.mpd .
|
{name} or {name=*}
|
Una variabile denominata corrispondente a un segmento del 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 che corrisponde a videos/* viene acquisito come variabile denominata.
|
/videos/{language=lang/*}/* corrisponde a
/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 i più semplici operatori
*
e**
. - Quando utilizzi le variabili per acquisire i componenti del percorso, le parti dell'URL che non vengono acquisite da una variabile non possono essere utilizzate come riferimento in un elemento
pathTemplateRewrite
successivo. Per un esempio, consulta la sezione Acquisizione delle variabili del percorso. - Non puoi fare riferimento a variabili in un elemento
pathTemplateRewrite
successivo che non esistono inpathTemplateMatch
sulla stessa route. - Le variabili sono sensibili alle maiuscole.
{FORMAT}
,{forMAT}
e{format}
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 in base a un'estensione del file
L'esempio seguente mostra un caso d'uso comune per gli operatori con caratteri jolly: corrispondenza di tutti i componenti del percorso fino a un suffisso.
In questo caso, segui questi passaggi:
- Recupera i file manifest video (playlist) che terminano con
.m3u8
e.mpd
dall'origine manifest, applicando un TTL breve (5 secondi) a queste risposte perché cambiano regolarmente. - Recupera i segmenti video che terminano con
.ts
e.m4s
dall'origine del segmento e applica un TTL più lungo (1 giorno) a queste risposte.
Questo approccio viene spesso utilizzato quando si utilizzano servizi SSAI (Server-Side Ad Injection) o DAI (inserimento di annunci dinamici) e per i video dal vivo in cui il manifest viene aggiornato a intervalli di pochi secondi.
La configurazione seguente illustra come configurare il routing di Media CDN in modo da supportare questa operazione:
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 uno o più componenti del percorso.
Queste variabili possono essere utilizzate in un pathTemplateRewrite
per riscrivere il percorso prima
che la richiesta venga inviata all'origine o per creare una pathTemplateMatch
complicata con una descrizione autonoma.
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 del 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 caso, corrisponde sia asegments/00001.ts
sia amaster.m3u8
. - Nella
pathTemplateRewrite
sulla stessa route, fai riferimento ad alcune delle variabili acquisite nellapathTemplateMatch
. Ometti esplicitamente le variabili{country}
e{lang}
perché non corrispondono alla struttura di directory nell'origine.
In questo esempio si verifica quanto segue:
- Un URL di richiesta in entrata
/us/en/hls/123139139/segment_00001.ts
corrisponde apathTemplateMatch
e viene 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 apathTemplateMatch
e riceve una risposta404 (Not Found)
HTTP. - Anche un URL di richiesta in entrata
/br/es/dash/c966cbbe6ae3/subtitle_00001.vtt
corrisponde 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 la sezione relativa alle riscritture.
Corrispondenza host
Ogni servizio può trovare corrispondenze su più nomi host, ognuno dei quali contiene il proprio gruppo di route (i cosiddetti matcher di percorso). Nel caso più comune, tutti i nomi host di un servizio sono mappati a un singolo insieme di route condivise con un singolo elenco di host e un singolo matcher di percorso.
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
Per gli 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 route (ad esempio, raggruppamento per paese o dal vivo rispetto a on demand). Poiché ogni servizio ha un unico criterio di sicurezza, generalmente consigliamo di avere un servizio per ogni mercato (area geografica) o carico di lavoro di cui disponi.
Note
- Le intestazioni host (o HTTP/2
:authority
) che contengono una porta vengono implicitamente abbinate a un host configurato. Non devi specificare esplicitamente le porte. - Se la richiesta è tramite HTTP, la voce
hostRules[].hosts[]
di*.vod.example.com
corrisponde aus.vod.example.com
eus.vod.example.com:80
. - Se la richiesta è tramite HTTPS (TLS), una voce
hostRules[].hosts[]
di*.vod.example.com
corrisponde aus.vod.example.com:443
.
Per maggiori dettagli, consulta la specifica API per HostRule
.
Trova corrispondenze in base a intestazioni e parametri di ricerca
Puoi configurare le route in modo che corrispondano a nomi specifici di intestazioni e parametri di query, nonché la presenza di un valore dell'intestazione (prefisso, suffisso o corrispondenza esatta).
La corrispondenza dei parametri di query e delle intestazioni è un tipo logico di tipo "AND", ovvero la richiesta deve corrispondere a tutti i parametri di ricerca e a tutte le chiavi di intestazione (e ai valori, se specificati) per corrispondere alla route specificata.
Ad esempio, se vuoi instradare le richieste con un nome di campo di intestazione e un valore di 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 dell'intestazione x-device-name: roku
corrispondono a questa route. Le richieste senza questo nome di intestazione
o con un valore diverso non corrispondono a questa route.
Per maggiori dettagli, consulta la specifica API per HeaderMatch
.
Analogamente, per trovare una corrispondenza con parametri di ricerca, 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 di https://cdn.example.com/videos/1234/abcd/xyz.m3u8?playback_type=live&geo=eu
corrisponde a questa route.
Per maggiori dettagli, consulta la specifica API per QueryParameterMatcher
.
Definisci una route catch-all (predefinita)
Per impostazione predefinita, Media CDN restituisce un errore HTTP 404 (Not Found)
se una richiesta non corrisponde a nessuna route configurata.
Per configurare una route catch-all, per un determinato pathMatcher
(raccolta di
route), segui questi passaggi:
- Crea un
routeRule
con la priorità più bassa (numero più alto), ad esempio 999, che è la priorità di route più bassa possibile. - Configura un
matchRule
con una corrispondenza del prefisso pari a/
(corrisponde a tutti i percorsi di richiesta). - Configura (uno di) un
origin
ourlRedirect
lungo il 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 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: /
Facoltativamente, puoi riscrivere l'URL prima del recupero dell'origine o reindirizzare a una pagina predefinita (ad esempio la tua pagina di destinazione) anziché inviare la richiesta "così com'è" all'origine.
Ordinamento e priorità route
A ogni route in un array di routeRules[]
deve essere associato un priority
.
Le route più specifiche dovrebbero essere impostate su una priorità più alta (numero più piccolo). Una route che corrisponde a un prefisso di /stream/
con priorità 1 impedisce a una route più specifica di /stream/live/eu/
con priorità 5 di soddisfare qualsiasi richiesta.
- La route con priorità più alta è "1" e quella più bassa è "999".
- Non puoi configurare due o più routeRules con la stessa priorità. La priorità di ogni regola deve essere impostata su un numero compreso tra 1 e 999 (inclusi).
- La definizione di un percorso completo ti consente di inviare tutte le richieste non corrispondenti a un'origine predefinita o di reindirizzarle a una pagina di destinazione o a un endpoint.
Nell'esempio seguente, puoi vedere che la route /live/us/
non verrebbe mai abbinata
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 questo problema, metti il percorso più specifico (più lungo) a una priorità maggiore:
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 la route più specifica può abbinare correttamente le richieste. Una richiesta
con prefisso /live/eu/
verrebbe comunque trasmessa alla route /live/
con
priorità 2.
Filtro del metodo
Per impostazione predefinita, Media CDN esegue il proxy solo dei metodi GET
, HEAD
e OPTIONS
alla tua origine e filtra i metodi che possono modificare l'origine.
In Anteprima, puoi eseguire l'override di questo comportamento predefinito per una regola di route specifica. Oltre a GET
, HEAD
e OPTIONS
,
Media CDN supporta PUT
, POST
, DELETE
e PATCH
.
Per configurare il supporto di un insieme di metodi per una regola di route, specifica una sezione routeMethods
che abbia 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
In anteprima, Media CDN consente di aggiornare e visualizzare questa configurazione utilizzando l'API Network Services v1alpha1.
In alternativa, puoi utilizzare il comando gcloud alpha edge-cache services export
e il comando gcloud alpha edge-cache services import
per aggiornare i file YAML di configurazione del servizio.
Normalizzazione del percorso
La normalizzazione dei percorsi descrive in che modo Media CDN combina più rappresentazioni di un URL in un'unica rappresentazione canonica in scenari specifici.
La normalizzazione dei percorsi può migliorare direttamente le percentuali di successo della cache riducendo il numero di URL di richiesta che rappresentano gli stessi contenuti e mitigando gli errori per le origini che prevedono percorsi normalizzati.
Le richieste in entrata vengono normalizzate come segue:
- Più barre consecutive vengono unite in un'unica barra. Ad esempio, un
percorso dell'URL di
/videos///12345/manifest.mpd
è normalizzato in/videos/12345/manifest.mpd
. - I segmenti di percorso sono normalizzati in base a quanto riportato nella RFC 3986 Sezione 6.2.2.3.
Ad esempio, il percorso
/a/b/c/./../../g
è normalizzato in/a/g
in base all'algoritmo "remove punti segment" definito in RFC 3986. Questa normalizzazione avviene prima di controllare la cache o inoltrare la richiesta all'origine. - Le richieste non presentano una codifica percentuale normalizzata. Ad esempio, un URL con un carattere barra con codifica percentuale (
%2F
) non viene decodificato nel modulo non codificato.
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 token di richiesta firmata.
Riscritture e reindirizzamenti
Le sezioni seguenti forniscono esempi su come riscrivere le richieste e configurare i reindirizzamenti.
Riscrivi URL di richiesta
Media CDN supporta le riscritture di host e percorsi. Le riscritture modificano l'URL inviato all'origine e consentono di modificare host e percorsi in base alle esigenze. Le riscritture di host e percorsi sono a livello di route, consentendoti di definire quali richieste specifiche vengono riscritte in base a qualsiasi matcher, inclusi percorso, parametro di query e intestazione della richiesta.
Per maggiori dettagli, consulta la specifica 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 in
È possibile specificare un solo elemento tra |
urlRewrite.pathTemplateRewrite
|
È possibile specificare un solo elemento tra |
urlRewrite.hostRewrite
|
Riscrive l'host prima che la richiesta venga inviata al server di origine. |
Note
- Gli URL riscritti non modificano la chiave cache. La chiave cache si basa sull'URL della richiesta inviato dal client.
- La riscrittura avviene dopo la corrispondenza della route e la convalida della richiesta firmata. Le route non vengono ritrovate con 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 utilizzare la
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 che corrisponde
all'elemento matchRules[].prefixMatch
con il valore pathPrefixRewrite
.
Per riscrivere un nome host (ad esempio, riscrivendo 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 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 di richiesta in entrata, consulta la sezione
Acquisizione di variabili.
Richieste di reindirizzamento
Media CDN supporta tre tipi di reindirizzamenti:
- Reindirizzamenti host, che reindirizzano solo l'host (dominio), mantenendo invariati i parametri di percorso e query.
- Reindirizzamenti del percorso, che sostituiscono il percorso completamente.
- Reindirizzamenti prefisso percorso, che sostituiscono solo il prefisso corrispondente.
I reindirizzamenti sono impostati su HTTP 301 (Moved Permanently)
per impostazione predefinita, ma possono essere configurati in modo da restituire codici di stato del reindirizzamento diversi in base alle singole route.
Di seguito è riportato 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 cambia anche il reindirizzamento in un reindirizzamento temporaneo, che impedisce ai client (come i browser) di memorizzarlo nella cache. Può essere utile se prevedi di cambiarla nel prossimo futuro.
I valori redirectResponseCode
supportati sono mostrati nella seguente tabella.
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
- Una route può indirizzare il traffico a un'origine o restituire un reindirizzamento al client. Non puoi impostare i campi
origin
eurlRedirect
contemporaneamente. - Le route che reindirizzano a HTTPS richiedono che al servizio sia collegato almeno un certificato SSL.
Per maggiori 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 del client a HTTPS. Ai client che si connettono tramite HTTP viene inviata una risposta HTTP 301 (Permanent Redirect)
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 tuo servizio, con requireTls
ora impostato su true
.
name: MY_SERVICE requireTls: true
Puoi anche scegliere di impostare l'intestazione Strict-Transport-Security come intestazione di risposta per indirizzare i client a connettersi sempre direttamente tramite HTTPS.
Usa backend di archiviazione di terze parti
Media CDN supporta la connessione a endpoint HTTP raggiungibili pubblicamente al di fuori di Google Cloud, inclusi bucket di archiviazione AWS S3, Azure Blob Storage e altri provider di archiviazione. Ciò può essere utile se hai un'architettura multi-cloud o devi ancora eseguire 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 le tue risorse EdgeCacheService
, devi anche configurare una riscrittura dell'host per le route associate a questa origine (o alle tue origini). Altrimenti, per il recupero dall'origine viene usata
l'intestazione Host impostata dalla richiesta del client.
Ad esempio, per mappare tutte le richieste con un prefisso di percorso /legacy/
al tuo
bucket esterno, puoi configurare sia hostRewrite
sia
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, consulta la documentazione relativa alle intestazioni delle richieste di origine.
Condivisione delle risorse tra origini (CORS)
La condivisione delle risorse tra origini (CORS) è un approccio incentrato sul browser per effettuare in modo sicuro richieste multiorigine.
I criteri CORS consentono di impostare automaticamente le intestazioni CORS, ad esempio Access-Control-Allow-Origins
, in base a un criterio per route.
Configura CORS
Media CDN consente di definire un criterio CORS su una route per EdgeCacheService
.
Un criterio CORS definisce queste regole con un insieme comune di intestazioni HTTP. Puoi impostare intestazioni CORS comuni nelle risposte, ad esempio Access-Control-Allow-Origin
, Access-Control-Max-Age
e Access-Control-Allow-Headers
. Queste intestazioni consentono di effettuare chiamate multiorigine ai servizi Media CDN che potrebbero essere ospitati su un dominio (origine) diverso dal frontend del tuo sito web e potrebbero impedire le richieste multiorigine non consentite in modo esplicito.
Ad esempio, player.example.com
e api.example.com
hanno origini diverse
(nel senso del browser) e potrebbe essere utile che l'applicazione frontend invii richieste a api.example.com
per recuperare la playlist successiva o aggiornare un
elenco di contenuti correlati. Analogamente, player.example.com
potrebbe dover
contattare cdn.example.com
per recuperare le playlist video e i segmenti di video:
cdn.example.com
deve indicare che va bene e che
player.example.com
è un allowed origin
, nonché qualsiasi altra regola
(intestazioni consentite, se è possibile includere 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 corsPolicy
su una route, come segue:
corsPolicy: maxAge: 600 allowOrigins: ["stream.example.com"] allowHeaders: ["X-Client-ID"]
Un corsPolicy
è configurato in
routing.pathMatchers[].routeRules[].routeAction.corsPolicy
all'interno di
EdgeCacheService. Ogni routeRule
può definire un corsPolicy
diverso in base alle necessità o nessuno.
Se definisci un valore corsPolicy
e imposti anche un'intestazione della risposta personalizzata
utilizzando i campi responseHeadersToAdd
su una route con lo stesso nome,
l'intestazione della risposta personalizzata ha la precedenza e viene utilizzata al posto del
valore corsPolicy
.
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 per impostare involontariamente un criterio più permissivo del previsto.
Il {origin_request_header}
speciale viene compilato con l'intestazione HTTP Origin
nella richiesta del client. Può essere impostato come valore di intestazione della risposta personalizzata su una
route, per l'intestazione Access-Control-Allow-Origin
.
Per ulteriori dettagli, consulta la specifica dell'API 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 contenuti video vengono pubblicati da |
Access-Control-Allow-Origins: https://stream.example.com
|
maxAge |
Imposta l'intestazione della risposta Alcuni browser limitano questo tempo a 2 ore o meno, anche se è 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 di risposta 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 Questa operazione è spesso richiesta dai video player, che potrebbero avere bisogno di accedere a intestazioni di risposta specifiche per i contenuti video quando si richiedono contenuti multiorigine. |
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. Le richieste
OPTIONS pre-flight vengono inviate tramite proxy all'origine.
|
N/A |
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 non restituiscono errori, controlla quanto segue:
- Una route deve avere un valore
matchRule
con un valore esattamente comeprefixMatch
,fullPathMatch
opathTemplateMatch
definito. L'API restituisce un errore se non includi uno di questi campi. - Assicurati che
priority
di ogni route sia impostato correttamente: alle route più specifiche (più lunghe) deve essere assegnata una priorità maggiore rispetto alle corrispondenze di route più brevi e più ampie. - Per impostazione predefinita, sono supportate solo le richieste
GET
,HEAD
eOPTIONS
. In Anteprima, per configurare il supporto per altri metodi, vedi Metodi di routing. I metodi non abilitati per una determinata route vengono rifiutati con un errore HTTP405 (Method Not Allowed)
. - Le richieste HTTP
GET
con un corpo o qualsiasi richiesta con trailer vengono rifiutate con un errore HTTP400
, perché il corpo delle richieste non è consentito nelle richiesteGET
. - La corrispondenza dei parametri di query e delle intestazioni è un tipo logico di tipo "AND", ovvero la richiesta deve corrispondere a tutti i parametri di query o a tutte le chiavi di intestazione (e i valori, se specificati) per trovare una corrispondenza con la route specificata.
Passaggi successivi
- Consulta la documentazione sulla configurazione della memorizzazione nella cache.
- Scopri come connetterti a origini diverse.
- Configura i certificati TLS (SSL) per il tuo servizio.
- Configurare le richieste firmate per autenticare l'accesso ai contenuti.