Supporto per le intestazioni della risposta HTTP

Questa pagina si applica a Apigee e Apigee ibridi.

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. 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 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.

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

Nota: utilizzo delle intestazioni per influenzare le chiavi della cache e il TTL delle voci della cache Puoi chiedere ad Apigee di utilizzare le intestazioni di risposta durante la creazione delle chiavi della cache di risposta e l'impostazione del TTL delle voci della cache. Da fare Usa questi elementi del flag del criterio ResponseCache:

• <UseResponseCacheHeaders>: se impostato su true, Apigee prenderà in considerazione le intestazioni delle risposte HTTP utilizzate durante l'impostazione della durata (TTL) (TTL) del nella cache. Per maggiori dettagli, consulta "Impostare la scadenza della voce della cache" e <UseResponseCacheHeaders> in Norme relative alla cache delle risposte.
• <UseAcceptHeader>: se questo valore è impostato su true, Apigee usa le intestazioni di risposta Accept per aumentare la chiave cache. Per saperne di più, consulta <UseAcceptHeader> nelle norme relative alla cache delle risposte.

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 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.
Accetta-codifica	Apigee invia risposte compresse o non compresse a seconda delle intestazioni in arrivo.

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à di intestazione delle risposte 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 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 per le risposte dei server di origine. La tabella seguente descrive il supporto di Apigee per l'intestazione della risposta HTTP Cache-Control istruzioni.

Per informazioni più dettagliate sulle direttive 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 il valore <UseResponseCacheHeaders> su true, la risposta può essere memorizzata nella cache per il numero di secondi specificato da questa istruzione. Questa direttiva viene sostituita dalla direttiva s-maxage e dall'intestazione Expires. Può anche essere sostituito dal valore Elemento <ExpirySettings>. Per saperne di più, consulta "Impostazione della scadenza della voce della cache" e <UseResponseCacheHeaders> in Norme relative alla cache delle risposte. Nota: i contenuti memorizzati nella cache con il criterio ResponseCache manterranno il valore max-age impostato dalla relativa origine. Ciò significa che, quando vengono recuperati dalla cache, i contenuti potrebbero essere meno recenti di quanto suggerito dal valore max-age (o meno recenti di quanto il cliente 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 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 della cache esistente. Eventuali nomi di campo specificati con questa direttiva vengono ignorati. Nota: l'intestazione HTTP/1.0, Pragma: no-cache è trattati come equivalenti a Cache-Control: no-cache.
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 il valore <UseResponseCacheHeaders> su true, la risposta può essere memorizzata nella cache per il numero di secondi specificato da questa istruzione. Questa istruzione sostituisce la direttiva max-age e l'intestazione Expires. Può essere sostituito dal valore Elemento <ExpirySettings>. Per saperne di più, consulta "Impostazione della scadenza della voce della cache" e <UseResponseCacheHeaders> in Norme relative alla cache delle risposte. Nota: i contenuti memorizzati nella cache con il criterio ResponseCache manterranno il valore s-maxage impostato dalla relativa origine. Ciò significa che, una volta recuperati dalla cache, il contenuto potrebbe essere più vecchio di quanto suggerito dal valore s-maxage (più vecchio del client conosce).

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 è considerata non aggiornata. Questa intestazione consente ai server di segnalare quando è possibile restituire un valore memorizzato nella cache in base a un timestamp.

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

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.

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

Per ulteriori informazioni sull'intestazione Expires, vedi Definizioni dei campi di 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. Per Ad esempio, il server potrebbe memorizzare nuovamente la risposta nella cache se non corrisponde a ciò che è attualmente memorizzato 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.

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. Qualsiasi richiesta diversa da GET che specifica un If-Match vengono passate al server di origine per garantire che tutte le strutture di memorizzazione nella cache dell'origine abbiano un di elaborare la richiesta.

Puoi scoprire di più su If-Match in 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 eventuali voci della cache non scadute per la risorsa specificata e confronta eventuali ETag sicuri su queste voci memorizzate nella cache con quelli specificati nell'If-Match intestazione. 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 qualsiasi memorizzazione nella cache dell'origine hanno la possibilità di elaborare la richiesta
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	Apigee recupera le voci della cache non scadute per l'URI specificato confronta gli eventuali ETag efficaci presenti nelle voci memorizzate nella cache con quelli specificati 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 "*" e una voce memorizzata nella cache non scaduta l'URI richiesto esiste	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 cliente
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, trasmesso 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.

Accetta codifica

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 contengono 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 ulteriori dettagli, consulta "Configurazione di una chiave cache" nel Criterio della cache delle risposte.