Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Definisci intestazioni personalizzate

Media CDN ti consente di specificare intestazioni della richiesta e della risposta personalizzate.

Le intestazioni personalizzate ti consentono di:

Restituire dati geografici sul client, come paese, regione o città, che puoi utilizzare per mostrare contenuti localizzati.
Determinare se una risposta è stata fornita dalla cache (in tutto o in parte) e da quale località della cache.
Rimuovere, sostituire o aggiungere intestazioni della richiesta e della risposta.

Impostare intestazioni personalizzate

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

Imposta le intestazioni della richiesta personalizzate per route all'inizio del percorso di elaborazione della CDN, prima delle decisioni di memorizzazione nella cache. Ad esempio, se imposti un'intestazione cache-control come intestazione personalizzata per route, influisce sul comportamento di memorizzazione nella cache nella CDN.

Per impostazione predefinita, i valori delle intestazioni aggiunti 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.

gcloud e YAML

Per elencare la configurazione YAML per la risorsa EdgeCacheService, utilizza il seguente comando:

gcloud edge-cache services describe prod-media-service

La sezione .routing.pathMatchers[].routeRules[].headerAction mostra le intestazioni da aggiungere e rimuovere:

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"

Terraform

Il seguente snippet Terraform mostra una regola di route con intestazioni personalizzate.

route_rule {
  description = "video routes"
  priority    = 1
  match_rule {
    prefix_match = "/video/"
  }
  origin = google_network_services_edge_cache_origin.default.name
  header_action {
    response_header_to_add {
      # Return the country (or region) associated with the client's IP address.
      header_name  = "client-geo"
      header_value = "{client_region}"
      replace      = true
    }
    request_header_to_add {
      # Inform the upstream origin server that the request is from Media CDN.
      header_name  = "x-downstream-cdn"
      header_value = "Media CDN"
    }
    response_header_to_remove {
      header_name = "X-User-ID"
    }
    response_header_to_remove {
      header_name = "X-Other-Internal-Header"
    }
  }
}

Questo esempio esegue le seguenti operazioni:

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

Per configurare intestazioni personalizzate specifiche dell'origine, consulta Configurare le modifiche dell'host o delle intestazioni specifiche dell'origine.

Variabili di intestazione dinamiche

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

Le intestazioni della richiesta che fanno parte della policy della chiave cache (cacheKeyPolicy.includedHeaderNames) possono contenere una o più variabili personalizzate. Le intestazioni della richiesta che contengono altre variabili dinamiche non possono far parte della chiave cache.

Variabile	Descrizione	Supportato per le intestazioni della richiesta	Supportato per le intestazioni della richiesta in una chiave cache	Supportato per le intestazioni della risposta
`cdn_cache_status`	Un elenco separato da virgole delle località (codice IATA dell'aeroporto più vicino) e degli stati di ogni nodo cache nel percorso 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 US-ASCII e i seguenti caratteri: !#$%&'*+-.^_`\|~.	✔		✔
`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 Unicode CLDR, ad esempio `US` o `FR`. Per la maggior parte dei paesi, questi codici corrispondono direttamente a codici ISO-3166-1 alpha-2.	✔	✔	✔
`client_region_subdivision`	La suddivisione, ad esempio la provincia o lo stato, del paese associato all'indirizzo IP del client. Si tratta di un ID di suddivisione Unicode CLDR, ad esempio `USCA` o `CAON`. Questi codici Unicode derivano dalle suddivisioni definite dallo standard ISO-3166-2.	✔	✔	✔
`client_rtt_msec`	Il tempo di trasmissione di round trip stimato tra la CDN e il client HTTP(S), in millisecondi. Si tratta del parametro del tempo di round trip uniforme (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`.	✔	✔
`host`	Il nome host e il numero di porta del server a cui è stata inviata originariamente la richiesta del client corrispondenti al valore dell' `Host` intestazione della richiesta per HTTP/1.1 o alla `:authority` pseudo-header per HTTP/2.	✔		✔
`original_request_id`	L'identificatore univoco assegnato alla richiesta che ha generato originariamente questa risposta. Viene 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 di condivisione delle risorse tra origini (CORS).			✔
`proxy_status`	Un elenco di proxy HTTP intermedi nel percorso della risposta. Il valore è definito nel documento RFC 9209. Una risorsa `EdgeCacheService` è rappresentata da `Google-Edge-Cache`. Se la risposta è stata recuperata dall'origine, una `EdgeCacheOrigin` risorsa è 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 viene rimosso qualsiasi punto finale.	✔		✔
`tls_version`	La versione TLS negoziata tra il client e il bilanciatore del carico durante l'handshake SSL. I valori possibili includono `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 delle suite di crittografia TLS IANA, ad esempio `TLS_RSA_WITH_AES_128_GCM_SHA256`. Questo valore è vuoto per le connessioni client QUIC e non crittografate.	✔		✔
`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`.	✔	✔

Le seguenti considerazioni si applicano alle variabili personalizzate:

Le intestazioni della richiesta e della risposta esistenti vengono mantenute, ad eccezione delle seguenti, che vengono rimosse:
- X-User-IP
- Qualsiasi intestazione con X-Google o X-GFE
Le chiavi e i valori delle intestazioni devono essere conformi al documento RFC 7230, con forme obsolete non consentite.
Tutte le chiavi delle intestazioni sono in minuscolo (per HTTP/2).
Alcune intestazioni vengono 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 un elenco separato da virgole. Altre intestazioni, come Set-Cookie, non vengono mai unite.
Alcune intestazioni vengono aggiunte o i valori vengono aggiunti a queste. Media CDN aggiunge o modifica sempre determinate intestazioni, ad esempio X-Forwarded-For.
Media CDN espande qualsiasi intestazione della risposta con una variabile supportata, anche se impostata dal client o dall'origine. In questo modo, puoi impostare intestazioni dinamiche dal client (ad esempio un video player) o dall'infrastruttura di origine, oltre a configurare intestazioni personalizzate.
Ad esempio, in base alle regole descritte in precedenza, le intestazioni X-Goog- e X-Amz- vengono mantenute e convertite in minuscolo.

Valori dello stato della cache

La variabile di intestazione {cdn_cache_status} può restituire più valori corrispondenti al livello di cache che ha fornito la risposta. Tieni presente 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, i contenuti richiesti non sono stati trovati in un nodo cache e dovevano essere recuperati 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 da 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, i contenuti richiesti sono stati 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, esamina i requisiti dell'origineMedia CDN.

Intestazioni predefinite

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

Intestazione	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 ti consente di correlare una richiesta/risposta del client a una voce di log.		✔
`age`	Restituisce l'età dell'oggetto memorizzato nella cache (il numero di secondi in cui è stato in cache). L'età viene in genere calcolata in base al momento in cui l' oggetto è stato inizialmente memorizzato nella cache in una località della cache long-tail (shield). Le risposte senza un'intestazione `age` non vengono fornite dalla cache.		✔
`server`	È impostato su `Google-Edge-Cache`.		✔
`cdn-loop`	Identifica i loop, ad esempio quando l'host di origine è lo stesso dell'host rivolto all'utente (edge). Un token di `google` viene aggiunto all'intestazione in base al documento RFC 8586. Il token non può essere modificato.	✔
`forwarded`	La versione strutturata dell'intestazione `x-forwarded-for`. L'intestazione `forwarded` è definita nel documento RFC 7239. Queste intestazioni ti consentono di identificare l'indirizzo IP del client di connessione quando nel percorso è presente uno o più 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 che si è connesso a Media CDN è l'ultimo indirizzo aggiunto nel valore dell'intestazione.	✔
`x-forwarded-for`	La versione non strutturata e standard di fatto dell' `forwarded` intestazione. I valori sono in genere separati da virgole. Entrambe le intestazioni vengono inviate in una richiesta per supportare le origini legacy che potrebbero non essere a conoscenza dell'intestazione `forwarded`.	✔

Le chiavi delle intestazioni vengono convertite in minuscolo sia per le intestazioni della richiesta sia per quelle della risposta, perché le chiavi delle intestazioni non fanno distinzione tra maiuscole e minuscole.

È possibile aggiungere altre intestazioni, tra cui la località del punto di presenza (PoP) edge e lo stato della cache (ad esempio hit e miss), utilizzando le variabili di intestazione dinamiche.

Definisci intestazioni personalizzate Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.