Questa pagina si applica a Apigee e Apigee ibridi.
Visualizza documentazione di Apigee Edge.
Questo argomento descrive come Apigee gestisce le intestazioni di memorizzazione nella cache HTTP/1.1 quando utilizzi criterio ResponseCache. Apigee supporta attualmente un sottoinsieme di intestazioni di memorizzazione nella cache HTTP/1.1 direttive (le funzionalità non supportate sono elencate in questo argomento) ricevute dalla destinazione del backend (origine) server web.
Inoltre, con alcune intestazioni Apigee agisce in base alle proprie istruzioni. In alcuni casi,
queste intestazioni cache HTTP/1.1 eseguono l'override di qualsiasi comportamento specificato nel criterio ResponseCache.
Ad esempio, se l'intestazione Cache-Control
viene restituita da un server di backend, puoi
fare in modo che l'istruzione s-maxage
dell'intestazione possa potenzialmente sostituire altre impostazioni di scadenza
nelle norme.
Intestazione | Assistenza |
---|---|
Controllo cache | Supportate sulle risposte restituite dai server di origine backend, ma non nelle richieste client. Apigee supporta un sottoinsieme di direttive. |
Scadenza | Supportata. Può essere sostituito. |
Tag di entità (ETag) | Comportamento specifico per If-Match e If-None-Match. |
Dal momento che è stata modificata | Nelle richieste GET, l'intestazione viene passata al server di origine anche se una voce di cache valida esiste già. |
Accetta-codifica | Apigee invia risposte compresse o non compresse a seconda delle richieste intestazioni. |
Cache-Control
Apigee supporta l'intestazione Cache-Control
solo per le risposte restituite da
server di origine backend (la specifica HTTP/1.1 consente l'intestazione Cache-Control
nei
richieste del client e le 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
in arrivo richieste del client. - 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 istruzioni di risposta
Cache-Control
nel HTTP/1.1. Vedi Supporto per istruzioni di intestazione di risposta Cache-Control per maggiori dettagli.
Supporto per le direttive di intestazione della risposta Cache-Control
Apigee supporta un sottoinsieme di direttive della specifica HTTP/1.1 sulle risposte dall'origine server web. 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 Controllo cache nella specifica HTTP/1.1.
Direttiva Cache-Control | In che modo Apigee elabora l'istruzione |
cache-extension |
Non supportati. |
max-age |
Se il criterio ResponseCache imposta il valore 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 riconvalidata con il server di origine prima di essere utilizzato per soddisfare le successive richieste del cliente. Questa regola consente all'origine per restituire una risposta 304 Non modificata per indicare che la risposta deve essere dalla cache, salvando così l'elaborazione necessaria per restituire l'intera risposta. Se il server di origine restituisce una risposta completa, sostituisce la voce esistente della cache. Qualsiasi i nomi dei campi specificati con questa istruzione vengono ignorati. |
no-store |
Non supportati. |
no-transform |
Non supportati. |
private |
Non supportati. Se questa istruzione viene ricevuta, la risposta dell'origine non viene memorizzata nella cache. Qualsiasi 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 quando altre direttive indicano diversamente. In base alle HTTP/1.1, l'unica eccezione a questa regola è se la risposta include un Intestazione di autorizzazione. |
s-maxage |
Se il criterio ResponseCache imposta il valore 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 di cache di una risposta
è considerata obsoleta. Questa intestazione consente ai server di segnalare quando è possibile restituire un valore memorizzato nella cache
in base a un timestamp.
I formati di data accettabili per l'intestazione Expires
sono descritti nella sezione HTTP/1.1
la specifica del container. Ad esempio:
Scade: Gio, 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. L'utilizzo di un ETag, il 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. it 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 l'ETag nella cache insieme con la risposta.
Puoi trovare ulteriori informazioni sui tag entità in Parametri di protocollo nella specifica HTTP/1.1.
If-Match
Con l'intestazione della richiesta If-Match
, un'entità memorizzata nella cache è corrente se l'ETag nel
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
in
Definizioni dei campi dell'intestazione
nella specifica HTTP/1.1.
Se Apigee riceve una richiesta GET in entrata da un client che include una If-Match
intestazione:
Se | Poi |
---|---|
L'intestazione If-Match specifica uno o più ETag |
|
L'intestazione If-Match specifica "*" |
La richiesta viene passata al server di origine per garantire che qualsiasi memorizzazione nella cache dell'origine hanno la possibilità di elaborare la richiesta |
È stata trovata una voce della cache con lo stesso URI della richiesta, ma contiene solo ETag deboli | La voce deve essere riconvalidata dal server di origine prima di essere restituita al cliente |
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 nel
l'intestazione non corrisponde all'ETag memorizzato nella cache. Richieste diverse da GET che lo contengono
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 lo stato 304 Non modificato |
È stata trovata una voce della cache con lo stesso URI della 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 |
Se-Modificato-Da
Se Apigee riceve un'intestazione If-Modified-Since
in una richiesta GET,
passata al server di origine anche se esiste una voce di cache valida.
Ciò garantisce che tutti gli aggiornamenti di una risorsa che non sono passati attraverso Apigee vengano
preso in considerazione. Se il server di origine restituisce una nuova entità, Apigee sostituisce la cache esistente
con il nuovo valore. Se il server restituisce lo stato 304 Non modificato, Apigee restituisce lo stato
valore di risposta se l'intestazione Last-Modified
della risposta memorizzata nella cache indica che ha
non modificato.
Accept-Encoding
Quando una richiesta in entrata include l'intestazione Accept-Encoding
con i valori di
gzip
, deflate
o compress
, il server di origine risponde con
di dati compressi. Quando le richieste successive non includono le intestazioni Accept-Encoding
,
si aspettano una risposta non compressa. Il meccanismo di memorizzazione nella cache di risposta di Apigee è in grado di inviare
risposte sia compresse che non compresse a seconda delle intestazioni in arrivo senza tornare indietro
al server di origine.
Puoi aggiungere i valori dell'intestazione Accetta alle chiavi cache per rendere le chiavi più significative per ogni elemento memorizzato nella cache. Per ulteriori dettagli, consulta "Configurazione di una chiave cache" nel Criterio della cache delle risposte.