Supporto per le intestazioni della risposta HTTP

Questa pagina si applica ad Apigee e Apigee hybrid.

Visualizza la documentazione di Apigee Edge.

Questo argomento descrive in che modo Apigee gestisce le intestazioni di memorizzazione nella cache HTTP/1.1 quando utilizzi il criterio ResponseCache. Apigee attualmente supporta un sottoinsieme di intestazioni e istruzioni 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 alcune intestazioni Apigee interviene in base alle relative istruzioni. In alcuni casi, queste intestazioni 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, puoi fare in modo che l'istruzione s-maxage dell'intestazione possa sostituire altre impostazioni di scadenza nel criterio.

Nota: la specifica HTTP/1.1 descrive le intestazioni di memorizzazione nella cache standard e i meccanismi di controllo che supportano la memorizzazione nella cache lungo la catena di richiesta/risposta HTTP. Intestazioni e meccanismi forniscono informazioni sulle risorse memorizzate nella cache. Inoltre, aiutano i server a determinare come gestire i dati memorizzati nella cache. La specifica contiene informazioni dettagliate sulla memorizzazione nella cache in HTTP. Su internet sono disponibili molti blog, articoli e altre risorse che spiegano la memorizzazione nella cache HTTP.

Nota: utilizzo delle intestazioni per influenzare le chiavi cache e il TTL delle voci della cache Puoi chiedere ad Apigee di utilizzare le intestazioni di risposta durante la creazione delle chiavi cache di risposta e l'impostazione del TTL delle voci della cache. Per farlo, utilizza questi elementi di segnalazione del criterio ResponseCache:

• <UseResponseCacheHeaders>: se il criterio è impostato su true, Apigee considererà le intestazioni della risposta HTTP utilizzate durante l'impostazione della "durata (TTL)" della risposta nella cache. Per maggiori dettagli, consulta "Impostare la scadenza delle voci della cache" e <UseResponseCacheHeaders> in Criterio cache risposta.
• <UseAcceptHeader>: se questa opzione è impostata su true, Apigee utilizzerà le intestazioni Accept di risposta per aumentare la chiave cache. Per saperne di più, consulta <UseAcceptHeader> in Criterio della cache di risposta.

Titolo	Assistenza
Controllo cache	Supportata sulle risposte restituite dai server di origine di backend, ma non dalle richieste del client. Apigee supporta un sottoinsieme di istruzioni.
Scadenza	Supportato. Può essere sostituita.
Tag di entità (ETag)	Comportamento specifico per If-Match e If-None-Match.
Se-modificato-da	Nelle richieste GET, l'intestazione viene passata al server di origine anche se esiste una voce di cache valida.
Accetta-codifica	Apigee invia risposte compresse o non compresse a seconda delle intestazioni in entrata.

Cache-Control

Apigee supporta l'intestazione Cache-Control solo sulle 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à dell'intestazione della risposta Cache-Control definito 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 istruzioni di risposta Cache-Control nella specifica HTTP/1.1. Per maggiori dettagli, consulta Assistenza per le direttive dell'intestazione delle risposte Cache-Control.

Supporto per le direttive dell'intestazione della risposta Cache-Control

Apigee supporta le istruzioni di un sottoinsieme della specifica HTTP/1.1 sulle risposte dai server di origine. La tabella seguente descrive il supporto di Apigee per le istruzioni di intestazione della risposta HTTP Cache-Control.

Per informazioni più dettagliate sulle istruzioni elencate qui, consulta Cache-Control 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 l'elemento <UseResponseCacheHeaders> su true, la risposta può essere memorizzata nella cache per il numero di secondi specificato da questa istruzione. Questa istruzione viene sostituita dall'istruzione s-maxage e sostituisce l'intestazione Expires. Può anche essere sostituita dall'elemento <ExpirySettings> del criterio. Per saperne di più, consulta "Impostare la scadenza delle voci della cache" e <UseResponseCacheHeaders> in Criterio cache risposta. Nota: i contenuti memorizzati nella cache con il criterio ResponseCache manterranno il valore di età massima impostato dalla relativa origine. Ciò significa che quando vengono recuperati dalla cache, i contenuti potrebbero essere più vecchi di quanto suggerito dal valore massimo di età (meno recenti di quanto il client sappia).
must-revalidate	Non supportati. Tutte le voci della cache vengono eliminate da Apigee non appena scadono.
no-cache	Apigee memorizza nella cache la risposta di origine, ma deve essere riconvalida 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, salvando così l'elaborazione necessaria per restituire l'intera risposta. Se il server di origine restituisce una risposta completa, sostituisce la voce della cache esistente. I nomi dei campi specificati con questa istruzione vengono ignorati. Nota: l'intestazione HTTP/1.0 Pragma: no-cache viene considerata equivalente a Cache-Control: no-cache.
no-store	Non supportati.
no-transform	Non supportati.
private	Non supportati. Se viene ricevuta questa istruzione, la risposta di origine non viene memorizzata nella cache. Tutti i nomi dei campi 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 di origine, anche quando le 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 <UseResponseCacheHeaders> su true, la risposta può essere memorizzata nella cache per il numero di secondi specificato da questa istruzione. Questa istruzione sostituisce l'istruzione max-age e l'intestazione Expires. Può essere sostituita dall'elemento <ExpirySettings> del criterio. Per saperne di più, consulta "Impostare la scadenza delle voci della cache" e <UseResponseCacheHeaders> in Criterio cache risposta. Nota: i contenuti memorizzati nella cache con il criterio ResponseCache manterranno il valore s-maxage impostato dalla relativa origine. Ciò significa che quando vengono recuperati dalla cache, i contenuti potrebbero essere più vecchi di quanto suggerito dal valore s-maxage (meno recenti di quanto il client sappia).

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. Questa intestazione consente ai server di indicare quando è consentito restituire un valore memorizzato nella cache in base a un timestamp.

Nota: le istruzioni di intestazione Cache-Control max-age e s-maxage hanno la precedenza e sostituiscono l'intestazione Expires. Per saperne di più, consulta "Impostare la scadenza delle voci della cache" e <UseResponseCacheHeaders> in Criterio cache risposta.

I formati di data accettabili per l'intestazione Expires sono descritti nella specifica HTTP/1.1. Ad esempio:

Scadenza: gio 01 dic 1994 16:00:00 GMT

Per informazioni dettagliate sui formati di data/ora HTTP, consulta la sezione Formati di data/ora nella specifica HTTP/1.1.

Nota: sebbene la sezione 14.21 della specifica indichi che un valore Expires superiore a un anno nel futuro indica che una voce della cache non scade mai, Apigee interpreta questo valore nel senso che la voce deve essere memorizzata nella cache fino alla data e all'ora specificate.

Per maggiori informazioni sull'intestazione Expires, consulta le definizioni dei campi intestazione nella specifica HTTP/1.1.

ETag

Un tag di 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 ciò che è attualmente memorizzato 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 l'ETag nella cache insieme alla risposta.

Per saperne di più sui tag entità, consulta Parametri di protocollo nella 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. Tutte le richieste diverse da GET che specificano un'intestazione If-Match vengono passate al server di origine per garantire che le strutture di memorizzazione nella cache di origine abbiano la possibilità di elaborare la richiesta.

Per saperne di più su If-Match, consulta le definizioni dei campi intestazione nella 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	Apigee recupera tutte le voci non scadute della cache per la risorsa specificata e confronta eventuali ETag efficaci su queste voci memorizzate nella cache con quelle specificate nell'intestazione If-Match. Se viene trovata una corrispondenza, viene restituita la voce della cache. In caso contrario, la richiesta viene passata al server di origine.
L'intestazione If-Match specifica "*"	La richiesta viene trasmessa al server di origine per garantire che tutti i servizi di memorizzazione nella cache dell'origine abbiano la possibilità di elaborarla
È stata trovata una voce della cache con lo stesso URI di richiesta, ma contenente solo ETag deboli	La voce deve essere riconvalida dal server di origine prima di essere restituita al client
Gli ETag provengono dal server di origine.	L'ETag viene restituito al cliente senza modifiche

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	Apigee recupera tutte le voci non scadute della cache per l'URI specificato e confronta eventuali ETag efficaci su queste voci memorizzate nella cache con quelle specificate nell'intestazione If-None-Match. Se viene trovata una corrispondenza, Apigee restituisce lo stato 304 Not Modified (Non modificato). Se non viene trovata alcuna corrispondenza, Apigee passa la richiesta al server di origine.
L'intestazione If-None-Match specifica "*" ed esiste una voce memorizzata nella cache non scaduta per l'URI richiesto	Apigee restituisce lo stato 304 Not Modified (Non modificato)
È stata trovata una voce della cache con lo stesso URI di richiesta, ma contenente solo ETag deboli	La voce deve essere riconvalida dal server di origine prima che Apigee la restituisca al client
Apigee riceve un ETag da un server di origine	L'ETag viene restituito al cliente senza modifiche

Se-modificato-da

Se Apigee riceve un'intestazione If-Modified-Since in una richiesta GET, viene passata al server di origine anche in presenza di una voce di cache valida.

In questo modo, verranno presi in considerazione eventuali aggiornamenti a una risorsa che non è passata attraverso 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 uno stato 304 Not Modified, Apigee restituisce il valore di risposta se l'intestazione Last-Modified della risposta memorizzata nella cache indica che non è stata modificata.

Accetta-codifica

Quando una richiesta in entrata include l'intestazione Accept-Encoding con valori di gzip, deflate o compress, il server di origine risponde con dati compressi. Quando le richieste successive sono prive dell'intestazione 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 entrata, senza tornare al server di origine.

Puoi aggiungere i valori di intestazione Accetta alle chiavi cache per renderli più significativi per ciascun elemento memorizzato nella cache. Per maggiori dettagli, consulta "Configurazione di una chiave cache" in Criterio cache risposta.