Panoramica della memorizzazione nella cache

Una risposta memorizzabile nella cache è una risposta HTTP che può essere archiviata e recuperata rapidamente da Cloud CDN, consentendo tempi di caricamento più rapidi. Non tutte le risposte HTTP sono memorizzabili nella cache.

Modalità cache

Con le modalità cache puoi controllare i fattori che determinano se Cloud CDN memorizza o meno i tuoi contenuti nella cache.

Cloud CDN offre tre modalità cache che determinano come le risposte vengono memorizzate nella cache, se Cloud CDN rispetta o meno le istruzioni di memorizzazione nella cache inviate dall'origine e come vengono applicate le durate (TTL) della cache.

Le modalità cache disponibili sono riportate nella tabella seguente:

Modalità cache Comportamento
CACHE_ALL_STATIC Memorizza automaticamente nella cache le risposte con esito positivo con contenuti statici che altrimenti non sono memorizzabili nella cache. Anche le risposte provenienti dall'origine che impostano istruzioni di memorizzazione nella cache valide vengono memorizzate nella cache.

Questo comportamento è predefinito per i backend con Cloud CDN abilitato creati utilizzando Google Cloud CLI o l'API REST.
USE_ORIGIN_HEADERS Richiede risposte con esito positivo provenienti dall'origine per impostare istruzioni di memorizzazione nella cache e intestazioni di memorizzazione nella cache valide. Le risposte con esito positivo senza queste istruzioni vengono inoltrate dall'origine.
FORCE_CACHE_ALL Memorizza incondizionatamente le risposte con esito positivo nella cache, ignorando qualsiasi istruzione di memorizzazione nella cache impostata dall'origine. Questa modalità non è adatta se il backend gestisce contenuti privati per ciascun utente (utente identificabile), come contenuti HTML dinamici o risposte dell'API.

Le risposte di errore potrebbero essere memorizzate nella cache anche in assenza di istruzioni di memorizzazione nella cache valide.

Prima di impostare la modalità cache su FORCE_CACHE_ALL, tieni presenti i seguenti comportamenti:

  • Per URL firmati o cookie firmati, FORCE_CACHE_ALL sostituisce la durata massima specificata tramite l'impostazione Durata massima delle voci di cache nella console Google Cloud o l'opzione gcloud --signed-url-cache-max-age.

  • FORCE_CACHE_ALL modifica la durata (TTL) di qualsiasi contenuto precedentemente memorizzato nella cache. Questa modifica può far sì che alcune voci precedentemente considerate aggiornate (perché avevano TTL più lunghi specificati dalle intestazioni dell'origine) vengano considerate scadute e che alcune voci precedentemente considerate scadute vengano considerate aggiornate.

  • FORCE_CACHE_ALL ignora le istruzioni di memorizzazione nella cache (Cache-Control ed Expires), ma non ignora altre intestazioni della risposta dell'origine. In particolare, un'intestazione Vary potrebbe disattivare la memorizzazione nella cache anche se la modalità cache è FORCE_CACHE_ALL. Per saperne di più, consulta Intestazioni Vary.

Per istruzioni per la configurazione, consulta Impostazione della modalità cache.

Contenuti statici

I contenuti statici sono contenuti sempre uguali, anche se vengono visualizzati da utenti diversi. Il CSS che utilizzi per definire lo stile del tuo sito, il codice JavaScript per fornire interattività, video e contenuti con immagini in genere non cambiano per ogni utente per un determinato URL (chiave cache) e quindi traggono vantaggio dalla memorizzazione nella cache nell'intera rete edge globale di Cloud CDN.

Quando imposti la modalità cache su CACHE_ALL_STATIC e una risposta non ha istruzioni di memorizzazione nella cache esplicite nelle intestazioni Cache-Control o Expires, Cloud CDN memorizza nella cache automaticamente la risposta per quanto segue:

  • Asset web, inclusi CSS (text/css), JavaScript (application/javascript) e tutti i caratteri web, incluso WOFF2 (font/woff2)
  • Immagini, inclusi i formati JPEG (image/jpg) e PNG (image/png)
  • Video, inclusi i formati H.264, H.265 e MP4 (video/mp4)
  • File audio, inclusi i formati MP3 (audio/mpeg) e MP4 (audio/mp4)
  • Documenti formattati, inclusi i file PDF (application/pdf)

La tabella seguente offre un riepilogo.

Categoria Tipi MIME
Asset web text/css text/ecmascript text/javascript application/javascript
Caratteri Qualsiasi Content-Type corrispondente a font/*
Immagini Qualsiasi Content-Type corrispondente a image/*
Video Qualsiasi Content-Type corrispondente a video/*
Audio Qualsiasi Content-Type corrispondente a audio/*
Tipi di documenti formattati application/pdf e application/postscript

Cloud CDN esamina l'intestazione della risposta HTTP Content-Type, che riflette il tipo MIME dei contenuti forniti.

Tieni presente quanto segue:

  • Il software server web dell'origine deve impostare Content-Type per ogni risposta. Molti server web, tra cui NGINX, Varnish e Apache, impostano automaticamente l'intestazione Content-Type.

  • Cloud Storage imposta automaticamente l'intestazione Content-Type quando utilizzi la console Google Cloud o Google Cloud CLI per caricare contenuti.

  • Cloud Storage fornisce sempre un'intestazione Cache-Control a Cloud CDN. Se non viene scelto esplicitamente alcun valore, invia un valore predefinito. Di conseguenza, tutte le risposte con esito positivo di Cloud Storage vengono memorizzate nella cache in base ai valori predefiniti di Cloud Storage, a meno che tu non modifichi esplicitamente i metadati di controllo cache per gli oggetti in Cloud Storage o utilizzi la modalità FORCE_CACHE_ALL per ignorare i valori inviati da Cloud Storage.

  • Se vuoi memorizzare nella cache i tipi di contenuti text/html e application/json, devi impostare intestazioni Cache-Control esplicite nella risposta, facendo attenzione a evitare di memorizzare accidentalmente nella cache i dati di un utente e fornirli a tutti gli utenti.

Se una risposta è memorizzabile nella cache in base al tipo MIME, ma ha un'intestazione della risposta Cache-Control con valore private o no-store oppure un'intestazione Set-Cookie, non viene memorizzata nella cache. Per saperne di più, consulta le regole di memorizzazione nella cache.

Altri tipi di contenuti, come HTML (text/html) e JSON (application/json), non vengono memorizzati nella cache per impostazione predefinita per le risposte con esito positivo. Questi tipi di risposte sono in genere dinamici (per utente). Alcuni esempi includono carrelli degli acquisti, pagine di prodotto con personalizzazione per l'utente e risposte API autenticate. Tuttavia, se abilitata, la memorizzazione nella cache negativa può comunque causarne la memorizzazione nella cache per determinati codici di stato.

Cloud CDN non utilizza le estensioni dei file nel percorso URL per determinare se una risposta può essere memorizzata nella cache, perché molte risposte valide memorizzabili nella cache non vengono riflesse negli URL.

Contenuti memorizzabili nella cache

Cloud CDN memorizza nella cache le risposte che soddisfano tutti i requisiti di questa sezione. Alcuni di questi requisiti sono specificati dalla RFC 7234, mentre altri sono specifici di Cloud CDN.

Cloud CDN potrebbe modificare periodicamente l'insieme esatto di condizioni in base alle quali memorizza i contenuti nella cache. Se vuoi impedire esplicitamente a Cloud CDN di memorizzare nella cache i tuoi contenuti, segui le linee guida riportate nella RFC 7234 per determinare come specificare una risposta con garanzia di non memorizzazione nella cache. Consulta anche la sezione Contenuti non memorizzabili nella cache in base alle intestazioni dell'origine.

Cloud CDN memorizza le risposte nella cache se sono soddisfatte tutte le seguenti condizioni.

Attributo Requisito
Fornito da Servizio di backend, bucket di backend o un backend esterno con Cloud CDN abilitato
In risposta a Richiesta GET
Codice di stato

200, 203, 204, 206, 300, 301, 302, 307, 308, 404, 405, 410, 421, 451 o 501.
Aggiornamento

La risposta ha un'intestazione Cache-Control con un'istruzione max-age o s-maxage oppure un'intestazione Expires con un timestamp futuro.

Per le risposte memorizzabili nella cache senza una durata (ad esempio, con no-cache), l'istruzione public deve essere fornita in modo esplicito.

Con la modalità cache CACHE_ALL_STATIC, se non sono presenti istruzioni di aggiornamento, una risposta con esito positivo e tipo di contenuto statico è comunque idonea alla memorizzazione nella cache.

Con la modalità cache FORCE_CACHE_ALL, qualsiasi risposta con esito positivo è idonea alla memorizzazione nella cache. Ciò potrebbe comportare la memorizzazione nella cache di contenuti privati per utente. Devi impostare FORCE_CACHE_ALL solo sui backend che non forniscono contenuti privati o dinamici, come i bucket Cloud Storage.

Se è abilitata la memorizzazione nella cache negativa e il codice di stato corrisponde a un codice per cui la memorizzazione nella cache negativa specifica un TTL, la risposta è idonea alla memorizzazione nella cache, anche senza istruzioni sullo stato di aggiornamento esplicite.
Contenuti

Per le origini HTTP/1, la risposta deve contenere un'intestazione Content-Length, Content-Range o Transfer-Encoding: chunked valida.

Per le origini che utilizzano versioni più avanzate del protocollo HTTP (HTTP/2 e successive), non è necessario che la risposta abbia queste intestazioni.
Dimensioni Valore minore o uguale alle dimensioni massime.

Per le risposte con dimensioni comprese tra 10 MiB e 100 GiB, consulta i vincoli di memorizzazione nella cache aggiuntivi descritti in Richieste di intervalli di byte.

Per i bucket di backend Cloud Storage, segui questi suggerimenti aggiuntivi:

Per impostazione predefinita, quando un oggetto è pubblico e non specifica metadati Cache-Control, Cloud Storage assegna un'intestazione Cache-Control: public, max-age=3600 all'oggetto. Puoi impostare valori diversi utilizzando i metadati Cache-Control.

Per un esempio che mostra come configurare un bilanciatore del carico delle applicazioni esterno con un bucket di backend, consulta Configurazione di Cloud CDN con un bucket di backend.

Dimensione massima

Cloud CDN applica una dimensione massima per ogni risposta. Qualsiasi risposta con un corpo più grande della dimensione massima non viene memorizzata nella cache, ma viene comunque inviata al client.

La dimensione massima varia a seconda che il server di origine supporti le richieste di intervalli di byte.

Il server di origine supporta le richieste di intervalli di byte Il server di origine non supporta le richieste di intervalli di byte
100 GiB (107.374.182.400 byte) 10 MiB (10.485.760 byte)

Quasi tutti i server web moderni (inclusi NGINX, Apache e Varnish) supportano le richieste di intervalli di byte.

Contenuti non memorizzabili nella cache in base alle intestazioni dell'origine

Esistono controlli che bloccano la memorizzazione nella cache delle risposte. Cloud CDN potrebbe modificare periodicamente l'insieme esatto di condizioni in base alle quali memorizza i contenuti nella cache; di conseguenza, se vuoi impedire esplicitamente a Cloud CDN di memorizzare i tuoi contenuti nella cache, segui le linee guida nello standard (RFC 7234) per determinare come specificare una risposta con garanzia di non memorizzazione nella cache.

Cloud CDN non memorizza nella cache una risposta se non soddisfa i requisiti per i contenuti memorizzabili nella cache o se si verifica una delle seguenti condizioni.

Attributo Requisito
Fornito da Servizio di backend o backend esterno senza Cloud CDN abilitato
Cookie Ha un'intestazione Set-Cookie
Intestazione Vary Ha un valore diverso da Accept, Accept-Encoding, Access-Control-Request-Headers, Access-Control-Request-Method, Origin, Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site, X-Goog-Allowed-Resources, X-Origin o una delle intestazioni configurate per far parte delle impostazioni della chiave cache.
Istruzione della risposta La risposta ha un'intestazione Cache-Control con l'istruzione no-store o private (a meno che non venga utilizzata la modalità cache FORCE_CACHE_ALL, nel qual caso l'intestazione Cache-Control viene ignorata).
Istruzione della richiesta La richiesta ha un'istruzione Cache-Control: no-store
Autorizzazione della richiesta La richiesta ha un'intestazione Authorization, a meno che non venga sostituita da Cache-Control della risposta.
Dimensioni Maggiori della dimensione massima

Se è presente Cache-Control: no-store o private, ma i contenuti sono ancora memorizzati nella cache, il motivo è uno dei seguenti:

  • È configurata la firma dell'URL.
  • La modalità cache di Cloud CDN è impostata per forzare la memorizzazione nella cache di tutte le risposte.

Impedisci la memorizzazione nella cache

Per impedire la memorizzazione di informazioni private nelle cache Cloud CDN, segui questi passaggi:

  1. Assicurati che la modalità cache di Cloud CDN non sia impostata su FORCE_CACHE_ALL, che memorizza nella cache in modo incondizionato tutte le risposte con esito positivo.
  2. Includi un'intestazione Cache-Control: private nelle risposte che non devono essere memorizzate nelle cache Cloud CDN oppure un'intestazione Cache-Control: no-store nelle risposte che non devono essere memorizzate in alcuna cache, neanche quella di un browser web.
  3. Non firmare gli URL che forniscono l'accesso a informazioni private. Quando l'accesso ai contenuti avviene utilizzando un URL firmato, i contenuti sono potenzialmente idonei alla memorizzazione nella cache indipendentemente dalle istruzioni Cache-Control nella risposta.
  4. Per le richieste dell'origine (riempimento della cache) che includono l'intestazione della richiesta Authorization, Cloud CDN memorizza nella cache solo le risposte che includono le istruzioni di controllo cache public, must-revalidate o s-maxage quando la modalità cache è impostata su USE_ORIGIN_HEADERS o CACHE_ALL_STATIC. In questo modo si evita la memorizzazione accidentale nella cache di contenuti per utente e di contenuti che richiedono l'autenticazione. La modalità cache FORCE_CACHE_ALL non presenta questa limitazione.

Intestazioni delle risposte personalizzate

Con le intestazioni delle risposte personalizzate puoi specificare le intestazioni che il bilanciatore del carico delle applicazioni classico aggiunge alle risposte inviate tramite proxy. Le intestazioni delle risposte personalizzate ti consentono di riflettere lo stato della cache sui tuoi client, sui dati geografici dei client e sulle tue intestazioni delle risposte statiche.

Per istruzioni, consulta Configura intestazioni delle risposte personalizzate.

Chiavi cache

Ogni voce della cache in una cache Cloud CDN è identificata da una chiave cache. Quando una richiesta entra nella cache, questa converte l'URI della richiesta in una chiave cache e la confronta con le chiavi delle voci memorizzate nella cache. Se trova una corrispondenza, la cache restituisce l'oggetto associato a quella chiave.

Per i servizi di backend, Cloud CDN utilizza per impostazione predefinita l'URI della richiesta completo come chiave cache. Ad esempio, https://example.com/images/cat.jpg è l'URI completo di una richiesta specifica per l'oggetto cat.jpg. Questa stringa viene utilizzata come chiave cache predefinita. Viene individuata una corrispondenza solo per le richieste con questa stringa esatta. Le richieste per http://example.com/images/cat.jpg o https://example.com/images/cat.jpg?user=user1 non corrispondono.

Per i bucket di backend, l'impostazione predefinita prevede che la chiave cache sia costituita dall'URI senza protocollo o host. Per impostazione predefinita, solo i parametri di query noti a Cloud Storage sono inclusi nella chiave cache (ad esempio, "generation").

Pertanto, per un determinato bucket di backend, i seguenti URI vengono risolti nello stesso oggetto memorizzato nella cache:

  • http://example.com/images/cat.jpg
  • https://example.com/images/cat.jpg
  • https://example.com/images/cat.jpg?user=user1
  • http://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2
  • https://media.example.com/images/cat.jpg
  • https://www.example.com/images/cat.jpg

Puoi cambiare le parti dell'URI utilizzate nella chiave cache. Sebbene il nome file e il percorso debbano sempre far parte della chiave, quando personalizzi la chiave cache puoi includere o omettere qualsiasi combinazione di protocollo, host o stringa di query. Utilizzo delle chiavi cache descrive come personalizzare le chiavi cache.

Parte dell'URI Personalizzazione URL di esempio con la stessa chiave cache
Protocollo Ometti il protocollo dalla chiave cache.
  • https://example.com/images/cat.jpg
  • http://example.com/images/cat.jpg
Host Ometti l'host dalla chiave cache.
  • https://example.com/images/cat.jpg
  • https://example2.com/images/cat.jpg
Stringa di query

Ometti la stringa di query dalla chiave cache.

Ometti o includi selettivamente parti della stringa di query.
  • https://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2

Oltre a omettere o includere l'intera stringa di query, puoi utilizzare parti della stringa di query tramite elenchi di inclusione ed esclusione.

Elenco di inclusione delle stringhe di query

Puoi controllare in modo selettivo quali parametri della stringa di query vengono incorporati da Cloud CDN nelle chiavi cache. Ad esempio, se crei un elenco di inclusione di user, https://example.com/images/cat.jpg?user=user1&color=blue crea una chiave cache https://example.com/images/cat.jpg?user=user1 che corrisponde anche a https://example.com/images/cat.jpg?user=user1&color=red.

Per utilizzare questa opzione, devi includere la stringa di query, specificare un elenco di inclusione non vuoto e non specificare un elenco di esclusione.

Elenco di inclusione della stringhe di query per le chiavi cache di Cloud Storage

L'inclusione dei parametri di query URL nelle chiavi cache per i bucket Cloud Storage consente di supportare il busting della cache. Il busting della cache consente a un utente di recuperare una nuova versione del file caricato, anche se la versione precedente è ancora validamente memorizzata nella cache in base all'impostazione del TTL.

Puoi utilizzare un elenco di inclusione con i parametri della stringa di query nella chiave cache utilizzata per fornire le risposte da un bucket di backend. Sebbene Cloud Storage non pubblichi contenuti o percorsi diversi in base ai parametri di query, puoi scegliere di includere parametri che ti consentono di eseguire il busting della cache dei contenuti statici archiviati nei bucket Cloud Storage.

Ad esempio, puoi aggiungere un parametro di query ?version=VERSION o ?hash=HASH basato sui contenuti sottostanti. Ciò limita la necessità di annullare in modo proattivo la validità dei contenuti ed è in linea con i moderni workflow di sviluppo web, in cui i framework web e gli URL utilizzano un hash dei contenuti per evitare di fornire oggetti scaduti nei vari deployment.

Poiché l'inclusione dei parametri di query nella chiave cache viene attivata solo esplicitamente, Cloud CDN non supporta l'esclusione dei parametri di query da una chiave cache per un bucket di backend.

Elenco di esclusione della stringa di query

Puoi controllare in modo selettivo quali parametri della stringa di query vengono ignorati da Cloud CDN utilizzando un elenco di esclusione. Ad esempio, se crei un elenco di esclusione per user, nella chiave cache vengono utilizzati tutti i parametri della stringa di query tranne user.

Con l'elenco di esclusione configurato e https://example.com/images/cat.jpg?user=user1&color=blue come input, Cloud CDN crea una chiave cache https://example.com/images/cat.jpg?color=blue che corrisponde anche a https://example.com/images/cat.jpg?user=user2&color=blue, ma non a https://example.com/images/cat.jpg?user=user1&color=red.

Per utilizzare questa opzione, devi includere la stringa di query, specificare un elenco di esclusione non vuoto e non specificare un elenco di inclusione.

Ordine dei parametri di query

La chiave cache generata non dipende dall'ordine dei parametri di query.

Ad esempio, i seguenti parametri di query generano la stessa chiave cache:

  • info=123&variant=13e&geography=US
  • geography=US&variant=13e&info=123

Impostazioni delle intestazioni HTTP e dei cookie HTTP

Puoi migliorare le percentuali di successo della cache e l'offload dell'origine con le seguenti impostazioni di configurazione della chiave cache:

  • Per servizi e bucket di backend: utilizza le intestazioni HTTP come parte delle chiavi cache includendo le intestazioni denominate nella configurazione della chiave cache.
  • Solo per servizi di backend: utilizza i cookie HTTP denominati come chiavi cache, ad esempio per i test A/B (multivariati), le release canary e scenari simili.

Le richieste che includono intestazioni HTTP o cookie HTTP aggiuntivi nella richiesta vengono memorizzate nella cache alla terza richiesta in una posizione della cache per la chiave cache in questione. In questo modo si riduce l'impatto sulle percentuali di eliminazioni dalla cache di valori di intestazioni o cookie con cardinalità elevata. In circostanze e condizioni di traffico utente normali, questo non dovrebbe risultare evidente e contribuisce a garantire che i contenuti popolari rimangano memorizzati nella cache.

Includi intestazioni della richiesta

Per memorizzare nella cache altre varianti di una risposta, puoi includere intestazioni della richiesta aggiuntive nella chiave cache.

Alcune intestazioni non sono consentite nelle chiavi cache perché in genere hanno una cardinalità molto elevata. Nella maggior parte dei casi, i valori di queste intestazioni sono univoci per utente (Cookie, Authorization) o hanno migliaia di valori probabili (Referer, User-Agent, Accept). Ad esempio, l'intestazione User-Agent può avere oltre 5000 valori univoci data la grande varietà di browser, dispositivi utente e sistemi operativi. Questi tipi di intestazioni avrebbero un impatto negativo grave sulla percentuale di successi della cache.

Sono accettati solo nomi di campi dell'intestazione HTTP validi in base alla RFC 7230. I nomi dei campi dell'intestazione non fanno distinzione tra maiuscole e minuscole e i duplicati vengono rifiutati.

Facoltativamente, puoi configurare il server di origine in modo che includa le intestazioni della richiesta della chiave cache configurate nella risposta Vary. Non è obbligatorio per Cloud CDN, ma può essere utile per le cache downstream. Per saperne di più, consulta Intestazioni Vary.

Cloud CDN non consente l'inclusione delle seguenti intestazioni nell'elenco delle intestazioni:

  • Accept
  • Accept-Encoding
  • Authority, perché questo valore è controllato dalla configurazione (cdnPolicy.includeHost)
  • Authorization, in genere per singolo utente come nei token OAuth Bearer
  • CDN-Loop
  • Connection
  • Content-MD5
  • Content-Type
  • Cookie
  • Date
  • Forwarded, spesso per singolo client o proxy
  • From
  • Host, perché questo valore è controllato dalla configurazione (cdnPolicy.includeHost)
  • If-Match, If-Modified-Since o If-None-Match
  • Origin
  • Proxy-Authorization
  • Range
  • Referer (o Referrer)
  • User-Agent
  • Want-Digest
  • X-CSRFToken e X-CSRF-Token come utilizzati da Django e Ruby on Rails
  • X-Forwarded-For, spesso per singolo client o proxy
  • X-User-IP
  • Qualsiasi intestazione che inizia con quanto segue:
    • Access-Control-, ad esempio Access-Control-Request-Headers e Access-Control-Request-Method
    • Sec-Fetch-
    • Sec-GFE-
    • Sec-Google-
    • X-Amz-
    • X-GFE-
    • X-Goog-
    • X-Google-

Utilizza variabili personalizzate con le intestazioni della richiesta

Le chiavi cache sono utili quando devi pubblicare contenuti in modo diverso in base al dispositivo e alla località di ogni utente. Ad esempio, puoi consentire a un sito web adattabile di mostrare le immagini appropriate agli utenti che visualizzano i contenuti in base al tipo di dispositivo o impostare una lingua predefinita utile in base alla loro località. Puoi definire le chiavi cache utilizzando intestazioni della richiesta personalizzate e variabili personalizzate.

Per utilizzare variabili personalizzate con le intestazioni della richiesta:

  1. Definisci un'intestazione della richiesta personalizzata per il tuo servizio di backend. Includi una o più variabili per il valore dell'intestazione della richiesta personalizzata.
  2. Aggiorna la chiave cache per utilizzare l'intestazione della richiesta personalizzata.

Per Cloud CDN, puoi utilizzare solo le seguenti variabili quando definisci intestazioni che sono sia intestazioni della richiesta personalizzate sia intestazioni della chiave cache:

  • device_request_type
  • user_agent_family
  • client_region
  • client_region_subdivision

Cloud CDN limita le variabili per contribuire a mantenere le prestazioni della cache. Ciò è analogo ai limiti delle intestazioni che possono essere utilizzate come chiavi cache.

Ad esempio, se potessi specificare X-Lat-Long:{client_city_lat_long} come intestazione della richiesta personalizzata e poi aggiungere X-Lat-Long al tuo insieme di intestazioni della chiave cache, Cloud CDN tenterebbe di memorizzare nella cache una copia della risposta per ogni valore di client_city_lat_long. Ciò comporterebbe un uso eccessivo della cache, il flush non necessario dei contenuti e una minore opportunità di restituire successi della cache.

Per questi motivi, le variabili con cardinalità elevata non sono incluse nell'elenco delle variabili utilizzate per definire le intestazioni della richiesta personalizzate e, successivamente, le chiavi cache.

Stesse intestazioni con valori diversi

Supponiamo che l'utente invii più intestazioni con lo stesso nome e valori diversi, ad esempio:

My-Header: Value1
My-Header: Value2

In questo caso, Cloud CDN modifica la richiesta presupponendo che l'intestazione debba seguire la convenzione standard che consente ad alcune intestazioni di avere più valori. Cloud CDN le comprime in un elenco separato da virgole da inviare al backend, quindi è come se il client avesse inviato quanto segue:

My-Header: Value1, Value2

Includi cookie denominati

Un cookie HTTP è un accoppiamento name=value e una richiesta può includere più cookie HTTP, separati da un punto e virgola sulla stessa riga oppure come intestazioni della richiesta Cookie discrete con un cookie per intestazione.

Puoi fornire un elenco di massimo cinque nomi di cookie.

Gli user agent (come i browser web) spesso limitano a 4 KB il numero di cookie memorizzati per dominio. Assicurati di non inviare troppi cookie (o cookie troppo grandi), poiché lo user agent potrebbe non inviarli tutti in una richiesta. Ciò può influire sulla ricezione di una risposta specifica memorizzata nella cache da parte di un utente.

Se fornisci i contenuti statici da un nome host diverso rispetto a quello da cui emetti i cookie, assicurati che l'attributo Domain del cookie (e l'attributo Path) consenta l'invio del cookie insieme alle richieste di contenuti statici.

Se una richiesta include più istanze dello stesso nome cookie, viene rispettata solo la prima.

Istruzioni di controllo cache

Le istruzioni di controllo cache HTTP influiscono sul comportamento di Cloud CDN, come descritto nella tabella seguente.

N/A indica che un'istruzione non è applicabile a una richiesta o a una risposta.

Istruzione Richiesta Risposta
no-store Se presente in una richiesta, Cloud CDN la rispetta e non memorizza la risposta nella cache.

Una risposta con no-store non viene memorizzata nella cache.

È possibile eseguire l'override di questa impostazione per singolo backend con la modalità cache FORCE_CACHE_ALL.

no-cache L'istruzione della richiesta no-cache viene ignorata per impedire ai client di essere in grado di avviare o forzare la riconvalida sull'origine.

Una risposta con no-cache viene memorizzata nella cache, ma deve essere riconvalidata con l'origine prima di essere fornita.

È possibile eseguire l'override di questa impostazione per singolo backend con la modalità cache FORCE_CACHE_ALL.

public N/A

Quest'istruzione non è necessaria per la memorizzazione nella cache, ma è una best practice includerla per i contenuti che devono essere memorizzati nella cache dai proxy.

private N/A

Una risposta con l'istruzione private non viene memorizzata nella cache da Cloud CDN, anche se la risposta è altrimenti considerata memorizzabile nella cache. I client (come i browser) potrebbero comunque memorizzare nella cache il risultato.

È possibile eseguire l'override di questa impostazione per singolo backend con la modalità cache FORCE_CACHE_ALL. Utilizza no-store per impedire completamente la memorizzazione nella cache delle risposte.

max-age=SECONDS L'istruzione max-age della richiesta viene ignorata. Una risposta memorizzata nella cache viene restituita come se questa intestazione non fosse inclusa nella richiesta. Una risposta con l'istruzione max-age viene memorizzata nella cache fino al valore di SECONDS definito.
s-maxage=SECONDS N/A

Una risposta con l'istruzione s-maxage viene memorizzata nella cache fino al valore di SECONDS definito.

Se sono presenti sia max-age che s-maxage, Cloud CDN utilizza s‑maxage.

Le risposte con questa istruzione non vengono fornite se scadute.

s-max-age (due trattini) non è valido ai fini della memorizzazione nella cache.

min-fresh=SECONDS L'istruzione min-fresh della richiesta viene ignorata. Una risposta memorizzata nella cache viene restituita come se questa intestazione non fosse inclusa nella richiesta. N/A
max-stale=SECONDS

L'istruzione max-stale della richiesta stabilisce il valore di mancato aggiornamento massimo (in secondi) che il client è disposto ad accettare.

Cloud CDN rispetta questa istruzione e restituisce una risposta memorizzata nella cache scaduta solo se il tempo di mancato aggiornamento della risposta è inferiore all'istruzione max-stale. In caso contrario, ripete la convalida prima di elaborare la richiesta.

 N/A
stale-while-revalidate=SECONDS N/A

Una risposta con stale-while-revalidate viene inviata a un client per un massimo di SECONDS mentre la riconvalida viene eseguita in modo asincrono.

Questo comportamento può essere attivato per tutte le risposte impostando cdnPolicy.serveWhileStale sul backend.

stale-if-error=SECONDS L'istruzione stale-if-error della richiesta viene ignorata. Una risposta memorizzata nella cache viene restituita come se questa intestazione non fosse inclusa nella richiesta.

Questa intestazione della risposta non ha alcun effetto.

must-revalidate N/A

Una risposta con must-revalidate viene riconvalidata con il server di origine dopo la scadenza.

Le risposte con questa istruzione non vengono fornite se scadute.

proxy-revalidate

Una risposta con proxy-revalidate viene riconvalidata con il server di origine dopo la scadenza.

Le risposte con questa istruzione non vengono fornite se scadute.

immutable N/A Nessun effetto. Questo valore viene passato al client nella risposta.
no-transform N/A Cloud CDN non applica trasformazioni.
only-if-cached L'istruzione only-if-cached della richiesta viene ignorata. Una risposta memorizzata nella cache viene restituita come se questa intestazione non fosse inclusa nella richiesta. N/A

Ove possibile, Cloud CDN si impegna a rispettare la RFC (RFC HTTP 7234), ma privilegia l'ottimizzazione per l'offload della cache e la riduzione al minimo dell'impatto che i client possono avere sulla percentuale di successi e sul carico complessivo dell'origine.

Per le risposte che utilizzano l'intestazione HTTP/1.1 Expires:

  • Il valore dell'intestazione Expires deve essere una data HTTP valida come definita nella RFC 7231.
  • Un valore di data nel passato, una data non valida o un valore pari a 0 indica che i contenuti sono già scaduti e richiedono la riconvalida.
  • Se nella risposta è presente un'intestazione Cache-Control, Cloud CDN ignora l'intestazione Expires.

La presenza di un'intestazione Expires valida e futura nella risposta consente di memorizzare la risposta nella cache e non richiede la specifica di altre istruzioni di memorizzazione nella cache.

L'intestazione HTTP/1.0 Pragma, se presente in una risposta, viene ignorata e trasmessa al client così com'è. Le richieste dei client con questa intestazione vengono trasmesse all'origine e non influiscono sul modo in cui una risposta viene gestita da Cloud CDN.

Intestazioni Vary

L'intestazione Vary indica che la risposta varia a seconda delle intestazioni della richiesta del client. Oltre all'URI della richiesta, Cloud CDN rispetta le intestazioni Vary che i server di origine includono nelle risposte. Ad esempio, se in una risposta è specificato Vary: Accept, Cloud CDN utilizza una voce della cache per le richieste in cui è specificato Accept: image/webp,image/*,*/*;q=0.8 e un'altra per le richieste in cui è specificato Accept: */*.

La tabella nella sezione Contenuti non memorizzabili nella cache elenca le intestazioni Vary che consentono la memorizzazione nella cache dei contenuti. Altri valori dell'intestazione Vary impediscono la memorizzazione nella cache dei contenuti.

La modalità cache FORCE_CACHE_ALL non esegue l'override di questo comportamento. Le intestazioni Vary sono importanti per evitare il poisoning della cache tra più possibili risposte del server di origine. Sarebbe pericoloso se FORCE_CACHE_ALL causasse la memorizzazione nella cache di queste risposte.

Le intestazioni Vary vengono talvolta utilizzate per pubblicare contenuti compressi. Cloud CDN non comprime né decomprime le risposte (a meno che non sia abilitata la compressione dinamica), ma può fornire risposte compresse dal server di origine. Se il server di origine sceglie se fornire contenuti compressi o non compressi in base al valore dell'intestazione della richiesta Accept-Encoding, assicurati che nella risposta sia specificato Vary: Accept-Encoding.

Quando utilizzi le intestazioni HTTP nella chiave cache, Cloud CDN memorizza nella cache più copie della risposta in base ai valori delle intestazioni della richiesta specificate, in modo simile al supporto di Vary, ma senza la necessità che il server di origine specifichi esplicitamente un'intestazione della risposta Vary. Se l'origine specifica le intestazioni della chiave cache nella risposta Vary, Cloud CDN tratta la risposta correttamente, come se le intestazioni non fossero menzionate nella risposta Vary.

Tempi di scadenza e richieste di convalida

La scadenza di una voce della cache definisce per quanto tempo rimane valida. Il valore fornito da s-maxage (o max-age o expires) consente la riconvalida automatica dei contenuti scaduti generati dagli utenti e memorizzati nella cache.

Quando Cloud CDN riceve una richiesta, cerca la voce della cache corrispondente e ne controlla l'attualità. Se la voce della cache esiste ed è abbastanza recente, la risposta può essere fornita dalla cache. Se il tempo di scadenza è trascorso, Cloud CDN tenta di riconvalidare la voce della cache contattando uno dei tuoi backend. Questa operazione viene eseguita prima di fornire la risposta, a meno che tu non attivi serve-while-stale, nel qual caso la riconvalida viene eseguita in modo asincrono.

Per alcune modalità cache, puoi impostare i valori di TTL. Per saperne di più, consulta Utilizzo delle impostazioni e degli override TTL.

La modalità cache influisce sul modo in cui viene determinato lo stato di aggiornamento.

Modalità cache Comportamento di convalida
CACHE_ALL_STATIC Le intestazioni dell'origine (Cache-Control: s-maxage, Cache-Control: max-age o Expires) vengono consultate per determinare lo stato di aggiornamento. Per i contenuti statici, se le intestazioni dell'origine non sono presenti, il valore di default_ttl configurato determina l'aggornamento. Dopo che i contenuti statici hanno superato il valore di default_ttl, Cloud CDN ripete la convalida.
USE_ORIGIN_HEADERS Ogni voce della cache in una cache Cloud CDN ha un tempo di scadenza definito dalle intestazioni Cache-Control: s-maxage, Cache-Control: max-age o Expires in conformità alla RFC 7234.
FORCE_CACHE_ALL Anziché dalle intestazioni dell'origine, lo stato di aggiornamento è determinato dal valore di default_ttl configurato. Dopo che i contenuti hanno superato il valore di default_ttl, Cloud CDN ripete la convalida.

Se sono presenti più valori, Cache-Control: s-maxage ha la precedenza su Cache-Control: max-age e Cache-Control: max-age ha la precedenza su Expires.

Per impostazione predefinita, quando il valore del tempo di scadenza supera i 30 giorni (2.592.000 secondi), Cloud CDN considera il valore di scadenza come se fosse di 2.592.000 secondi. I client downstream continuano a visualizzare i valori accurati di max-age e s-maxage, anche se superano i 30 giorni.

Eliminazione dalla cache

Non è garantito che una voce rimanga nella cache fino alla scadenza, perché le voci meno popolari possono essere rimosse prima della scadenza in qualsiasi momento per fare spazio a nuovi contenuti. Come limite superiore, le voci della cache a cui non viene eseguito l'accesso per 30 giorni vengono eliminate automaticamente.

Per saperne di più, consulta Eliminazione dalla cache e scadenza.

Utilizza richieste condizionali per la convalida

Cloud CDN può tentare di utilizzare le informazioni nelle intestazioni della risposta memorizzata nella cache per convalidare la voce della cache con il backend. Ciò si verifica quando sono soddisfatte entrambe le seguenti condizioni:

  • La risposta memorizzata nella cache in precedenza ha un'intestazione Last-Modified o ETag.
  • La richiesta del client è una richiesta GET che non contiene intestazioni If-Modified-Since o If-None-Match.

Cloud CDN esegue questa convalida in modo leggermente diverso a seconda che la risposta sia stata memorizzata nella cache utilizzando richieste di intervalli di byte:

  • Se la risposta è stata memorizzata nella cache utilizzando richieste di intervalli di byte, Cloud CDN avvia una richiesta di convalida separata che include le intestazioni If-Modified-Since e If-None-Match.
  • In caso contrario, Cloud CDN aggiunge le intestazioni If-Modified-Since e If-None-Match alla richiesta del client e inoltra la richiesta modificata al backend.

Se la copia memorizzata nella cache è ancora aggiornata, il backend può convalidare la voce della cache esistente inviando una risposta 304 Not Modified. In questo caso, il backend invia solo le intestazioni della risposta, non il corpo. Cloud CDN inserisce le nuove intestazioni della risposta nella cache, aggiorna il tempo di scadenza e invia le nuove intestazioni della risposta e il corpo della risposta memorizzato nella cache al client.

Se la risposta memorizzata nella cache in precedenza non ha un'intestazione Last-Modified o ETag, Cloud CDN ignora la voce della cache scaduta e inoltra la richiesta del client al backend senza modifiche.

Supporto per le richieste di intervalli di byte

Una risposta che soddisfa i seguenti criteri indica che il server di origine supporta le richieste di intervalli di byte:

  • Codice di stato: 200 OK o 206 Partial Content
  • Intestazione: Accept-Ranges: bytes
  • Intestazione: Content-Length e, per una risposta 206 Partial Content, un valore di Content-Range che indica la lunghezza completa dell'oggetto di origine. Ad esempio, Content-length: 0-100/999 è memorizzabile nella cache, mentre Content-length: 0-100/* non lo è.
  • Intestazione: Last-Modified e ETag con uno strumento di convalida efficace.

Cloud Storage supporta le richieste di intervalli di byte per la maggior parte degli oggetti. Tuttavia, Cloud Storage non supporta le richieste di intervalli di byte per gli oggetti con metadati Content-Encoding: gzip, a meno che la richiesta del client non includa un'intestazione Accept- Encoding: gzip. Se hai oggetti Cloud Storage di dimensioni superiori a 10 MB, assicurati che non abbiano metadati Content-Encoding: gzip. Per informazioni su come modificare i metadati degli oggetti, consulta Visualizzazione e modifica dei metadati degli oggetti.

Anche i software server web più diffusi supportano le richieste di intervalli di byte. Per informazioni dettagliate su come attivare il supporto, consulta la documentazione del tuo server web. Per saperne di più sulle richieste di intervalli di byte, consulta la specifica HTTP.

Quando un server di origine supporta le richieste di intervalli di byte, una cache Cloud CDN rifiuta di memorizzare una risposta altrimenti memorizzabile nella cache la prima volta che viene richiesta se si verifica una delle seguenti condizioni:

  • Il corpo della risposta è incompleto perché il client ha richiesto solo una parte del contenuto.
  • Il corpo della risposta è maggiore di 1 MB (1.048.576 byte).

Quando ciò accade e la risposta soddisferebbe altrimenti i normali requisiti di memorizzazione nella cache, la cache registra che il server di origine supporta le richieste di intervalli di byte per quella chiave cache e inoltra la risposta del server di origine al client.

In caso di fallimento della cache, la cache verifica se il server di origine supporta le richieste di intervalli di byte. Se è noto che le richieste di intervalli di byte sono supportate per la chiave cache, la cache non inoltra la richiesta del client al bilanciatore del carico delle applicazioni esterno. La cache avvia invece le proprie richieste di riempimento della cache degli intervalli di byte per le parti del contenuto mancanti.

Il server di origine restituisce una risposta 206 Partial Content quando Cloud CDN avvia la propria richiesta di riempimento della cache degli intervalli di byte. Affinché una risposta 206 Partial Content venga presa in considerazione durante la memorizzazione nella cache, deve includere un'intestazione Content-Range con un'istruzione complete-length che non contiene asterischi, ad esempio 0-100/999. Cloud CDN memorizza nella cache la risposta 206 Partial Content restituita e la utilizza per rispondere alle richieste future dei client per questi contenuti.

Una cache memorizza una risposta 206 Partial Content solo quando viene ricevuta in risposta a una richiesta di un intervallo di byte avviata dalla cache. Poiché una cache non avvia una richiesta di un intervallo di byte a meno che non abbia registrato in precedenza che il server di origine supporta le richieste di intervalli di byte per quella chiave cache, una determinata cache non memorizza contenuti di dimensioni superiori a 1 MB fino alla seconda volta che si accede ai contenuti.

A causa della sua natura distribuita, Cloud CDN potrebbe recuperare il chunk finale dall'origine più di una volta per località. Questo influisce solo su un piccolo numero di richieste iniziali per ogni chiave cache.

Compressione (raggruppamento) delle richieste

La compressione delle richieste (chiamata anche raggruppamento) raggruppa attivamente più richieste di riempimento della cache guidate dall'utente per la stessa chiave cache in un'unica richiesta di origine per nodo edge. Ciò può ridurre attivamente il carico sull'origine e si applica sia alle richieste di elementi (risposte recuperate direttamente) sia alle richieste di chunk, in cui Cloud CDN utilizza richieste Range per recuperare oggetti più grandi con maggiore efficienza.

La compressione delle richieste è attiva per impostazione predefinita.

Le richieste compresse hanno il comportamento seguente:

  • Le richieste compresse registrano sia la richiesta rivolta al client sia la richiesta di riempimento della cache (compressa).
  • Il leader della sessione compressa viene utilizzato per creare la richiesta di riempimento dell'origine.
  • Gli attributi della richiesta che non fanno parte della chiave cache, come l'intestazione User-Agent o Accept-Encoding, riflettono solo il leader della sessione compressa.
  • Le richieste che non hanno la stessa chiave cache non possono essere compresse.

Il seguente diagramma mostra come vengono raggruppate le richieste:

Cloud CDN con la compressione delle richieste abilitata.
Cloud CDN con la compressione delle richieste abilitata (fai clic per ingrandire).

Al contrario, con la compressione delle richieste disabilitata o per le richieste che non possono essere raggruppate, il numero di richieste di origine e risposte può essere uguale al numero di client che tentano di recuperare un oggetto non memorizzato nella cache.

Cloud CDN senza la compressione delle richieste abilitata.
Cloud CDN senza la compressione delle richieste abilitata (fai clic per ingrandire).

Per tutti i tipi di richieste, la compressione è abilitata per impostazione predefinita. Per i tipi di richieste di elementi, puoi disabilitare la compressione. Ti consigliamo di disabilitare la compressione per le richieste di elementi in scenari con sensibilità alla latenza elevata, ad esempio la pubblicazione di annunci, in cui il carico dell'origine non è un fattore da considerare.

La tabella seguente riepiloga il comportamento predefinito e la configurabilità per diversi tipi di richieste.

Tipo di richiesta Comportamento predefinito Configurabile Vantaggi della compressione
Richieste di chunk Abilitata No Può ridurre significativamente la larghezza di banda dell'origine
Richieste di elementi Abilitata Sì Può ridurre il volume delle richieste di origine

Per disabilitare il raggruppamento delle richieste di elementi utilizzando Google Cloud CLI per un bucket di backend che fa riferimento a un bucket Cloud Storage:

gcloud

Utilizza il comando gcloud compute backend-services o backend-buckets:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --no-request-coalescing

Per abilitare la compressione delle richieste di elementi su un bucket di backend utilizzando Google Cloud CLI:

gcloud

Utilizza il comando gcloud compute backend-buckets:

gcloud compute backend-buckets update BACKEND_BUCKET_NAME \
    --request-coalescing

Per abilitare la compressione delle richieste di elementi utilizzando Google Cloud CLI per un servizio di backend, inclusi i gruppi di VM e i backend esterni:

gcloud

Utilizza il comando gcloud compute backend-services:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --request-coalescing

Richieste avviate da Cloud CDN

Quando il server di origine supporta le richieste di intervalli di byte, Cloud CDN può inviare più richieste al server di origine come reazione a una singola richiesta del client. Cloud CDN può avviare due tipi di richieste: richieste di convalida e richieste di intervalli di byte.

Se la risposta che indicava che il server di origine supportava le richieste di intervalli di byte per una determinata chiave cache è scaduta, Cloud CDN avvia una richiesta di convalida per confermare che i contenuti non sono cambiati e che il server di origine supporta ancora le richieste di intervalli per i contenuti. Se il server di origine restituisce una risposta 304 Not Modified, Cloud CDN procede a fornire i contenuti utilizzando intervalli di byte. In caso contrario, Cloud CDN inoltra la risposta del server di origine al client. Puoi controllare i tempi di scadenza utilizzando le intestazioni della risposta Cache-Control e Expires.

In caso di fallimento della cache, Cloud CDN avvia richieste di riempimento della cache per un insieme di intervalli di byte che si sovrappongono alla richiesta del client. Se alcuni intervalli dei contenuti richiesti dal client sono presenti nella cache, Cloud CDN gestisce tutto il possibile dalla cache e invia richieste di intervalli di byte al server di origine solo per gli intervalli mancanti.

Ogni richiesta di un intervallo di byte avviata da Cloud CDN specifica un intervallo che inizia con un offset multiplo di 2.097.136 byte. Con la possibile eccezione dell'intervallo finale, anche tutti gli intervalli sono di 2.097.136 byte. Se i contenuti non sono un multiplo di questa dimensione, l'intervallo finale è più piccolo. Le dimensioni e gli offset utilizzati nelle richieste di intervalli di byte potrebbero cambiare in futuro.

Consideriamo, ad esempio, una richiesta del client per i byte da 1.000.000 a 3.999.999 di contenuti non presenti nella cache. In questo esempio, Cloud CDN potrebbe avviare due richieste GET, una per i primi 2.097.136 byte di contenuti e un'altra per i secondi 2.097.136 byte. Ciò comporta il riempimento della cache con 4.194.272 byte, anche se il client ha richiesto solo 3.000.000 byte.

Quando utilizzi un bucket Cloud Storage come origine, ogni richiesta GET viene fatturata come operazione di classe B separata. Ti vengono addebitate tutte le richieste GET elaborate da Cloud Storage, incluse quelle avviate da Cloud CDN. Quando una risposta viene fornita interamente da una cache Cloud CDN, non vengono inviate richieste GET a Cloud Storage e non ti vengono addebitati costi per le operazioni di Cloud Storage.

Quando Cloud CDN avvia una richiesta di convalida o una richiesta di un intervallo di byte, non include intestazioni specifiche del client come Cookie o User-Agent.

Nel campo httpRequest.userAgent di Cloud Logging, Cloud-CDN-Google indica che Cloud CDN ha avviato la richiesta.

Bypass della cache

Il bypass della cache consente alle richieste contenenti intestazioni della richiesta specifiche di bypassare la cache, anche se i contenuti sono stati memorizzati nella cache in precedenza.

Questa sezione fornisce informazioni sul bypass della cache con le intestazioni HTTP, come Pragma e Authorization. Questa funzionalità è utile quando vuoi assicurarti che i tuoi utenti o clienti recuperino sempre i contenuti più recenti dal server di origine. Potresti volerlo fare a scopo di test, configurazione di directory di staging o script.

Se un'intestazione specificata corrisponde, la cache viene ignorata per tutte le impostazioni della modalità cache, anche FORCE_CACHE_ALL. Il bypass della cache comporta un numero elevato di fallimenti della cache se le intestazioni specificate sono comuni a molte richieste.

Prima di iniziare

  • Assicurati che Cloud CDN sia abilitato. Per istruzioni, consulta Utilizzo di Cloud CDN.

  • Se necessario, esegui l'aggiornamento all'ultima versione di Google Cloud CLI:

    gcloud components update

Configura il bypass della cache

Puoi specificare fino a cinque nomi di intestazioni HTTP. I valori non fanno distinzione tra maiuscole e minuscole. Il nome dell'intestazione deve essere un token di campo di intestazione HTTP valido. Un nome di intestazione non deve apparire più di una volta nell'elenco delle intestazioni aggiunte. Per le regole relative ai nomi delle intestazioni validi, vedi Come funzionano le intestazioni personalizzate.

Console

  1. Nella console Google Cloud , vai alla pagina Bilanciamento del carico.

    Vai alla pagina Bilanciamento del carico

  2. Fai clic sul nome del bilanciatore del carico delle applicazioni esterno.
  3. Fai clic su Modifica .
  4. In Configurazione backend, seleziona un backend e fai clic su Modifica .
  5. Assicurati che l'opzione Abilita Cloud CDN sia selezionata.
  6. Nella parte inferiore della finestra, fai clic su Configurazioni avanzate.
  7. Nella sezione Ignora cache per intestazione della richiesta, fai clic su Aggiungi intestazione.
  8. Digita un nome di intestazione, ad esempio Pragma o Authorization.
  9. Fai clic su Aggiorna.
  10. Fai di nuovo clic su Aggiorna.

gcloud

Per i bucket di backend, utilizza il comando gcloud compute backend-buckets create o gcloud compute backend-buckets update con il flag --bypass-cache-on-request-headers.

Per i servizi di backend, utilizza il comando gcloud compute backend-services create o gcloud compute backend-services update con il flag --bypass-cache-on-request-headers.

gcloud compute backend-buckets (create | update) BACKEND_BUCKET_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER

gcloud compute backend-services (create | update) BACKEND_SERVICE_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER

Ad esempio:

gcloud compute backend-services update my-backend-service
    --bypass-cache-on-request-headers=Pragma
    --bypass-cache-on-request-headers=Authorization

API

Per i bucket di backend, utilizza la chiamata API Metodo: backendBuckets.insert, Metodo: backendBuckets.update o Metodo: backendBuckets.patch.

Per i servizi di backend, utilizza la chiamata API Metodo: backendServices.insert, Metodo: backendServices.update o Metodo: backendServices.patch.

Ad esempio:

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets

Aggiungi il seguente snippet al corpo della richiesta JSON:

"cdnPolicy": {
  "bypassCacheOnRequestHeaders": [
    {
      "headerName": string
    }
  ]
}

Disattiva il bypass della cache

gcloud

Per i bucket di backend, utilizza il comando gcloud compute backend-buckets create o gcloud compute backend-buckets update con il flag --no-bypass-cache-on-request-headers.

Per i servizi di backend, utilizza il comando gcloud compute backend-services create o gcloud compute backend-services update con il flag --no-bypass-cache-on-request-headers.

gcloud compute backend-services (create | update) (BACKEND_SERVICE_NAME | BACKEND_BUCKET_NAME)
    --no-bypass-cache-on-request-headers

API

Per i bucket di backend, utilizza la chiamata API Metodo: backendBuckets.insert o Metodo: backendBuckets.update.

Per i servizi di backend, utilizza la chiamata API Metodo: backendServices.insert o Metodo: backendServices.update.

Utilizza una delle chiamate API seguenti:

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE

Aggiungi il seguente snippet al corpo della richiesta JSON:

"cdnPolicy": {
  "fields": "bypassCacheOnRequestHeaders"
}

Passaggi successivi