Configura route di servizio

Media CDN offre funzionalità di routing HTTP avanzate che consentono di mappare il traffico a specifiche configurazioni perimetrali e origini a un livello livello.

Richieste di 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 indirizzare le richieste di manifest a un'origine specifica definisci 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 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 percorso con caratteri jolly. La corrispondenza dei percorsi può essere combinata con host, intestazione e parametri di query corrispondenza 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 un valore finale barre, se pertinenti.

Una route con una regola di corrispondenza fullPathMatch: "/stream/" corrisponde a /stream/ ma non a /stream o /stream/us/hls/1234.ts.

Un fullPathMatch è una corrispondenza esplicita (esatta).
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 prefixMatch: "/videos/" corrisponde sia a /videos/hls/58481314/manifest.m3u8 che /videos/dash perché entrambi contengono /videos/ .
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 pathTemplateMatch: "/**.m3u8" corrisponde a qualsiasi percorso dell'URL che termina con .m3u8.

Sia /content/en-GB/13/51491/manifest_193193.m3u8 che /p/abc/1234/manifest_1080p5000.m3u8 corrispondono a questo pattern.

Per altri esempi, consulta corrispondenza pattern.

Per ulteriori 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 al 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 corrispondono a questo percorso.

Nel secondo caso, Media CDN restituisce un errore HTTP 404, a meno che non ci sia un altro percorso o un percorso completo configurato.

Per indicazioni su come funziona la predecenza per i percorsi con prefissi simili, consulta alla sezione Priorità e ordinamento delle route.

Corrispondenza di pattern (con caratteri jolly)

La corrispondenza dei pattern ti consente di abbinare più parti di un URL, inclusi gli URL parziali e suffissi (estensioni file), utilizzando la sintassi con caratteri jolly.

Puoi anche associare uno o più componenti del percorso a variabili con nome in un campo pathTemplateMatch, poi fai riferimento a queste variabili quando riscrivi l'URL in un campo pathTemplateRewrite. In questo modo puoi riordinare e rimuovere i componenti dell'URL prima la richiesta viene 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 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 del percorso.

Corrisponde a un singolo componente del percorso, fino al separatore di percorso successivo: /.

/content/{format}/{lang}/{id}/{file}.vtt corrispondenze /content/hls/en-us/12345/en_193913.vtt e acquisizioni 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/*}/* corrispondenze /videos/lang/en/video.m4s e compila la variabile del 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.

/**.m3u8 o /{path=**}.m3u8 corrisponde a tutti segmenti di percorso fino all'estensione.

/videos/{file=**} corrispondenze /videos/en-GB/def566/manifest.m3u8, tra cui e acquisisce la variabile di percorso file="en-GB/def566/manifest.m3u8.

Note:

  • Se non stai riscrivendo un URL, utilizza i più semplici operatori * e **.
  • Quando utilizzi variabili per acquisire i componenti del percorso, tutte le parti dell'URL che non vengono acquisiti da una variabile non può essere referenziata in una pathTemplateRewrite. Per un esempio, vedi l'acquisizione delle variabili del percorso.
  • Non puoi fare riferimento a variabili in un elemento pathTemplateRewrite successivo che non esistono in pathTemplateMatch sullo 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 e pathTemplateRewrite non devono superare i 255 caratteri.

Esempio: corrispondenza in base a un'estensione del file

Nell'esempio seguente viene mostrato un caso d'uso comune per gli operatori con caratteri jolly: 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 (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 configurazione seguente mostra come configurare Routing Media CDN per supportare quanto segue:

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 del percorso. Un segmento di percorso è tutto 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 a segments/00001.ts sia a master.m3u8.
  • Nel pathTemplateRewrite sullo stesso percorso, fai riferimento ad alcuni delle variabili acquisite in pathTemplateMatch. 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 a pathTemplateMatch 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 alla pathTemplateMatch e riceve una risposta HTTP 404 (Not Found).
  • URL di richiesta in entrata di /br/es/dash/c966cbbe6ae3/subtitle_00001.vtt corrisponde anche alla pathTemplateMatch ed è 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, ognuno dei quali contiene 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

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 percorsi (ad esempio, raggrupparli per paese o rispetto a quelle on demand). Poiché ogni servizio ha un'unica norma di sicurezza, generalmente consigliano di avere un servizio per ogni mercato (area geografica) o carico di lavoro disponibili.

Note:

  • Le intestazioni host (o HTTP/2 :authority) che contengono una porta sono implicitamente confrontato con un host configurato. Non è necessario specificare esplicitamente ports.
  • Se la richiesta avviene tramite HTTP, viene visualizzata una voce hostRules[].hosts[] di *.vod.example.com corrisponde a us.vod.example.com e us.vod.example.com:80.
  • Se la richiesta è tramite HTTPS (TLS), viene visualizzata una voce hostRules[].hosts[] di *.vod.example.com corrisponde a us.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 le route in modo che corrispondano a nomi specifici di intestazioni e parametri di query, e la presenza di un valore di intestazione (prefisso, suffisso o corrispondenza esatta).

La corrispondenza dei parametri di query e dell'intestazione è con operatore logico "AND", la richiesta deve corrispondere tutti i parametri di ricerca e le chiavi di intestazione (e i valori, se specificati) in modo che corrispondano per un determinato percorso.

Ad esempio, se vuoi indirizzare le richieste con un nome di campo di intestazione specifico valore dell'intestazione a un'origine denominata alternate-origin, configura la corrispondenza condizioni 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 x-device-name: roku intestazione corrisponde a questo percorso. Richieste senza questa intestazione o con un valore diverso non corrispondono a questo percorso.

Per ulteriori dettagli, consulta la specifica API per HeaderMatch.

Analogamente, per trovare corrispondenze 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 https://cdn.example.com/videos/1234/abcd/xyz.m3u8?playback_type=live&geo=eu corrisponde a questo percorso.

Per ulteriori 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), procedi nel seguente modo:

  • Crea un elemento routeRule con la priorità più bassa (numero più alto), ad esempio: 999, che è la priorità di routing 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 urlRedirect 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 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: /

Facoltativamente, puoi riscrivere l'URL prima del recupero dell'origine oppure reindirizzare a un pagina predefinita (ad es. la pagina di destinazione) anziché inviare la richiesta "così com'è". all'origine.

Ordinamento e priorità route

Ogni route in un array di routeRules[] deve avere un priority associato a li annotino.

Le route più specifiche dovrebbero essere impostate su una priorità più alta (numero più piccolo). 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 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 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.

In Anteprima, puoi eseguire l'override di questa impostazione predefinita. comportamento per una determinata regola di route specificando i metodi che si ad esempio inviato tramite proxy alla tua 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

In Anteprima, Media CDN consente di aggiornare e visualizzare mediante 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ù 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 entrata 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 a RFC 3986 Sezione 6.2.2.3. Ad esempio, il percorso /a/b/c/./../../g è normalizzato in /a/g in base a il "rimuovi segmenti di punti" specifico definito in RFC 3986. Questa normalizzazione avviene prima di controllare nella cache o inoltrando la richiesta all'origine.
  • Le richieste non presentano una codifica percentuale normalizzata. Ad esempio, un URL con un Il carattere della barra con codifica percentuale (%2F) non viene decodificato nel formato non codificato in un modulo di testo.

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 reindirizzamenti.

Riscrivi URL di richiesta

Media CDN supporta le riscritture di host e percorsi. Le riscritture cambiano URL inviato all'origine e consente di modificare host e percorsi in base alle esigenze. Host e le riscritture dei percorsi sono a livello di route, consentendoti di definire quali richieste specifiche vengono riscritte in base a qualsiasi matcher, tra cui percorso, parametro di query e richiesta intestazione.

Per ulteriori 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 nel prefixMatch che corrispondono alla richiesta.

Solo uno tra pathPrefixRewrite o pathTemplateRewrite può essere specificato in una singola regola di route.

urlRewrite.pathTemplateRewrite

pathTemplateRewrite può essere utilizzato solo con un pathTemplateMatch regola di corrispondenza corrispondente sulla stessa route.

Solo uno tra pathPrefixRewrite o pathTemplateRewrite può essere specificato in una singola regola di route.

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 su l'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, 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 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 host, che reindirizzano solo l'host (dominio), mantenendo il percorso e parametri di ricerca non modificati.
  • Reindirizzamenti del percorso, che sostituiscono il percorso completamente.
  • Reindirizzamenti prefisso percorso, 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.

Di seguito è riportato un esempio di reindirizzamento basato su prefisso. a 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

In questo esempio viene modificato anche il reindirizzamento a un reindirizzamento temporaneo, che impedisce ai client (come i browser) di memorizzarli nella cache. Questo può essere utile se prevedi di lo cambieremo 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:

  • Un percorso può indirizzare il traffico a un'origine o restituire un reindirizzamento alla di alto profilo. Non puoi impostare sia origin sia urlRedirect campi contemporaneamente.
  • Le route che reindirizzano a HTTPS richiedono almeno uno certificato SSL sia collegato alla completamente gestito di Google Cloud.

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 ogni dei tuoi servizi per reindirizzare automaticamente tutte le richieste del client a HTTPS. Clienti quando si connette tramite HTTP viene inviata una risposta HTTP 301 (Permanent Redirect) con 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 HTTP raggiungibile pubblicamente al di fuori di Google Cloud, inclusi i bucket di archiviazione AWS S3, Archiviazione BLOB e altri fornitori di spazio di archiviazione. Questo può essere utile se hai un multi-cloud o non devono ancora migrare i 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 durante il recupero dall'origine viene utilizzata.

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)

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 di singola route.

Configura CORS

Media CDN 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 consentono di chiamate multiorigine ai servizi Media CDN che potrebbero 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 sono origini diverse (nel senso del browser) e potresti voler avere la tua applicazione frontend invia richieste a api.example.com per recuperare la playlist successiva o aggiornare elenco di contenuti correlati. Analogamente, player.example.com potrebbe dover contatta 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 è una allowed origin, così come qualsiasi altra regola (intestazioni consentite, se è possibile 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 valore corsPolicy diverso necessarie o nessuna.

Se definisci un valore corsPolicy e imposti anche un'intestazione della risposta personalizzata tramite utilizzando i campi responseHeadersToAdd su un percorso 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 un valore corsPolicy vengono utilizzati i valori corsPolicy. I valori non sono compressi o combinati per evitare di inviare valori di intestazione non validi a un client oppure che non sia 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 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 Access-Control-Allow-Origins, che specifica quali origini possono effettuare richieste multiorigine in un dell'ambiente del browser.

Ad esempio, se i contenuti video vengono pubblicati https://video.example.com, ma il tuo portale rivolto agli utenti fornito da https://stream.example.com, aggiungi https://stream.example.com come origine consentita.

Access-Control-Allow-Origins: https://stream.example.com
maxAge

Imposta l'intestazione della risposta Access-Control-Max-Age, che specifica per quanto tempo, in secondi, un client del browser deve memorizzare nella cache risposta a una richiesta CORS pre-flight.

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 Access-Control-Allow-Methods, che specifica i metodi HTTP autorizzati ad accedere risorsa.

Per impostazione predefinita, Media CDN supporta solo GET, HEAD e OPTIONS. Nel Anteprima, per configurare il supporto per altri metodi, vedi Metodi di routing.

 Access-Control-Allow-Methods: GET, OPTIONS, HEAD
allowHeaders

Imposta l'intestazione Access-Control-Allow-Headers, che determina quali intestazioni possono essere inviate in una richiesta CORS.

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 Access-Control-Expose-Headers, che determina quali intestazioni sono accessibili dal lato client. JavaScript.

Questa operazione è spesso richiesta dai video player, che potrebbero richiedere l'accesso intestazioni delle risposte 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 Access-Control-Allow-Credentials, che consente a JavaScript lato client di ispezionare la risposta per le richieste con credenziali incluse.

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:

  • Una route deve avere un matchRule con esattamente uno tra prefixMatch, fullPathMatch o pathTemplateMatch definiti. L'API restituisce un errore se uno di questi campi.
  • Assicurati che priority di ogni percorso sia impostato correttamente: più specifico ai percorsi (più lunghi) deve avere una priorità maggiore rispetto a quelli più brevi e ampi. corrispondenze di percorso.
  • Per impostazione predefinita, sono supportate solo le richieste GET, HEAD e OPTIONS. In Anteprima, per configurare il supporto per per altri metodi, consulta Metodi di routing. I metodi non abilitati per una determinata route vengono rifiutati con un errore HTTP 405 (Method Not Allowed).
  • Le richieste GET HTTP con un corpo o qualsiasi richiesta con trailer vengono rifiutate con un errore HTTP 400, perché il corpo delle richieste non è consentito in GET richieste.
  • La corrispondenza dei parametri di query e dell'intestazione è con operatore logico "AND", la richiesta deve corrisponde a tutti i parametri di query o a tutte le chiavi di intestazione (e i valori, se specificati) in modo che corrispondano al percorso specificato.

Passaggi successivi