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à che puoi utilizzare per mostrare contenuti localizzati.
Determina se una risposta è stata fornita dalla cache (completamente o in parte) dalla posizione della cache da cui sono state fornite.
Rimuovi, sostituisci o aggiungi alle intestazioni della richiesta e della risposta.

Puoi utilizzare le intestazioni anche per instradare le richieste a diverse principali. Se devi configurare più origini di condivisione delle risorse (CORS), configura un'istanza per ogni route.

Imposta intestazioni personalizzate

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

Per impostazione predefinita, i valori dell'intestazione aggiunti sono separati da virgole e aggiunti alla risposta o di richieste con gli stessi nomi di campo.

Per sovrascrivere i valori esistenti, imposta replace su true.

Il seguente esempio di .routing.pathMatchers[].routeRules[].headerAction mostra 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 il metodo {client_region}, che restituisce il paese (o la regione) associato con l'indirizzo IP del client.
Aggiunge un'intestazione x-downstream-cdn personalizzata alla richiesta utilizzando un stringa.
Rimuove due intestazioni interne.

Variabili di intestazione dinamiche

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

Intestazioni delle richieste che fanno parte del criterio della chiave di cache (cacheKeyPolicy.includedHeaderNames) può contenere una o più variabili personalizzate. Intestazioni delle richieste che contengono altri le 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 delle località (codice IATA dell'aeroporto più vicino) e gli stati di ciascun nodo 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 sono presenti elenco canonico di valori validi per questa variabile. I nomi delle città possono deve contenere lettere, numeri, spazi e i seguenti caratteri US-ASCII: !#$%&'*+-.^_`\|~.	✔		✔
`client_city_lat_long`	La latitudine e la longitudine della città da cui viene inviata la richiesta ha avuto origine, 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. Questo è un codice regione CLDR Unicode, come `US` o `FR`. Per la maggior parte dei paesi, questi codici corrispondono direttamente ISO-3166-2 codici.	✔	✔	✔
`client_region_subdivision`	La suddivisione, ad esempio provincia o stato, del paese associati all'indirizzo IP del client. Questa è una suddivisione CLDR Unicode ID, come `USCA` o `CAON`. Questi codici Unicode derivano dalle suddivisioni definite ISO-3166-2 standard.	✔	✔	✔
`client_rtt_msec`	Il tempo stimato di trasmissione andata e ritorno tra la CDN e la client HTTP(S), in millisecondi. Questo è il tempo di round trip ridotto (SRTT) misurato dallo stack TCP della CDN, per RFC 2988.	✔		✔
`device_request_type`	Il tipo di dispositivo utilizzato dal client. Questi sono i criteri valori: `DESKTOP`, `MOBILE`, `TABLET` `SMART_TV` `GAME_CONSOLE`, `WEARABLE`, e `UNDETERMINED`.	✔	✔
`original_request_id`	L'identificatore univoco assegnato alla richiesta che ha originariamente ha generato questa risposta. Compilato solo se diverso da `request_id` per le risposte memorizzate nella cache.			✔
`origin_name`	La risorsa `EdgeCacheOrigin` da cui è stata generata la risposta è stato inviato tramite proxy.			✔
`origin_request_header`	Riflette il valore dell'intestazione Origine nella richiesta di più origini Casi d'uso relativi alla condivisione delle risorse (CORS).			✔
`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, `EdgeCacheOrigin` la risorsa è rappresentata da `Google-Edge-Cache-Origin`.			✔
`tls_sni_hostname`	L'indicazione del nome del server (come definita RFC 6066), se fornito dal client durante l'handshake TLS o QUIC. Il nome host è convertito in minuscolo 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 dalla IANA Registro delle suite di crittografia TLS, 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 criteri valori: `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 richiesta e risposta esistenti vengono conservate, ad eccezione degli che vengono rimossi:
- X-User-IP
- Qualsiasi intestazione con X-Google o X-GFE
Le chiavi e i valori di intestazione devono essere conformi alla specifica RFC 7230, con moduli obsoleti non consentiti.
Tutte le chiavi di intestazione hanno caratteri minuscoli (per HTTP/2).
Alcune intestazioni sono unite. Quando sono presenti più istanze dello stesso chiave di intestazione (ad esempio, Via), il bilanciatore del carico combina i propri valori in un unico elenco separato da virgole per una singola chiave di intestazione. Solo le intestazioni i cui valori possono essere rappresentati come un elenco separato da virgole vengono uniti. 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, ad esempio Via e X-Forwarded-For.
Media CDN espande qualsiasi intestazione della risposta con un , anche se impostata dal client o dall'origine. Ciò consente puoi impostare intestazioni dinamiche dal client (ad esempio un video player) o dall'origine dell'infrastruttura, oltre a configurare intestazioni personalizzate. Media CDN non espande le variabili sul percorso di richiesta.
Ad esempio, in base alle regole descritte in precedenza, X-Goog- e Le intestazioni X-Amz- vengono mantenute e sono minuscole.

Valori dello stato della cache

La variabile di intestazione {cdn_cache_status} può restituire più valori corrispondente al livello di cache che ha fornito la risposta. Considera le seguenti linee guida per l'interpretazione della variabile di intestazione {cdn_cache_status}:

Se l'intestazione contiene hit, i contenuti richiesti sono stati recuperati dalla cache.
Se l'intestazione contiene miss, i contenuti richiesti non erano trovato in un nodo cache e che doveva essere recuperato da un nodo upstream.
Se l'intestazione contiene fetch, i contenuti richiesti sono stati recuperato dall'origine.
Se l'intestazione contiene uncacheable, i contenuti richiesti sono stati considerati non memorizzabili nella cache da alcuni o tutti i componenti della memorizzazione nella cache dell'infrastruttura.
- Se l'intestazione contiene anche hit o miss, il valore il contenuto richiesto era considerato non memorizzabile nella cache da alcuni componenti di memorizzazione nella cache e memorizzabili nella cache da altri.
- Se l'intestazione non contiene anche hit o miss, i contenuti richiesti sono considerati non memorizzabili 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 nella cache in modo appropriato, consulta l'origine di Media CDN requisiti.

Intestazioni predefinite

Media CDN aggiunge le seguenti intestazioni di richiesta e risposta richieste di origine e risposte del client.

Intestazione	Descrizione	Richiesta	Risposta
`x-request-id`	Un identificatore univoco per la richiesta specificata. Questo valore viene aggiunto anche nel log delle richieste come `jsonPayload.requestId`, 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 per cui è stato nella cache). L'età viene generalmente calcolata in base a quando inizialmente era memorizzato nella cache in una posizione cache long-tail (scudo). Le risposte senza un'intestazione `age` non vengono pubblicate da .		✔
`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, dove l'host di origine è come l'host rivolto agli utenti (perimetrali). Un token `google` viene aggiunto all'intestazione come da RFC 8586. Il token non può essere modificato.	✔
`forwarded`	La versione strutturata dell'intestazione `x-forwarded-for`. L'intestazione `forwarded` è definito nel documento RFC 7239. Queste intestazioni consentono di identificare l'indirizzo IP della connessione se nel percorso sono presenti uno o più proxy. Ad esempio, se un il client con indirizzo IP `192.0.2.60` si connette Media CDN tramite HTTPS, `forwarded` l'intestazione viene compilata come segue: `forwarded: [for=192.0.2.60;proto=https]` Nel caso di più proxy lato client, il client che si è connesso Media CDN è l'ultimo indirizzo aggiunto nell'intestazione valore.	✔
`x-forwarded-for`	La versione standard non strutturata e di fatto 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 risposta. non fanno distinzione tra maiuscole e minuscole.

Altre intestazioni, inclusa la posizione del punto di presenza (POP) perimetrale e la cache (ad esempio hit e miss), può essere aggiunto utilizzando variabili di intestazione dinamiche.