Questa pagina si applica ad Apigee e Apigee hybrid.
Visualizza la documentazione di Apigee Edge.
Questo argomento descrive come Apigee gestisce le intestazioni di memorizzazione nella cache HTTP/1.1 quando utilizzi il criterio ResponseCache. Al momento Apigee supporta un sottoinsieme di intestazioni e direttive di memorizzazione nella cache HTTP/1.1 (le funzionalità non supportate sono elencate in questo argomento) ricevute dai server di destinazione (origine) di backend.
Inoltre, con determinate intestazioni Apigee interviene in base alle relative direttive. In alcuni casi, queste intestazioni della cache HTTP/1.1 sostituiscono qualsiasi comportamento specificato nel criterio ResponseCache.
Ad esempio, se l'intestazione Cache-Control
viene restituita da un server di backend, la direttiva Cache-Control
dell'intestazione può potenzialmente sostituire altre impostazioni di scadenza nel criterio.s-maxage
Intestazione | Assistenza |
---|---|
Cache-Control | Supportato nelle risposte restituite dai server di origine di backend, ma non nelle richieste dei client. Apigee supporta un sottoinsieme di direttive. |
Scadenza | Supportato. Può essere ignorato. |
Tag entità (ETag) | Comportamento specifico per If-Match e If-None-Match. |
If-Modified-Since | Nelle richieste GET, l'intestazione viene passata al server di origine anche se esiste una voce della cache valida. |
Accept-Encoding | Apigee invia risposte compresse o non compresse a seconda delle intestazioni in entrata. |
Cache-Control
Apigee supporta l'intestazione Cache-Control
solo per le risposte restituite dai server di origine di backend (la specifica HTTP/1.1 consente le intestazioni Cache-Control
sia nelle richieste client sia nelle risposte del server di origine). I server di origine possono includere sia gli endpoint di destinazione
definiti in un proxy API Apigee sia quelli creati utilizzando le chiamate API TargetServer.
Limitazioni del supporto di Cache-Control
Apigee supporta un sottoinsieme di funzionalità delle intestazioni di risposta Cache-Control
definite nella specifica HTTP/1.1. Tieni presente quanto segue:
- Apigee non supporta le intestazioni
Cache-Control
che arrivano con le richieste client in entrata. - Apigee supporta solo la nozione di cache pubbliche. (In base alla specifica HTTP,
Cache-Control
può essere pubblico (condiviso) o privato (singolo utente).) - Apigee supporta solo un sottoinsieme di direttive di risposta
Cache-Control
nella specifica HTTP/1.1. Per maggiori dettagli, consulta la sezione Supporto per le direttive delle intestazioni di risposta Cache-Control.
Supporto per le direttive delle intestazioni di risposta Cache-Control
Apigee supporta un sottoinsieme di direttive della specifica HTTP/1.1 per le risposte dei server di origine. La tabella seguente descrive il supporto di Apigee per le direttive dell'intestazione della risposta HTTP Cache-Control.
Per informazioni più dettagliate sulle direttive elencate qui, consulta Cache-Control nella specifica HTTP/1.1.
Direttiva Cache-Control | Come Apigee elabora la direttiva |
cache-extension |
Non supportati. |
max-age |
Se il criterio ResponseCache imposta l'elemento Questa direttiva viene sostituita dalla direttiva |
must-revalidate |
Non supportati. Tutte le voci della cache vengono eliminate da Apigee non appena scadono. |
no-cache |
Apigee memorizza nella cache la risposta dell'origine, ma deve essere convalidata di nuovo con il server di origine prima di essere utilizzata per soddisfare eventuali richieste del client successive. Questa regola consente all'origine di restituire una risposta 304 Non modificato per indicare che la risposta deve essere restituita dalla cache, risparmiando così l'elaborazione necessaria per restituire l'intera risposta. Se il server di origine restituisce una risposta completa, sostituisce la voce della cache esistente. Eventuali nomi di campo specificati con questa direttiva vengono ignorati. |
no-store |
Non supportati. |
no-transform |
Non supportati. |
private |
Non supportati. Se viene ricevuta questa direttiva, la risposta dell'origine non viene memorizzata nella cache. Eventuali nomi di campo vengono ignorati. |
proxy-revalidate |
Non supportati. Tutte le voci della cache vengono eliminate da Apigee non appena scadono. |
public |
Apigee memorizza nella cache la risposta dell'origine, anche se altre direttive indicano il contrario. In base alla specifica HTTP/1.1, l'unica eccezione a questa regola è se la risposta include un'intestazione Authorization. |
s-maxage |
Se il criterio ResponseCache imposta l'elemento Questa istruzione sostituisce la direttiva |
Scadenza
Quando il flag UseResponseCacheHeaders
nel criterio ResponseCache è impostato su
true
, Apigee può utilizzare l'intestazione Expires
per determinare la durata (TTL)
di una voce memorizzata nella cache. Questa intestazione specifica una data/ora dopo la quale la voce della cache di una risposta viene considerata obsoleta. Questo intestazione consente ai server di indicare quando è consentito restituire un valore memorizzato nella cache basato su un timestamp.
I formati di data accettabili per l'intestazione Expires
sono descritti nella specifica HTTP/1.1. Ad esempio:
Scade il: 01 dic 1994 16:00:00 GMT
Per informazioni dettagliate sui formati data/ora HTTP, consulta Formati data/ora nella specifica HTTP/1.1.
Per ulteriori informazioni sull'intestazione Expires
, consulta
Definizioni dei campi dell'intestazione
nella specifica HTTP/1.1.
ETag
Un tag entità (ETag) è un identificatore associato a una risorsa richiesta. Utilizzando un ETag, un server può determinare se la risorsa richiesta e la risorsa memorizzata nella cache associata corrispondono. Ad esempio, il server potrebbe memorizzare nuovamente nella cache la risposta se non corrisponde a quella attualmente memorizzata nella cache. Potrebbe restituire la risorsa memorizzata nella cache se gli ETag corrispondono.
Quando un endpoint di destinazione invia una risposta ad Apigee con un ETag, Apigee memorizza nella cache l'ETag insieme alla risposta.
Puoi scoprire di più sugli elementi Entity Tag nella sezione Parametri di protocollo della specifica HTTP/1.1.
Se-corrispondenza
Con l'intestazione della richiesta If-Match
, un'entità memorizzata nella cache è corrente se l'ETag nell'intestazione corrisponde all'ETag memorizzato nella cache. Eventuali richieste diverse da GET che specificano un If-Match
intestazione vengono trasmesse al server di origine per garantire che eventuali strutture di memorizzazione nella cache dell'origine abbiano la possibilità di elaborare la richiesta.
Puoi scoprire di più su If-Match
nella sezione Definizioni dei campi dell'intestazione della specifica HTTP/1.1.
Se Apigee riceve una richiesta GET in entrata da un client che include un'intestazione If-Match
:
Se | Poi |
---|---|
L'intestazione If-Match specifica uno o più ETag |
|
L'intestazione If-Match specifica "*" |
La richiesta viene trasmessa al server di origine per garantire che eventuali strutture di memorizzazione nella cache dell'origine abbiano la possibilità di elaborarla |
Viene trovata una voce della cache con lo stesso URI richiesta, ma contiene solo ETag deboli | La voce deve essere riconvalidata dal server di origine prima di essere restituita al client |
Gli ETag provengono dal server di origine. | L'ETag viene restituito invariato al client |
Se-Nessuna-Corrispondenza
Con l'intestazione If-None-Match
, un'entità memorizzata nella cache è corrente se l'ETag nell'intestazione non corrisponde all'ETag memorizzato nella cache. Le richieste diverse da GET che contengono questa
intestazione vengono passate al server di origine.
Se Apigee riceve una richiesta GET in entrata con questa intestazione:
Se | Poi |
---|---|
L'intestazione If-None-Match specifica uno o più ETag |
|
L'intestazione |
Apigee restituisce uno stato 304 Non modificato |
Viene trovata una voce della cache con lo stesso URI richiesta, ma contiene solo ETag deboli | La voce deve essere riconvalidata dal server di origine prima che Apigee la restituisca al client |
Apigee riceve un ETag da un server di origine | L'ETag viene restituito invariato al client |
If-Modified-Since
Se Apigee riceve un'intestazione If-Modified-Since
in una richiesta GET, la inoltra al server di origine anche se esiste una voce della cache valida.
In questo modo, vengono presi in considerazione eventuali aggiornamenti a una risorsa che non è passata da Apigee. Se il server di origine restituisce una nuova entità, Apigee sostituisce la voce della cache esistente con il nuovo valore. Se il server restituisce lo stato 304 Non modificato, Apigee restituisce il valore della risposta se l'intestazione Last-Modified
della risposta memorizzata nella cache indica che non è stata modificata.
Accept-Encoding
Quando una richiesta in arrivo include l'intestazione Accept-Encoding
con valori di
gzip
, deflate
o compress
, il server di origine risponde con
dati compressi. Quando le richieste successive non includono le intestazioni Accept-Encoding
,
si aspettano una risposta non compressa. Il meccanismo di memorizzazione nella cache delle risposte di Apigee è in grado di inviare risposte sia compresse che non compresse a seconda delle intestazioni in arrivo senza tornare al server di origine.
Puoi aggiungere i valori dell'intestazione Accept alle chiavi della cache per renderle più significative per ogni elemento memorizzato nella cache. Per maggiori dettagli, consulta "Configurazione di una chiave della cache" in Norme della cache delle risposte.