Supporto per le intestazioni della risposta HTTP

Questa pagina si applica a Apigee e Apigee ibrido.

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 supporta attualmente 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) del backend.

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, è possibile che l'istruzione s-maxage dell'intestazione sostituisca potenzialmente 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. Queste intestazioni e questi meccanismi forniscono informazioni sulle risorse memorizzate nella cache. Consentono inoltre ai server di determinare come gestire i dati memorizzati nella cache. La specifica contiene informazioni dettagliate sulla memorizzazione nella cache in HTTP. Su internet sono inoltre disponibili molti blog, articoli e altre risorse che spiegano la memorizzazione nella cache HTTP.

Nota: uso delle intestazioni per influenzare le chiavi di cache e il TTL delle voci di cache Puoi fare in modo che Apigee utilizzi le intestazioni di risposta durante la creazione delle chiavi cache di risposta e l'impostazione del TTL delle voci di cache. Per farlo, utilizza questi elementi di flag del criterio ResponseCache:

• <UseResponseCacheHeaders>: se questo criterio è impostato su true, Apigee prenderà in considerazione 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 di cache" e <UseResponseCacheHeaders> in Criterio della cache delle risposte.
• <UseAcceptHeader>: se questo valore è impostato su true, Apigee utilizzerà le intestazioni di risposta Accept per aumentare la chiave cache. Per ulteriori informazioni, consulta <UseAcceptHeader> in Criterio della cache delle risposte.

Titolo	Assistenza
Controllo cache	Supportate sulle risposte restituite dai server di origine backend, ma non nelle richieste client. Apigee supporta un sottoinsieme di istruzioni.
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 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 per le risposte restituite dai server di origine 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à di intestazione della risposta Cache-Control definite nella specifica HTTP/1.1. Tieni presente quanto segue:

• Apigee non supporta le intestazioni Cache-Control ricevute con le richieste del client in entrata.
• Apigee supporta solo la nozione di cache pubbliche. Secondo la specifica HTTP, Cache-Control può essere pubblico (condiviso) o privato (utente singolo).
• Apigee supporta solo un sottoinsieme di istruzioni di risposta Cache-Control nella specifica HTTP/1.1. Per maggiori dettagli, consulta Supporto per le istruzioni di intestazione della risposta Cache-Control.

Supporto per le direttive di intestazione della risposta Cache-Control

Apigee supporta un sottoinsieme di direttive della specifica HTTP/1.1 sulle risposte dai server di origine. La seguente tabella descrive il supporto di Apigee per le direttive 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 sostituito dall'elemento <ExpirySettings> del criterio. Per ulteriori informazioni, consulta "Impostare la scadenza delle voci di cache" e <UseResponseCacheHeaders> in Criterio della cache delle risposte. Nota: i contenuti memorizzati nella cache con il criterio ResponseCache conserveranno il valore max-age impostato in base alla sua origine. Ciò significa che, se recuperati dalla cache, i contenuti potrebbero essere più vecchi di quanto suggerito dal valore max-age (più vecchi di quanto sia noto il client).
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 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 richiesta per restituire l'intera risposta. Se il server di origine restituisce una risposta completa, sostituisce la voce esistente della cache. Tutti i nomi di campo 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 questa istruzione viene ricevuta, la risposta dell'origine non viene memorizzata nella cache. 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 dell'origine, anche quando altre direttive indicano diversamente. Secondo la specifica HTTP/1.1, l'unica eccezione a questa regola è se la risposta include un'intestazione Autorizzazione.
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 sostituito dall'elemento <ExpirySettings> del criterio. Per ulteriori informazioni, consulta "Impostare la scadenza delle voci di cache" e <UseResponseCacheHeaders> in Criterio della cache delle risposte. Nota: i contenuti memorizzati nella cache con il criterio ResponseCache conserveranno il valore s-maxage impostato in base alla sua origine. Ciò significa che, se recuperati dalla cache, i contenuti potrebbero essere più vecchi di quanto suggerito dal valore di s-maxage (più vecchi di quanto sia noto al client).

Scadenza

Se 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 inattiva. Questa intestazione consente ai server di segnalare la possibilità di restituire un valore memorizzato nella cache in base a un timestamp.

Nota: le istruzioni dell'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 di cache" e <UseResponseCacheHeaders> in Criterio della cache delle risposte.

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

Scade: Gio, 01 dic 1994 16:00:00 GMT

Per informazioni dettagliate sui formati data/ora HTTP, consulta la pagina relativa ai formati di data e ora nella specifica HTTP/1.1.

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

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

ETag

Un tag entità (ETag) è un identificatore associato a una risorsa richiesta. Tramite 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 la risposta nella cache se non corrisponde a ciò che è attualmente memorizzato nella cache. Potrebbe restituire la risorsa memorizzata nella cache in caso di corrispondenza degli ETag.

Quando un endpoint di destinazione invia una risposta ad Apigee con un ETag, Apigee memorizza l'ETag nella cache insieme alla risposta.

Puoi trovare ulteriori informazioni sui tag delle entità in Parametri di protocollo nella specifica HTTP/1.1.

If-Match

Con l'intestazione della richiesta If-Match, un'entità memorizzata nella cache è aggiornata 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 qualsiasi struttura di memorizzazione nella cache dell'origine abbia la possibilità di elaborare la richiesta.

Per ulteriori informazioni su If-Match, consulta le Definizioni dei campi di 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 le voci della cache non scadute per la risorsa specificata e confronta gli eventuali ETag efficaci presenti in queste voci memorizzate nella cache con quelli specificati 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 passata al server di origine per garantire che tutte le strutture di memorizzazione nella cache dell'origine abbiano 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 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	Apigee recupera le voci della cache non scadute per l'URI specificato e confronta gli eventuali ETag efficaci su queste voci memorizzate nella cache con quelli specificati nell'intestazione If-None-Match. Se viene trovata una corrispondenza, Apigee restituisce lo stato 304, non modificata. 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 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, viene passata al server di origine anche se esiste una voce cache valida.

In questo modo, vengono presi in considerazione eventuali aggiornamenti di una risorsa che non è passata attraverso Apigee. Se il server di origine restituisce una nuova entità, Apigee sostituisce la voce esistente della cache 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 è cambiata.

Accetta codifica

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

È possibile aggiungere i valori dell'intestazione Accetta alle chiavi cache per rendere le chiavi più significative per ogni elemento memorizzato nella cache. Per maggiori dettagli, consulta "Configurazione di una chiave cache" in Criterio della cache di risposta.