Questa pagina è stata tradotta dall'API Cloud Translation.

Definisci intestazioni personalizzate

Media CDN consente di specificare intestazioni personalizzate di richieste e risposte.

Le intestazioni personalizzate ti consentono di:

Restituire i dati geografici del cliente, ad esempio paese, regione o città, da utilizzare per mostrare contenuti localizzati.
Determina se una risposta è stata fornita dalla cache (completa o in parte) e la posizione della cache da cui è stata fornita.
Rimuovi, sostituisci o aggiungi alle intestazioni della richiesta e della risposta.

Puoi utilizzare le intestazioni anche per instradare le richieste a origini diverse. Se hai bisogno di configurare intestazioni di condivisione delle risorse tra origini (CORS), configura un criterio CORS per ogni route.

Imposta intestazioni personalizzate

Le intestazioni vengono impostate su ogni percorso, il che consente di aggiungere e rimuovere intestazioni per contenuti diversi, come manifest o segmenti video.

Per impostazione predefinita, i valori dell'intestazione aggiunta sono separati da virgole e aggiunti alle intestazioni della risposta o della richiesta con gli stessi nomi dei campi.

Per sovrascrivere i valori esistenti, imposta replace su true.

Il seguente esempio di .routing.pathMatchers[].routeRules[].headerAction mostra le intestazioni aggiunte e rimosse in una risorsa EdgeCacheService:

gcloud edge-cache services describe prod-media-service

routeRules:
  - priority: 1
    description: "video routes"
    matchRules:
      - prefixMatch: "/video/"
    headerAction:
      responseHeadersToAdd:
        # Return the country (or region) associated with the client's IP address.
        - headerName: "client-geo"
          headerValue: "{client_region}"
          replace: true
      requestHeadersToAdd:
        # Inform the upstream origin server the request is from Media CDN
        - headerName: "x-downstream-cdn"
          headerValue: "Media CDN"
      responseHeadersToRemove:
        - headerName: "X-User-ID"
        - headerName: "X-Other-Internal-Header"

In questo esempio si verifica quanto segue:

Aggiunge un'intestazione client-geo personalizzata alla risposta utilizzando la variabile {client_region}, che restituisce il paese (o la regione) associato all'indirizzo IP del client.
Aggiunge un'intestazione x-downstream-cdn personalizzata alla richiesta utilizzando una stringa statica.
Rimuove due intestazioni interne.

Variabili di intestazione dinamiche

Le intestazioni personalizzate possono contenere una o più variabili dinamiche.

Le intestazioni delle richieste che fanno parte del criterio della chiave di cache (cacheKeyPolicy.includedHeaderNames) possono contenere una o più variabili personalizzate. Le intestazioni delle richieste che contengono altre variabili dinamiche non possono far parte della chiave cache.

Variabile	Descrizione	Supportate per le intestazioni delle richieste	Supportata per le intestazioni delle richieste in una chiave cache	Supportate per le intestazioni delle risposte
`cdn_cache_status`	Un elenco separato da virgole di posizioni (codice IATA dell'aeroporto più vicino) e stati di ciascun nodo di cache nel percorso di richiesta/risposta, dove il valore più a destra rappresenta la cache più vicina all'utente.			✔
`client_city`	Il nome della città da cui ha avuto origine la richiesta, ad esempio `Mountain View` per Mountain View, California. Non esiste un elenco canonico di valori validi per questa variabile. I nomi delle città possono contenere lettere, numeri, spazi e i seguenti caratteri US-ASCII: !#$%&'*+-.^_`\|~.	✔		✔
`client_city_lat_long`	La latitudine e la longitudine della città da cui ha avuto origine la richiesta, ad esempio `37.386051,-122.083851` per una richiesta da Mountain View.	✔		✔
`client_region`	Il paese (o la regione) associato all'indirizzo IP del client. Si tratta di un codice regione CLDR Unicode, come `US` o `FR`. Nella maggior parte dei paesi, questi codici corrispondono direttamente ai codici ISO-3166-2.	✔	✔	✔
`client_region_subdivision`	La suddivisione, ad esempio provincia o stato, del paese associato all'indirizzo IP del client. Questo è un ID di suddivisione CLDR Unicode, ad esempio `USCA` o `CAON`. Questi codici Unicode derivano dalle suddivisioni definite dallo standard ISO-3166-2.	✔	✔	✔
`client_rtt_msec`	Il tempo stimato di trasmissione andata e ritorno tra la CDN e il client HTTP(S), in millisecondi. Si tratta del parametro del tempo di round trip livellato (SRTT) misurato dallo stack TCP della CDN, in base al documento RFC 2988.	✔		✔
`device_request_type`	Il tipo di dispositivo utilizzato dal client. Questi sono i valori validi: `DESKTOP`, `MOBILE`, `TABLET`, `SMART_TV`, `GAME_CONSOLE`, `WEARABLE` e `UNDETERMINED`.	✔	✔
`original_request_id`	L'identificatore univoco assegnato alla richiesta che ha generato originariamente questa risposta. Compilato solo se diverso da `request_id` per le risposte memorizzate nella cache.			✔
`origin_name`	La risorsa `EdgeCacheOrigin` da cui è stata inviata la risposta tramite proxy.			✔
`origin_request_header`	Riflette il valore dell'intestazione Origin nella richiesta per i casi d'uso CORS (condivisione delle risorse tra origini).			✔
`proxy_status`	Un elenco di proxy HTTP intermedi nel percorso di risposta. Il valore è definito da RFC 9209. Una risorsa `EdgeCacheService` è rappresentata da `Google-Edge-Cache`. Se la risposta è stata recuperata dall'origine, una risorsa `EdgeCacheOrigin` è rappresentata da `Google-Edge-Cache-Origin`.			✔
`tls_sni_hostname`	L'indicazione del nome del server (come definita in RFC 6066), se fornita dal client durante l'handshake TLS o QUIC. Il nome host viene convertito in lettere minuscole e gli eventuali punti finali vengono rimossi.	✔		✔
`tls_version`	La versione TLS negoziata tra il client e il bilanciatore del carico durante l'handshake SSL. I valori possibili sono `TLSv1`, `TLSv1.1`, `TLSv1.2` e `TLSv1.3`. Se il client si connette utilizzando QUIC anziché TLS, il valore è QUIC.	✔		✔
`tls_cipher_suite`	La suite di crittografia negoziata durante l'handshake TLS. Il valore è definito dal registro di suite di crittografia TLS IANA, ad esempio `TLS_RSA_WITH_AES_128_GCM_SHA256`. Questo valore è vuoto per le connessioni QUIC e client non criptate.	✔		✔
`user_agent_family`	La famiglia di browser utilizzata dal client. Questi sono i valori validi: `APPLE`, `APPLEWEBKIT`, `BLACKBERRY`, `DOCOMO`, `GECKO`, `GOOGLE`, `KHTML`, `KOREAN`, `MICROSOFT`, `MSIE`, `NOKIA`, `NETFRONT`, `OBIGO`, `OPENWAVE`, `OPERA`, `OTHER`, `POLARIS`, `TELECA`, `SEMC`, `SMIT` e `USER_DEFINED`.	✔	✔

Alle variabili personalizzate si applicano le seguenti considerazioni:

Le intestazioni di richieste e risposte esistenti vengono conservate, ad eccezione di quelle seguenti, che vengono rimosse:
- X-User-IP
- Qualsiasi intestazione con X-Google o X-GFE
Le chiavi e i valori di intestazione devono essere conformi a RFC 7230 e non sono consentiti moduli obsoleti.
Tutte le chiavi di intestazione hanno caratteri minuscoli (per HTTP/2).
Alcune intestazioni sono unite. Quando sono presenti più istanze della stessa chiave di intestazione (ad esempio, Via), il bilanciatore del carico combina i relativi valori in un unico elenco separato da virgole per una singola chiave di intestazione. Vengono unite solo le intestazioni i cui valori possono essere rappresentati come elenco separato da virgole. Altre intestazioni, come Set-Cookie, non vengono mai unite.
Vengono aggiunte alcune intestazioni o vengono aggiunti valori. Media CDN aggiunge o modifica sempre determinate intestazioni, come Via e X-Forwarded-For.
Media CDN espande qualsiasi intestazione della risposta con una variabile supportata, anche se impostata dal client o dall'origine. Questo ti consente di impostare intestazioni dinamiche dal client (ad esempio un video player) o dall'infrastruttura di origine, oltre a configurare intestazioni personalizzate. Media CDN non espande le variabili sul percorso di richiesta.
Ad esempio, secondo le regole descritte in precedenza, le intestazioni X-Goog- e X-Amz- vengono mantenute e vengono usate in lettere minuscole.

Valori dello stato della cache

La variabile di intestazione {cdn_cache_status} può restituire più valori corrispondenti al livello di cache che ha pubblicato la risposta. Considera le seguenti linee guida per interpretare la variabile di intestazione {cdn_cache_status}:

Se l'intestazione contiene hit, i contenuti richiesti sono stati recuperati dalla cache.
Se l'intestazione contiene miss, il contenuto richiesto non è stato trovato in un nodo cache e deve essere recuperato da un nodo upstream.
Se l'intestazione contiene fetch, i contenuti richiesti sono stati recuperati dall'origine.
Se l'intestazione contiene uncacheable, i contenuti richiesti sono stati considerati non memorizzabili nella cache da alcuni o tutti i componenti dell'infrastruttura di memorizzazione nella cache.
- Se l'intestazione contiene anche hit o miss, i contenuti richiesti sono stati considerati non memorizzabili nella cache da alcuni componenti di memorizzazione nella cache e memorizzabili nella cache da altri.
- Se l'intestazione non contiene anche hit o miss, il contenuto richiesto è considerato non memorizzabile nella cache da tutti i componenti di memorizzazione nella cache e tutte le richieste per questi contenuti vengono recuperate dall'origine. Per assicurarti che i contenuti vengano memorizzati correttamente nella cache, esamina i requisiti dell'origine di Media CDN.

Intestazioni predefinite

Media CDN aggiunge le seguenti intestazioni di richiesta e risposta, rispettivamente, alle richieste dell'origine e alle risposte del client.

Titolo	Descrizione	Richiesta	Risposta
`x-request-id`	Un identificatore univoco per la richiesta specificata. Questo valore viene aggiunto anche al log delle richieste come `jsonPayload.requestId`, che consente di correlare una richiesta/risposta del client a una voce di log.		✔
`age`	Restituisce l'età dell'oggetto memorizzato nella cache (numero di secondi in cui è stato nella cache). In genere, l'età viene calcolata in base a quando l'oggetto è stato inizialmente memorizzato nella cache in una posizione cache long-tail (scudo). Le risposte senza un'intestazione `age` non vengono fornite dalla cache.		✔
`via`	Identifica Google come proxy intermedio. Questo valore è impostato come `1.1 google` e non può essere modificato.	✔	✔
`server`	È impostato come `Google-Edge-Cache`.		✔
`cdn-loop`	Identifica i loop, ad esempio, in cui l'host di origine è uguale all'host rivolto agli utenti (perimetrali). Un token `google` viene aggiunto all'intestazione in base a RFC 8586. Il token non può essere modificato.	✔
`forwarded`	La versione strutturata dell'intestazione `x-forwarded-for`. L'intestazione `forwarded` è definita in RFC 7239. Queste intestazioni consentono di identificare l'indirizzo IP del client che si connette quando il percorso contiene un proxy (o dei proxy). Ad esempio, se un client con indirizzo IP `192.0.2.60` si connette a Media CDN tramite HTTPS, l'intestazione `forwarded` viene compilata come segue: `forwarded: [for=192.0.2.60;proto=https]` Nel caso di più proxy lato client, il client connesso a Media CDN è l'ultimo indirizzo aggiunto nel valore dell'intestazione.	✔
`x-forwarded-for`	La versione standard non strutturata e di fatto dell'intestazione `forwarded`. I valori sono in genere separati da virgole. Entrambe le intestazioni vengono inviate in una richiesta per supportare origini legacy che potrebbero non essere a conoscenza dell'intestazione `forwarded`.	✔

Le chiavi di intestazione hanno lettere minuscole per le intestazioni di richiesta e di risposta, perché le chiavi di intestazione non fanno distinzione tra maiuscole e minuscole.

Altre intestazioni, tra cui la posizione del punto di presenza (POP) perimetrale e lo stato della cache (ad esempio hit e miss), possono essere aggiunte utilizzando le variabili di intestazione dinamiche.