Configura le route di servizio

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

Configurare una regola di route

Configura una regola di route per un servizio Media CDN.

Richieste di corrispondenza

Una configurazione Media CDN contiene un insieme di route definiti nella sezione Routing per una risorsa EdgeCacheService. Questi percorsi corrispondono alle richieste in base ad almeno un host. Per ulteriori 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, norme CORS, intestazioni HTTP personalizzate e mapping dell'origine. 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 una policy di memorizzazione nella cache negativa. Le richieste di segmenti possono essere suddivise in un'altra origine utilizzando intestazioni e parametri di query per separare tipi di manifest o utenti specifici.

L'esempio seguente mostra come instradare le richieste che corrispondono a un'intestazione, un parametro di query e un prefisso del 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 esatta, del prefisso e con caratteri jolly del percorso. La corrispondenza del percorso può essere combinata con la corrispondenza basata su host, intestazione e parametri di query per creare regole di routing delle richieste granulari.

Di seguito sono riportati tre modi per trovare una corrispondenza in un percorso URL.

Per ulteriori dettagli, consulta la specifica dell'API per MatchRule.

Ad esempio, per trovare corrispondenze con 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:

• Una richiesta a media.example.com/stream/id/1234/hls/manifest.m3u8 corrisponde a questo percorso.
• Una richiesta di 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 sia stata configurata un'altra route o una route catch-all.

Per indicazioni su come funziona la precedenza per le route con prefissi simili, consulta la sezione Ordinamento e priorità route.

Corrispondenza (carattere jolly) di pattern

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 con caratteri jolly.

Puoi anche associare uno o più segmenti di percorso a variabili denominate in un campo pathTemplateMatch e poi fare riferimento a queste variabili quando riscrivi l'URL in un campo pathTemplateRewrite. In questo modo, puoi riordinare e rimuovere i segmenti URL prima che la richiesta venga inviata all'origine.

Il seguente esempio mostra come eseguire la corrispondenza con 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.

Note:

• Se non riscrivi un URL, utilizza gli operatori più semplici * e **.
• Quando utilizzi le variabili per acquisire segmenti di percorso, non è possibile fare riferimento a nessuna parte dell'URL che non viene acquisita da una variabile in un successivo pathTemplateRewrite. Per un esempio, consulta la sezione Acquisizione delle variabili di percorso.
• Non puoi fare riferimento a variabili in un pathTemplateRewrite successivo che non esistono nel pathTemplateMatch sulla stessa route.
• 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 di file

L'esempio seguente mostra un caso d'uso comune per gli operatori jolly: la corrispondenza di tutti i segmenti di percorso fino a un suffisso.

In questo caso, segui questi passaggi:

• Recupera i manifest dei video (playlist) che terminano con .m3u8 e .mpd dall'origine del 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 (Dynamic Ad Insertion) e per i video live in cui il manifest viene aggiornato ogni pochi secondi.

La seguente configurazione mostra come configurare il routing di 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 denominate per descrivere uno o più segmenti di percorso.

Queste variabili possono essere utilizzate in un pathTemplateRewrite per riscrivere il percorso prima che la richiesta venga inviata all'origine o per rendere un pathTemplateMatch complesso autodescrittivo.

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 / ("slash") in un percorso URL.
• Una variabile di {name=**} acquisisce tutti i segmenti di percorso rimanenti; in questo caso, corrisponde sia a segments/00001.ts che a master.m3u8.
• In pathTemplateRewrite sullo stesso percorso, fai riferimento ad alcune delle variabili acquisite in pathTemplateMatch. Ometti esplicitamente le variabili {country} e {lang} perché non corrispondono alla struttura delle directory nell'origine.

Con questo esempio, si verifica quanto segue:

• Un URL di richiesta in entrata di /us/en/hls/123139139/segment_00001.ts corrisponde a pathTemplateMatch e viene riscritto in /123139139/hls/segment_00001.ts prima di essere inviato all'origine.
• Un URL della richiesta in entrata /us/123139139/master.m3u8 non corrisponde a pathTemplateMatch e riceve un codice di stato HTTP 404 (Not Found).
• Un URL di richiesta in entrata di /br/es/dash/c966cbbe6ae3/subtitle_00001.vtt corrisponde anche a pathTemplateMatch e viene riscritto in /c966cbbe6ae3/dash/subtitle_00001.vtt prima di essere inviato all'origine.

Per scoprire di più su come funziona la corrispondenza con caratteri jolly con la riscrittura degli URL, consulta la sezione Riscrizioni.

Corrispondenza host

Ogni servizio può corrispondere a più nomi host e ogni insieme di nomi host contiene il proprio gruppo di route (noti come corrispondenze di percorso). Nel caso più comune, tutti i nomi host per un servizio vengono mappati a un singolo insieme di route condivise con un singolo elenco di host e una singola espressione di corrispondenza dei percorsi.

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

Gli host che non corrispondono mostrano 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, raggruppamento per paese o live rispetto a on demand). Poiché ogni servizio ha un'unica policy di sicurezza, in genere consigliamo di avere un servizio per ogni mercato (area geografica) o carico di lavoro.

Note:

• Le intestazioni host (o HTTP/2 :authority) che contengono una porta vengono abbinate implicitamente a un host configurato. Non è necessario specificare esplicitamente le porte.
• Se la richiesta avviene tramite HTTP, una voce hostRules[].hosts[] di *.vod.example.com corrisponde a us.vod.example.com e us.vod.example.com:80.
• Se la richiesta avviene tramite HTTPS (TLS), una voce hostRules[].hosts[] di *.vod.example.com corrisponde a us.vod.example.com:443.

Per ulteriori dettagli, consulta la specifica dell'API per HostRule.

Corrispondenza in base a intestazioni e parametri di ricerca

Puoi configurare le route in modo che corrispondano a nomi specifici di parametri di ricerca e intestazioni, nonché alla presenza di un valore di intestazione (prefisso, suffisso o corrispondenza esatta).

La corrispondenza tra parametri di query e intestazioni è logica "AND": la richiesta deve corrispondere a tutti iparametri di ricercay e alle chiavi di intestazione (e ai valori, se specificati) per corrispondere alla route specificata.

Ad esempio, se vuoi indirizzare 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 all'interno di 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 questa route. Le richieste in cui manca questo nome dell'intestazione o con un valore diverso non corrispondono a questa route.

Per ulteriori dettagli, consulta la specifica dell'API per HeaderMatch.

Analogamente, per la corrispondenza con parametri di ricerca, specifica uno o più queryParameterMatches nel seguente modo:

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 client di https://cdn.example.com/videos/1234/abcd/xyz.m3u8?playback_type=live&geo=eu corrisponde a questa route.

Per ulteriori dettagli, consulta la specifica dell'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 generica per un determinato pathMatcher (insieme di route), procedi nel seguente modo:

• Crea un routeRule con la priorità più bassa (il numero più alto), ad esempio 999, che è la priorità di route più bassa possibile.
• Configura un matchRule con una corrispondenza del prefisso di / (corrisponde a tutti i percorsi delle richieste).
• Configura (uno dei) un origin o un urlRedirect sulla route.

Ad esempio, per configurare una route catch-all che indirizza tutte le richieste non corrispondenti 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: /

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 più piccolo). Una route che corrisponde a un prefisso di /stream/ con priorità 1 impedisce altrimenti a una route più specifica di /stream/live/eu/ con priorità 5 di corrispondere a qualsiasi richiesta.

• La route con priorità più alta è "1", mentre quella con priorità 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 una route catch-all 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 verrà mai corrisposta 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 alla route più specifica (più lunga):

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ò corrispondere correttamente alle richieste. Una richiesta con il prefisso /live/eu/ verrà comunque indirizzata al percorso /live/ con priorità 2.

Filtro del metodo

Per impostazione predefinita, Media CDN esegue il proxy solo dei metodi GET, HEAD e OPTIONS all'origine e filtra i metodi che possono modificare l'origine.

Puoi ignorare questo comportamento predefinito per una regola di routing specifica specificando i metodi per cui vuoi utilizzare il proxy per l'origine. Oltre a GET, HEAD e OPTIONS, Media CDN supporta PUT, POST, DELETE e PATCH.

Media CDN esegue nuovi tentativi o tentativi di failover solo per le richieste che utilizzano i metodi HTTP più sicuri, come GET, HEAD o OPTIONS.

Per configurare il supporto per un insieme di metodi per una regola di percorso, specifica una sezione routeMethods con 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 del percorso descrive il modo in cui Media CDN combina più rappresentazioni di un URL in un'unica rappresentazione canonica in scenari specifici.

La normalizzazione del percorso può migliorare direttamente i tassi di successo della cache riducendo il numero di URL di richiesta che rappresentano lo stesso contenuto e mitigando gli errori di 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 percorso URL /videos///12345/manifest.mpd viene normalizzato in /videos/12345/manifest.mpd.
• I segmenti di percorso vengono normalizzati in base alla sezione 6.2.2.3 dell'RFC 3986. Ad esempio, il percorso /a/b/c/./../../g viene normalizzato in /a/g in base all'algoritmo "remove dot segments" definito in RFC 3986. Questa normalizzazione avviene prima di controllare la cache o inoltrare la richiesta all'origine.
• Le richieste non sono normalizzate con codifica percentuale. Ad esempio, un URL con un carattere barra codificato in percentuale (%2F) non viene decodificato nella forma non codificata.

Gli URL rimangono sensibili alle maiuscole e non vengono normalizzati. 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.

Riscrivere gli URL delle richieste

Media CDN supporta la riscrittura di host e percorsi. Le riscritture modificano l'URL inviato all'origine e ti consentono di modificare host e percorsi in base alle esigenze. Le riscritture di host e percorso sono a livello di route, il che ti consente di definire quali richieste specifiche vengono riscritte in base a qualsiasi matcher, inclusi 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:

Note:

• Gli URL riscritti non modificano la chiave della cache. La chiave della cache si basa sull'URL della richiesta inviata dal client.
• La riscrittura avviene dopo la corrispondenza delle route e la convalida delle richieste firmate. Le route non vengono corrispondenti a un'altra regola di corrispondenza.

Esempio: rimuovere un prefisso di percorso

Ad esempio, per riscrivere un URL di richiesta 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 funziona sostituendo l'intero prefisso del percorso corrispondente in matchRules[].prefixMatch con il valore di pathPrefixRewrite.

Per riscrivere un nome host (ad esempio, riscrivere 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 cambierebbe da cdn.example.com/videos/* a my-bucket.s3.us-west-2.amazonaws.com/videos/*. Puoi anche combinare la riscrittura 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 della 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 il percorso e parametri di ricerca.
• Reindirizzamenti del percorso, che sostituiscono completamente il percorso.
• Reindirizzamenti del prefisso del percorso, che sostituiscono solo il prefisso corrispondente.

I reindirizzamenti sono impostati per impostazione predefinita su HTTP 301 (Moved Permanently), ma possono essere configurati per restituire codici di stato di reindirizzamento diversi in base alla route.

La seguente configurazione è un esempio di reindirizzamento basato sul 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, il che impedisce ai client (come i browser) di memorizzarlo nella cache. Questa opzione può essere utile se prevedi di modificarlo nel prossimo futuro.

I valori redirectResponseCode supportati sono riportati nella tabella seguente.

Note:

• Una route può indirizzare il traffico a un'origine o restituire un reindirizzamento al client. Non puoi impostare contemporaneamente i campi origin e urlRedirect.
• Le route che reindirizzano a HTTPS richiedono che almeno un certificato SSL sia collegato al servizio.

Per ulteriori dettagli, consulta la specifica dell'API per RouteRule.UrlRedirect.

Reindirizzare tutte le richieste a HTTPS

Per reindirizzare tutte le richieste a HTTPS (anziché HTTP), puoi configurare ciascuno dei tuoi servizi in modo che reindirizzino automaticamente tutte le richieste client a HTTPS. I client che si connettono tramite HTTP ricevono un codice di stato HTTP 301 (Permanent Redirect) con l'intestazione Location impostata sullo stesso URL utilizzando "https://" anziché "http://".

gcloud edge-cache services update MY_SERVICE \
    --require-tls

Request issued for: [MY_SERVICE]
Updated service [MY_SERVICE].

  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.

Utilizzare backend di archiviazione di terze parti

Media CDN supporta la connessione a endpoint HTTP raggiungibili pubblicamente al di fuori di Google Cloud, inclusi i bucket di archiviazione AWS S3, Azure Blob Storage e altri provider di archiviazione. Ciò può essere utile se hai un'architettura multicloud o se devi ancora eseguire la migrazione dei dati a Cloud Storage utilizzando Storage Transfer Service.

Una configurazione dell'origine minima che configura un bucket ospitato virtualmente in AWS S3:

name: MY_S3_ORIGIN
originAddress: BUCKET-NAME.s3.REGION.amazonaws.com

Se non utilizzi un nome bucket che corrisponda ai nomi host configurati per le tue risorse EdgeCacheService, devi anche configurare una riscrittura dell'host per le route associate a questa origine (o origini). In caso contrario, viene utilizzata l'intestazione Host impostata dalla richiesta del client durante il recupero dall'origine.

Ad esempio, per mappare tutte le richieste con un prefisso di percorso /legacy/ al tuo bucket esterno, puoi configurare sia un hostRewrite sia 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 saperne di più su come viene impostata l'intestazione host nelle 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 tra origini. Le policy CORS ti consentono di impostare automaticamente le intestazioni CORS, ad esempio Access-Control-Allow-Origins, in base a una policy per route.

Configurare CORS

Media CDN consente di definire una policy 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, ad esempio 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 autorizzi esplicitamente.

Ad esempio, player.example.com e api.example.com sono origini diverse (nel senso del browser) e potresti voler fare in modo che la tua applicazione frontend invi richieste a api.example.com per recuperare la playlist successiva o aggiornare un elenco di contenuti correlati. Allo stesso modo, 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 che player.example.com è un allowed origin, nonché qualsiasi altra regola (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 route, nel seguente modo:

corsPolicy: maxAge: 600 allowOrigins: ["stream.example.com"] allowHeaders:
["X-Client-ID"]

Un corsPolicy è configurato in routing.pathMatchers[].routeRules[].routeAction.corsPolicy all'interno di un EdgeCacheService. Ogni routeRule può definire un corsPolicy diverso in base alle esigenze o nessuno.

Se definisci un valore corsPolicy e imposti anche un'intestazione della risposta personalizzata utilizzando i campi responseHeadersToAdd in 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 di origine imposta le 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 criteri più permissivi di quanto previsto.

La variabile speciale {origin_request_header} viene compilata con l'intestazione HTTP Origin nella richiesta del client. Può essere impostato come valore dell'intestazione della risposta personalizzata in una route, per l'intestazione Access-Control-Allow-Origin.

Per maggiori dettagli, consulta la specifica dell'API per RouteAction.CORSPolicy.

Campi della policy CORS

La tabella seguente descrive i campi contenuti in una norma CORS.

Esempio di corsPolicy

Il seguente esempio di configurazione mostra una configurazione corsPolicy di base:

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 di routing

Se alcune richieste non recuperano risultati corrispondenti o restituiscono errori, controlla quanto segue:

• Un percorso deve avere un matchRule con esattamente uno dei valori prefixMatch, fullPathMatch o pathTemplateMatch definito. L'API restituisce un errore se non includi uno di questi campi.
• Assicurati che il 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 e OPTIONS. Per configurare il supporto per altri metodi, vedi Metodi di routing. I metodi non abilitati per una determinata route vengono rifiutati con un errore HTTP 405 (Method Not Allowed).
• Le richieste HTTP GET con un corpo o qualsiasi richiesta con trailer vengono rifiutate con un errore HTTP 400, perché i corpi delle richieste non sono consentiti nelle richieste GET.
• La corrispondenza di parametri di query e intestazioni è logica "AND": la richiesta deve corrispondere a tutte le chiavi (e i valori, se specificati) dei parametri di query o delle intestazioni per corrispondere alla 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.
• Configura le richieste firmate per autenticare l'accesso ai contenuti.
• Per maggiori dettagli sulla configurazione delle risorse EdgeCacheService utilizzando Terraform, consulta la documentazione del registro Terraform.