Panoramica della memorizzazione nella cache

Una risposta memorizzabile nella cache è una risposta HTTP che Cloud CDN può archiviare e recuperare rapidamente, consentendo così tempi di caricamento più rapidi. Non tutte le risposte HTTP possono essere memorizzate nella cache.

Modalità cache

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

Cloud CDN offre tre modalità cache che definiscono il modo in cui le risposte vengono memorizzate nella cache, se Cloud CDN rispetta le direttive di memorizzazione nella cache inviate dall'origine e come vengono applicate le TTL della cache.

Le modalità cache disponibili sono indicate nella seguente tabella:

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

Questo è il comportamento predefinito per i backend abilitati per Cloud CDN creati utilizzando Google Cloud CLI o l'API REST.

USE_ORIGIN_HEADERS Richiede risposte dell'origine riuscite per impostare direttive di memorizzazione nella cache valide e intestazioni di memorizzazione nella cache valide. Le risposte riuscite senza queste istruzioni vengono inoltrate dall'origine.
FORCE_CACHE_ALL Memorizza nella cache incondizionatamente le risposte riuscite, sostituendo eventuali direttive di cache impostate dall'origine. Questa modalità non è appropriata se il backend pubblica contenuti privati per singolo utente, ad esempio le risposte dell'API o HTML dinamico.

Le risposte di errore possono essere memorizzate nella cache anche in assenza di direttive valide.

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

  • Per gli URL firmati o i cookie firmati, FORCE_CACHE_ALL sostituisce il valore massimo specificato tramite l'impostazione Durata massima voce Cache nella console Google Cloud o l'opzione gcloud --signed-url-cache-max-age.

  • FORCE_CACHE_ALL modifica la durata (TTL) di tutti i contenuti precedentemente memorizzati nella cache. Questa modifica può far sì che alcune voci precedentemente considerate aggiornate (a causa della presenza di TTL più lunghi dalle intestazioni di origine) vengano considerate obsolete e alcune voci che in precedenza erano considerate obsolete possono essere considerate aggiornate.

  • FORCE_CACHE_ALL esegue l'override delle istruzioni di memorizzazione nella cache (Cache-Control e Expires), ma non delle altre intestazioni delle risposte di origine. In particolare, un'intestazione Vary viene comunque rispettata e può sopprimere la memorizzazione nella cache anche in presenza di FORCE_CACHE_ALL. Per maggiori informazioni, consulta Intestazioni Vary.

Per le istruzioni di configurazione, consulta Impostazione della modalità cache.

Contenuti statici

I contenuti statici sono contenuti sempre uguali, anche se accedono a utenti diversi. Il CSS che utilizzi per definire il tuo sito e il codice JavaScript per fornire interattività, video e contenuti di immagini in genere non cambiano per ogni utente in un determinato URL (chiave cache) e quindi traggono vantaggio dall'essere memorizzati nella cache sulla rete perimetrale globale di Cloud CDN.

Quando imposti la modalità cache su CACHE_ALL_STATIC e una risposta non ha istruzioni esplicite di memorizzazione nella cache nelle intestazioni Cache-Control o Expires, Cloud CDN memorizza automaticamente nella cache 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 JPEG (image/jpg) e PNG (image/png)
  • Video, inclusi H.264, H.265 e MP4 (video/mp4) e file audio, inclusi MP3 (audio/mpeg) e MP4 (audio/mp4)
  • Documenti formattati, inclusi 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 controlla l'intestazione della risposta HTTP Content-Type, che riflette il tipo MIME dei contenuti pubblicati.

Tieni presente quanto segue:

  • Il software server web della tua 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 l'intestazione Content-Type automaticamente al caricamento quando utilizzi la console Google Cloud o lo strumento gsutil per caricare contenuti.

  • Se una risposta può essere memorizzata nella cache in base al tipo MIME, ma ha un'intestazione della risposta Cache-Control private o no-store, oppure un'intestazione Set-Cookie (consulta l'elenco completo delle regole), non viene memorizzata nella cache.

Cloud CDN non utilizza le estensioni dei file nel percorso dell'URL per determinare se una risposta può essere memorizzata nella cache perché molte risposte valide possono essere memorizzate nella cache non sono riportate negli URL.

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

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 dal documento RFC 7234, mentre altri sono specifici di Cloud CDN.

Cloud CDN può modificare periodicamente l'esatto insieme di condizioni in cui memorizza i contenuti nella cache. Se vuoi impedire esplicitamente a Cloud CDN di memorizzare nella cache i tuoi contenuti, segui le linee guida in RFC 7234 per determinare come specificare una risposta garantita non memorizzabile nella cache. Consulta anche la sezione Contenuti non memorizzabili nella cache basati su intestazioni di origine.

Cloud CDN archivia le risposte nella cache se tutte le seguenti condizioni sono vere.

Attributo Requisito
Servito da Servizio di backend, bucket di backend o backend esterno con Cloud CDN abilitato
In risposta a Richiesta di 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 nel futuro.

Per le risposte memorizzabili nella cache senza un'età (ad esempio, con no-cache), l'istruzione public deve essere fornita esplicitamente.

Con la modalità cache di CACHE_ALL_STATIC, in assenza di direttive di aggiornamento, una risposta positiva con tipo di contenuto statico è comunque idonea per la memorizzazione nella cache.

Con la modalità cache di FORCE_CACHE_ALL, qualsiasi risposta riuscita è idonea per la memorizzazione nella cache. Ciò potrebbe causare la memorizzazione nella cache di contenuti privati per singolo utente (identificabili dall'utente). Devi impostare FORCE_CACHE_ALL solo sui backend che non distribuiscono contenuti privati o dinamici, come i bucket Cloud Storage.

Se la memorizzazione nella cache negativa è abilitata e il codice di stato corrisponde a uno per cui la memorizzazione nella cache negativa specifica un TTL, la risposta è idonea per la memorizzazione nella cache, anche senza direttive esplicite di aggiornamento.
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 versioni successive), la risposta non deve contenere queste intestazioni.
Dimensioni Minore o uguale alla dimensione massima.

Per risposte con dimensioni comprese tra 10 MB e 100 GB, vedi i vincoli aggiuntivi di memorizzazione nella cache descritti nelle richieste di intervallo di byte.

Per i bucket di backend Cloud Storage, esistono diversi modi per soddisfare questi requisiti:

  • Rendi il bucket leggibile pubblicamente. Questo è l'approccio che consigliamo per i contenuti pubblici. Con questa impostazione, chiunque su internet può visualizzare ed elencare gli oggetti e i relativi metadati, esclusi gli ACL. Si consiglia di dedicare bucket specifici per oggetti pubblici.

  • Utilizza le cartelle gestite per rendere pubblicamente leggibile una parte del tuo bucket.

  • Rendi i singoli oggetti pubblicamente leggibili. Questo approccio è sconsigliato, perché utilizza un sistema di autorizzazioni legacy specifico per Cloud Storage.

Per impostazione predefinita, quando un oggetto è pubblico e non specifica i 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.

Dimensioni massime

Cloud CDN applica una dimensione massima per ogni risposta. Le risposte con un corpo più grande della dimensione massima non vengono memorizzate nella cache, ma vengono comunque recapitate al client.

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

Il server di origine supporta le richieste di intervallo di byte Il server di origine non supporta le richieste di intervalli di byte
100 GB (107.374.182.400 byte) 10 MB (10.485.760 byte)

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

Contenuti non memorizzabili nella cache in base alle intestazioni di origine

Esistono controlli che bloccano la memorizzazione nella cache delle risposte. Cloud CDN può modificare periodicamente l'esatto insieme di condizioni in cui memorizza i contenuti nella cache. Quindi, se vuoi impedire esplicitamente a Cloud CDN di memorizzare nella cache i tuoi contenuti, segui le linee guida dello standard (RFC7234) per determinare come specificare una risposta garantita non memorizzabile 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
Servito da Servizio di backend o backend esterno in cui Cloud CDN non è 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 con una delle intestazioni configurate per far parte delle impostazioni della chiave cache.
Istruzione di risposta La risposta ha un'intestazione Cache-Control con l'istruzione no-store o private (a meno che non utilizzi la modalità cache FORCE_CACHE_ALL, nel qual caso l'intestazione Cache-Control viene ignorata)
Richiesta di istruzione La richiesta ha un'istruzione Cache-Control: no-store
Richiedi autorizzazione La richiesta ha un'intestazione Authorization, a meno che non venga sottoposta a override dalla risposta Cache-Control.
Dimensioni Più grande della dimensione massima

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

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

Prevenzione della memorizzazione nella cache

Per evitare che le informazioni private vengano memorizzate nella cache di Cloud CDN, procedi nel seguente modo:

  1. Assicurati che la modalità cache di Cloud CDN non sia impostata sulla modalità FORCE_CACHE_ALL, che memorizza incondizionatamente nella cache tutte le risposte riuscite.
  2. Includi un'intestazione Cache-Control: private nelle risposte che non devono essere archiviate nelle cache di Cloud CDN oppure un'intestazione Cache-Control: no-store nelle risposte che non devono essere memorizzate in nessuna cache, neanche nella cache di un browser web.
  3. Non firmare URL che forniscono accesso a informazioni private. Quando si accede ai contenuti tramite un URL firmato, questi sono potenzialmente idonei per la memorizzazione nella cache indipendentemente dalle istruzioni Cache-Control nella risposta.
  4. Per le richieste di 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 della cache public, must-revalidate o s-maxage quando la modalità cache è impostata su USE_ORIGIN_HEADERS o CACHE_ALL_STATIC. Ciò impedisce la memorizzazione accidentale nella cache di contenuti per utente e/o di contenuti che richiedono l'autenticazione. La modalità cache FORCE_CACHE_ALL non prevede questa limitazione.

Aggiungere intestazioni delle risposte personalizzate

Con le intestazioni delle risposte personalizzate, puoi specificare le intestazioni che l'Application Load Balancer classico aggiunge alle risposte inviate tramite proxy. Le intestazioni delle risposte personalizzate ti consentono di mostrare lo stato della cache per i clienti, i dati geografici e le intestazioni di risposta statiche.

Per l'elenco delle intestazioni, consulta Variabili che possono essere visualizzate nel valore dell'intestazione.

Per le istruzioni, vedi Utilizzo delle intestazioni delle risposte personalizzate.

Le intestazioni delle risposte personalizzate non sono supportate per i deployment di Cloud CDN su Application Load Balancer esterni globali.

Chiavi cache

Ogni voce della cache in una cache di Cloud CDN è identificata da una chiave cache. Quando una richiesta entra nella cache, la cache converte l'URI della richiesta in una chiave cache, quindi lo confronta con le chiavi delle voci memorizzate nella cache. Se trova una corrispondenza, la cache restituisce l'oggetto associato alla 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 per una determinata richiesta per l'oggetto cat.jpg. Questa stringa è utilizzata come chiave cache predefinita. Solo le richieste con questa corrispondenza esatta della stringa. 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 il protocollo o l'host. Per impostazione predefinita, solo parametri di ricerca noti a Cloud Storage sono inclusi nella chiave cache (ad esempio, "generation").

Pertanto, per un determinato bucket di backend, i seguenti URI si risolvono 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 modificare le parti dell'URI che vengono utilizzate nella chiave cache. Sebbene il nome file e il percorso devono sempre far parte della chiave, puoi includere o omettere qualsiasi combinazione di protocollo, host o stringa di query quando personalizzi la chiave cache. L'utilizzo delle chiavi cache descrive come personalizzare le chiavi cache.

Parte URI Personalizzazione URL di esempio che hanno 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 parti della stringa di query in modo selettivo.
  • https://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2

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

Elenco di inclusione stringa di query

Puoi controllare selettivamente i parametri delle stringhe di query 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 delle stringhe di query per le chiavi cache di Cloud Storage

L'inclusione parametri di ricerca dell'URL nelle chiavi cache per i bucket Cloud Storage contribuisce a supportare il busting della cache. Il busting della cache è il processo che consente a un utente di trovare una nuova versione del file che è stata caricata, anche se la versione precedente è ancora validamente memorizzata nella cache dal TTL.

Puoi includere un elenco di parametri di ricerca specifici nella chiave cache utilizzata per pubblicare le risposte da un bucket di backend. Sebbene Cloud Storage non pubblichi route o contenuti diversi in base ai parametri di ricerca, puoi scegliere di includere parametri che 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 invalidare in modo proattivo i contenuti e si allinea ai moderni flussi di lavoro di sviluppo web, in cui framework e URL web utilizzano un hash dei contenuti per evitare di pubblicare oggetti inattivi nei deployment.

Poiché l'inclusione dei parametri di ricerca nella chiave cache è solo ad attivazione, Cloud CDN non supporta l'esclusione dei parametri di ricerca da una chiave cache in un bucket di backend.

Elenco di esclusione stringa di query

Puoi controllare selettivamente i parametri delle stringhe di query ignorati da Cloud CDN utilizzando un elenco di esclusione. Ad esempio, se crei un elenco di esclusione di user, nella chiave cache vengono utilizzati tutti i parametri della stringa di query tranne user.

Con l'elenco di esclusione configurato e un input di https://example.com/images/cat.jpg?user=user1&color=blue, 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 ricerca

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

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

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

Impostazioni della chiave cache delle intestazioni HTTP e dei cookie HTTP

Puoi migliorare i tassi di successo della cache e l'offload dell'origine con le seguenti impostazioni di configurazione della chiave cache.

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

Le richieste cache che includono intestazioni HTTP o cookie HTTP aggiuntivi nella richiesta vengono memorizzate nella cache sulla terza richiesta in una posizione di cache per quella chiave cache. In questo modo ridurrai l'impatto dei valori di intestazione/cookie ad alta cardinalità sui tassi di eliminazione della cache. In circostanze normali e nelle condizioni del traffico degli utenti, questo non dovrebbe essere visibile e garantisce che i contenuti popolari rimangano memorizzati nella cache.

Inclusi le intestazioni delle richieste

Per memorizzare nella cache ulteriori varianti di una risposta, puoi includere altre intestazioni della richiesta 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 più di 5000 valori univoci data la grande varietà di browser, dispositivi utente e sistemi operativi. Questi tipi di intestazioni avrebbero un grave impatto negativo sulle percentuali di successo della cache.

Sono accettati solo nomi di campi di intestazione HTTP validi secondo il documento 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 da includere le intestazioni delle richieste con chiave cache configurate nella risposta Vary. Non è necessaria per Cloud CDN, ma può essere utile per le cache downstream. Per ulteriori informazioni, consulta la sezione Variare intestazioni.

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

  • Accept
  • Accept-Encoding
  • Authority, perché questa operazione è controllata dalla configurazione (cdnPolicy.includeHost)
  • Authorization, generalmente per utente come nei token OAuth Bearer
  • CDN-Loop
  • Connection
  • Content-MD5
  • Content-Type
  • Cookie
  • Date
  • Forwarded, spesso per client o per proxy
  • From
  • Host, perché questa operazione è controllata 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 utilizzati da Django e Ruby su Rails
  • X-Forwarded-For, spesso per client o per proxy
  • X-User-IP
  • Qualsiasi intestazione che inizia con le seguenti:
    • Access-Control-, come Access-Control-Request-Headers e Access-Control-Request-Method
    • Sec-Fetch-
    • Sec-GFE-
    • Sec-Google-
    • X-Amz-
    • X-GFE-
    • X-Goog-
    • X-Google-

Stesse intestazioni con valori diversi

Supponi che l'utente invii più intestazioni con lo stesso nome con valori di intestazione diversi, ad esempio:

My-Header: Value1
My-Header: Value2

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

My-Header: Value1, Value2

Inclusi cookie con nome

Un cookie HTTP è una combinazione name=value e una richiesta può includere più cookie HTTP, separati da un punto e virgola sulla stessa riga o come intestazioni di 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 il numero di cookie archiviati per dominio a 4 kB. Assicurati di non inviare troppi cookie (o troppo grandi), altrimenti lo user agent potrebbe non inviare tutti i cookie in una richiesta. Questo può influire sulla ricezione da parte di un utente di una specifica risposta memorizzata nella cache.

Se pubblichi i tuoi contenuti statici da un nome host diverso da cui invii i cookie, assicurati che l'attributo Domain del cookie (e l'attributo Path) consenta l'invio dei cookie insieme alle richieste di contenuti statici.

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

Istruzioni di controllo della cache

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

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

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

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

Puoi eseguire l'override di questa opzione in base ai singoli backend con la modalità cache FORCE_CACHE_ALL.

no-cache L'istruzione di richiesta no-cache viene ignorata per impedire ai client di avviare o forzare potenzialmente la riconvalida all'origine.

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

Puoi eseguire l'override di questa opzione in base ai singoli backend con la modalità cache FORCE_CACHE_ALL.

public N/A

Questa istruzione non è obbligatoria per l'inserimento nella cache, ma una best practice prevede l'inclusione di questa istruzione 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 viene altrimenti considerata memorizzabile nella cache. I client (come i browser) potrebbero comunque memorizzare nella cache il risultato.

Puoi eseguire l'override di questa opzione in base ai singoli backend con la modalità cache FORCE_CACHE_ALL. Usa no-store per impedire la memorizzazione nella cache delle risposte.

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

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

Se sono presenti sia max-age che s-maxage, s‑maxage viene utilizzato da Cloud CDN.

Le risposte con questa istruzione non vengono pubblicate.

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

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

L'istruzione di richiesta max-stale determina il livello massimo di inattività (in secondi) che il client è disposto ad accettare.

Cloud CDN rispetta questo comportamento e restituisce una risposta memorizzata nella cache inattiva solo se il tempo di inattività della risposta è inferiore all'istruzione max-stale. In caso contrario, viene riconvalidato prima di pubblicare la richiesta.

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

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

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

stale-if-error=SECONDS L'istruzione di richiesta stale-if-error viene ignorata. Viene restituita una risposta memorizzata nella cache come se l'intestazione non fosse inclusa nella richiesta.

Questa intestazione della risposta non ha effetto.

must-revalidate N/A

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

Le risposte con questa istruzione non vengono pubblicate.

proxy-revalidate

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

Le risposte con questa istruzione non vengono pubblicate.

immutable N/A Nessun effetto. Questo viene trasmesso al client nella risposta.
no-transform N/A Cloud CDN non applica alcuna trasformazione.
only-if-cached L'istruzione di richiesta only-if-cached viene ignorata. Viene restituita una risposta memorizzata nella cache come se l'intestazione non fosse inclusa nella richiesta. N/A

Ove possibile, Cloud CDN cerca di essere conforme a RFC (HTTP RFC 7234), ma favorisce l'ottimizzazione per l'offload della cache e la riduzione al minimo dell'impatto che i client possono avere sulla percentuale di hit e/o sul carico complessivo dell'origine.

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

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

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

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

Vary intestazioni

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 una risposta specifica Vary: Accept, Cloud CDN utilizza una voce di cache per le richieste che specificano Accept: image/webp,image/*,*/*;q=0.8 e un'altra per le richieste che specificano 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 di FORCE_CACHE_ALL non sostituisce questo comportamento. Le intestazioni Vary sono importanti per evitare il poisoning della cache tra più possibili risposte del server di origine. Sarebbe pericoloso che FORCE_CACHE_ALL vengano memorizzati nella cache.

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

Quando utilizzi intestazioni HTTP nella chiave cache, Cloud CDN memorizza nella cache più copie della risposta in base ai valori delle intestazioni delle richieste specificate, in modo simile al supporto Vary, ma senza 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 state menzionate nella risposta Vary.

Tempi di scadenza e richieste di convalida

La data di scadenza di una voce della cache definisce per quanto tempo una voce della cache rimane valida. Il valore fornito dal valore s-maxage (o max-age o expires) consente la riconvalida automatica dei contenuti obsoleti generati dalla cache generati dagli utenti.

Quando Cloud CDN riceve una richiesta, cerca la voce della cache corrispondente e ne controlla la data. Se la voce della cache esiste ed è sufficientemente aggiornata, la risposta può essere fornita dalla cache. Se è trascorso il tempo di scadenza, Cloud CDN tenta di riconvalidare la voce della cache contattando uno dei tuoi backend. Questo viene fatto prima di pubblicare la risposta, a meno che non abiliti serve-while-stale, nel qual caso la riconvalida viene eseguita in modo asincrono.

Per alcune modalità cache, puoi impostare i valori TTL. Per maggiori informazioni, consulta Utilizzo delle impostazioni e degli override TTL.

La modalità cache influisce sul modo in cui viene determinato l'aggiornamento.

Modalità cache Comportamento di convalida
CACHE_ALL_STATIC Per determinare l'aggiornamento, vengono consultate le intestazioni dell'origine (intestazioni Cache-Control: s-maxage, Cache-Control: max-age o Expires). Per i contenuti statici, se le intestazioni di origine non sono presenti, il criterio default_ttl configurato determina l'aggiornamento. Quando i contenuti statici sono precedenti a default_ttl, Cloud CDN li riconvalida.
USE_ORIGIN_HEADERS Ogni voce della cache in una cache di Cloud CDN ha una data di scadenza definita dalle intestazioni Cache-Control: s-maxage, Cache-Control: max-age o Expires in base allo standard RFC 7234.
FORCE_CACHE_ALL Anziché le intestazioni di origine, l'elemento default_ttl configurato determina l'aggiornamento. Quando i contenuti sono precedenti a default_ttl, Cloud CDN li riconvalida.

Se sono presenti più indirizzi, 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 della scadenza supera 30 giorni (2.592.000 secondi), Cloud CDN tratta il valore della scadenza come se fosse 2.592.000 secondi. I clienti downstream continuano a vedere i valori accurati di max-age e s-maxage, anche se superano i 30 giorni.

Sfrazione

Non c'è alcuna garanzia che una voce della cache rimanga nella cache fino alla scadenza, perché le voci impopolari possono essere eliminate prima della scadenza in qualsiasi momento per fare spazio a nuovi contenuti. Come limite superiore, le voci della cache che non vengono visualizzate per 30 giorni vengono eliminate automaticamente.

Per maggiori informazioni, consulta Rimozione e scadenza.

Utilizzare le richieste condizionali per la convalida

Cloud CDN può tentare di utilizzare le informazioni nelle intestazioni delle risposte memorizzate nella cache per convalidare la voce della cache con il backend. Questo accade quando si verificano entrambe le seguenti condizioni:

  • La risposta precedentemente memorizzata nella cache ha un'intestazione Last-Modified o ETag.
  • La richiesta 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 le richieste di intervallo di byte:

  • Se la risposta è stata memorizzata nella cache utilizzando le richieste di intervalli di byte, Cloud CDN avvia una richiesta di convalida separata che include le intestazioni If-Modified-Since e/o If-None-Match.
  • In caso contrario, Cloud CDN aggiunge le intestazioni If-Modified-Since e/o 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 esistente della cache inviando una risposta 304 Not Modified. In questo caso, il backend invia solo le intestazioni della risposta, non il corpo della risposta. Cloud CDN inserisce le nuove intestazioni della risposta nella cache, aggiorna la data di scadenza e pubblica al client le nuove intestazioni di risposta e il corpo delle risposte memorizzato nella cache.

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

Supporto per le richieste di intervallo 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
  • Titolo: Accept-Ranges: bytes
  • Intestazione: Content-Length e/o Content-Range
  • Intestazione: Last-Modified e/o 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 intervallo di byte per gli oggetti con metadati Content-Encoding: gzip, a meno che la richiesta client non includa un'intestazione Accept- Encoding: gzip. Se hai oggetti Cloud Storage più grandi di 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 con intervallo di byte. Consulta la documentazione del software del server web per i dettagli su come attivare il supporto. Per ulteriori informazioni sulle richieste di intervalli di byte, consulta la specifica HTTP.

Quando un server di origine supporta le richieste di intervallo di byte, una cache di Cloud CDN rifiuta di archiviare una risposta altrimenti memorizzabile nella cache la prima volta che viene richiesta se una delle seguenti condizioni è vera:

  • Il corpo della risposta è incompleto perché il client ha richiesto solo una parte dei contenuti.
  • Il corpo della risposta è più grande di 1 MB (1.048.576 byte).

In questo caso e la risposta soddisferebbe i normali requisiti di memorizzazione nella cache, la cache registra che il server di origine supporta le richieste di intervallo di byte per quella chiave cache e inoltra la risposta del server di origine al client.

In caso di fallimento della cache, la cache controlla se il server di origine supporta le richieste di intervallo 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 dell'intervallo di byte per le parti mancanti dei contenuti. Se il server di origine restituisce l'intervallo di byte richiesto in una risposta 206 Partial Content, la cache può archiviare l'intervallo per le richieste future.

Una cache archivia una risposta 206 Partial Content solo quando viene ricevuta in risposta a una richiesta di intervallo di byte avviata dalla cache. Poiché una cache non avvia una richiesta di intervallo di byte, a meno che non abbia registrato in precedenza che il server di origine supporta le richieste di intervallo di byte per quella chiave cache, una determinata cache non archivia contenuti di dimensioni superiori a 1 MB fino al secondo accesso ai contenuti.

A causa della sua natura distribuita, Cloud CDN potrebbe a volte recuperare il blocco finale dall'origine più di una volta per località. Questo influisce solo sulle prime richieste per chiave cache.

Compressione delle richieste (coalescenza)

La compressione delle richieste (detta anche coalescenza) comprime attivamente più richieste di riempimento della cache gestite dall'utente per la stessa chiave cache in una singola richiesta di origine per nodo perimetrale. Questo può ridurre attivamente il carico sull'origine e si applica sia alle richieste di item (risposte recuperate direttamente) sia alle richieste di tipo blocco, in cui Cloud CDN utilizza le richieste Range per recuperare oggetti più grandi in modo più efficiente.

La compressione delle richieste è attivata per impostazione predefinita.

Le richieste compresse si comportano nel seguente modo:

  • 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 effettuare la richiesta di riempimento dell'origine.
  • Gli attributi di 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 unite le richieste:

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

In confronto, se la compressione delle richieste è disabilitata o per le richieste che non possono essere unite, il numero di richieste e risposte di origine può essere uguale al numero di client che tentano di recuperare un oggetto non attualmente memorizzato nella cache.

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

Per tutti i tipi di richieste, la compressione è abilitata per impostazione predefinita. Per i tipi di richiesta di elemento, puoi disattivare la compressione. Consigliamo di disattivare la compressione per le richieste di elementi in scenari sensibili a latenza elevata, come la pubblicazione di annunci, in cui il caricamento dell'origine non viene preso in considerazione.

La seguente tabella riassume il comportamento predefinito e la configurabilità per i diversi tipi di richiesta.

Tipo di richiesta Comportamento predefinito Configurabile Vantaggi del collasso
Richieste di blocchi Abilitato No Può ridurre notevolmente la larghezza di banda di origine
Richieste di articoli Abilitato Sì Può ridurre il volume delle richieste di origine

Per disabilitare la compressione della richiesta di elemento 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 in un bucket di backend utilizzando Google Cloud CLI:

gcloud

Usa 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 gruppi di VM e backend esterni:

gcloud

Usa il comando gcloud compute backend-services:

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

Richieste avviate da Cloud CDN

Quando il tuo server di origine supporta le richieste di intervallo di byte, Cloud CDN può inviare più richieste al server di origine in 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 intervallo per i contenuti. Se il tuo server di origine risponde con 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 le richieste di riempimento della cache per un insieme di intervalli di byte che si sovrappongono alla richiesta del client. Se nella cache sono presenti alcuni intervalli dei contenuti richiesti dal client, Cloud CDN gestisce tutto ciò che è possibile dalla cache e invia richieste di intervalli di byte solo per gli intervalli mancanti al server di origine.

Ogni richiesta di intervallo di byte avviata da Cloud CDN specifica un intervallo che inizia con un offset di un multiplo di 2.097.136 byte. Con la possibile eccezione dell'intervallo finale, ogni intervallo è pari a 2.097.136 byte. Se i contenuti non sono un multiplo di queste dimensioni, l'intervallo finale è inferiore. Le dimensioni e gli offset utilizzati nelle richieste di intervalli di byte potrebbero cambiare in futuro.

Prendiamo ad esempio una richiesta client per byte compresi tra 1.000.000 e 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 del contenuto e un'altra per i secondi 2.097.136 byte. Ciò si traduce in 4.194.272 byte di riempimento della cache 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 le richieste avviate da Cloud CDN. Quando una risposta viene pubblicata interamente da una cache di Cloud CDN, non vengono inviate richieste GET a Cloud Storage e non ti viene addebitato alcun costo per le operazioni di Cloud Storage.

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

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

Bypass della cache

L'esclusione della cache consente alle richieste contenenti intestazioni specifiche di bypassare la cache, anche se i contenuti erano stati precedentemente memorizzati nella cache.

Questa sezione fornisce informazioni su come bypassare la cache con le intestazioni HTTP, come Pragma e Authorization. Questa funzionalità è utile quando vuoi assicurarti che i tuoi utenti o clienti abbiano sempre i contenuti più recenti recuperati dal server di origine. Potresti voler eseguire questa operazione per eseguire test, configurare directory temporanee o script.

Se un'intestazione specificata corrisponde, la cache viene bypassata per tutte le impostazioni della modalità cache, anche per FORCE_CACHE_ALL. L'esclusione della cache genera 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 le istruzioni, consulta Utilizzo di Cloud CDN.

  • Se necessario, esegui l'aggiornamento alla versione più recente di Google Cloud CLI:

    gcloud components update

Configurazione del 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 del campo di intestazione HTTP valido. Il nome di un'intestazione non deve comparire più di una volta nell'elenco delle intestazioni aggiunte. Per le regole sui nomi validi delle intestazioni, consulta 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. In Ignora la cache sull'intestazione della richiesta, fai clic su Aggiungi intestazione.
  8. Digita un nome per l'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
    }
  ]
}

Disattivazione del 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 seguenti chiamate API:

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