Questa pagina è stata tradotta dall'API Cloud Translation.

Supporto per le intestazioni della risposta HTTP

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. informazioni

Questo argomento descrive in che modo Edge gestisce le intestazioni di memorizzazione nella cache HTTP/1.1 quando utilizzi il criterio ResponseCache. Apigee Edge attualmente supporta un sottoinsieme di istruzioni e intestazioni 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 Edge agisce in base alle loro istruzioni. 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, puoi fare in modo che l'istruzione s-maxage dell'intestazione sostituisca potenzialmente altre impostazioni di scadenza nel criterio.

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

<UseResponseCacheHeaders>: se è impostato su true, Edge considera 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 cache di risposta.
<UseAcceptHeader>: se è impostato su true, Edge utilizzerà le intestazioni Accept di risposta per aumentare la chiave cache. Per saperne di più, consulta <UseAcceptHeader> in Criterio cache delle risposte.

Titolo	Assistenza
Controllo cache	Supportato per le risposte restituite dai server di origine del backend, ma non per le richieste del client. Edge supporta un sottoinsieme di istruzioni.
Scadenza	Supportata. È possibile eseguire l'override.
Tag entità (ETag)	Comportamento specifico per If-Match e If-None-Match.
If-Modified-From	Nelle richieste GET, l'intestazione viene passata al server di origine anche se esiste una voce valida della cache.
Accetta-codifica	Edge invia risposte compresse o non compresse a seconda delle intestazioni in entrata.

Cache-Control

Apigee Edge supporta l'intestazione Cache-Control solo nelle risposte restituite dai server di origine del 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 Edge sia quelli creati utilizzando le chiamate API TargetServer.

Limitazioni del supporto di Cache-Control

Apigee Edge supporta un sottoinsieme di funzionalità dell'intestazione della risposta Cache-Control definite nella specifica HTTP/1.1. Tieni presente quanto segue:

Apigee Edge non supporta le intestazioni Cache-Control che arrivano con le richieste client in entrata.
Apigee Edge supporta solo la nozione di cache pubbliche. In base alla specifica HTTP, Cache-Control può essere pubblico (condiviso) o privato (singolo utente).
Apigee Edge supporta solo un sottoinsieme di istruzioni di risposta Cache-Control nella specifica HTTP/1.1. Per maggiori dettagli, vedi Supporto per le direttive dell'intestazione delle risposte Cache-Control.

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

Apigee supporta istruzioni di sottoinsiemi della specifica HTTP/1.1 sulle risposte dei server di origine. La tabella seguente descrive il supporto di Apigee Edge per le direttive dell'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 Edge elabora la direttiva
`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 saperne di più, consulta "Impostazione della scadenza delle voci della cache" e `<UseResponseCacheHeaders>` in Criterio 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 più vecchi di quanto suggerito dal valore di età massima (meno recenti di quanto il client sappia).
`must-revalidate`	Non supportati. Tutte le voci della cache vengono eliminate da Apigee Edge non appena scadono.
`no-cache`	Edge memorizza nella cache la risposta dell'origine, ma deve essere riconvalidata con il server di origine prima di essere utilizzata per soddisfare eventuali richieste 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 esistente della cache. 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 questa istruzione viene ricevuta, la risposta dell'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 Edge non appena scadono.
`public`	Edge memorizza nella cache la risposta dell'origine, anche quando altre direttive indicano il contrario. In base alla specifica HTTP/1.1, l'unica eccezione a questa regola è se la risposta include un'intestazione di 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 saperne di più, consulta "Impostazione della scadenza delle voci della cache" e `<UseResponseCacheHeaders>` in Criterio 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, quando vengono recuperati dalla cache, i contenuti potrebbero essere più vecchi di quanto suggerito dal valore s-maxage (anteriore di quanto non sia noto al client).

Scadenza:

Quando il flag UseResponseCacheHeaders nel criterio ResponseCache è impostato su true, Edge può usare l'intestazione Expires per determinare la durata (TTL) di una voce memorizzata nella cache. Questa intestazione specifica una data e un'ora dopo la quale la voce della cache di una risposta viene considerata obsoleta. Questa intestazione consente ai server di segnalare quando è consentito 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 cache di 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 di oltre un anno nel futuro indica che una voce della cache non scade mai, Apigee interpreta tale valore per indicare 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 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 a Edge con un ETag, Edge memorizza nella cache l'ETag insieme alla risposta.

Ulteriori informazioni sui tag entità sono disponibili in Parametri di protocollo nella specifica HTTP/1.1.

Se corrispondente

Con l'intestazione della richiesta If-Match, è corrente un'entità memorizzata nella cache se l'ETag nell'intestazione corrisponde all'ETag memorizzato nella cache. Tutte le richieste diverse da GET che specificano un'intestazione If-Match vengono trasmesse al server di origine per garantire che tutte le strutture di memorizzazione nella cache dell'origine abbiano la possibilità di elaborare la richiesta.

Per saperne di più su If-Match, consulta le definizioni dei campi di intestazione nella specifica HTTP/1.1.

Se Edge riceve una richiesta GET in entrata da un client che include un'intestazione If-Match:

IF	Poi
L'intestazione `If-Match` specifica uno o più ETag	Apigee Edge recupera tutte le voci di cache non scadute per la risorsa specificata e confronta eventuali ETag efficaci su 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 trasmessa al server di origine per garantire che tutti i servizi di memorizzazione nella cache dell'origine possano elaborare la richiesta
È stata trovata una voce della cache con lo stesso URI di 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 cliente

Se non esistono corrispondenze

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 Edge riceve una richiesta GET in entrata con questa intestazione:

IF	Poi
L'intestazione `If-None-Match` specifica uno o più ETag	Apigee Edge recupera eventuali voci di cache non scadute per l'URI specificato e confronta gli ETag efficaci su queste voci memorizzate nella cache con quelli specificati nell'intestazione `If-None-Match`. Se viene trovata una corrispondenza, Edge restituisce lo stato 304 Non modificato. Se non viene trovata alcuna corrispondenza, Edge 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	Edge 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 riconvalidata dal server di origine prima che Edge la restituisca al client
Edge riceve un ETag da un server di origine	L'ETag viene restituito invariato al cliente

Se-modificato-da

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

In questo modo, tutti gli aggiornamenti a una risorsa che non sono passati attraverso Apigee Edge verranno presi in considerazione. Se il server di origine restituisce una nuova entità, Edge sostituisce la voce della cache esistente con il nuovo valore. Se il server restituisce lo stato 304 Non modificato, Edge 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 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.

Puoi aggiungere valori di intestazione Accept alle chiavi cache per renderle più significative per ciascun elemento memorizzato nella cache. Per maggiori dettagli, consulta "Configurazione di una chiave cache" in Criterio cache delle risposte.