Questa pagina è stata tradotta dall'API Cloud Translation.

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 come Apigee gestisce le intestazioni di memorizzazione nella cache HTTP/1.1 quando utilizzi il criterio ResponseCache. Apigee attualmente supporta un sottoinsieme di intestazioni e direttive 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 determinate intestazioni Apigee interviene in base alle direttive. In alcuni casi, queste intestazioni della cache HTTP/1.1 ignorano qualsiasi comportamento specificato nelle norme ResponseCache. Ad esempio, se l'intestazione Cache-Control viene restituita da un server di backend, puoi fare in modo che la direttiva s-maxage dell'intestazione possa sostituire altre impostazioni di scadenza nella policy.

Nota: Utilizzo delle intestazioni per influenzare le chiavi della cache e il TTL delle voci della cache Puoi fare in modo che Apigee utilizzi le intestazioni di risposta per creare le chiavi della cache di risposta e impostare il TTL delle voci della cache. Per farlo, utilizza questi elementi flag del criterio ResponseCache:

<UseResponseCacheHeaders>: se questo valore è impostato su true, Apigee prenderà in considerazione le intestazioni della risposta HTTP utilizzate per impostare il "time to live" (TTL) della risposta nella cache. Per i dettagli, vedi "Impostazione della scadenza della voce della cache" e <UseResponseCacheHeaders> in Norme della cache delle risposte.
<UseAcceptHeader> -- When this is set to true, Apigee will use response Accept headers to augment the cache key. Per saperne di più, consulta <UseAcceptHeader> nelle norme sulla cache delle risposte.

Intestazione	Assistenza
Cache-Control	Supportato nelle risposte restituite dai server di origine di backend, ma non nelle richieste client. Apigee supporta un sottoinsieme di direttive.
Scadenza	Supportato. Può essere sostituito.
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.
Accept-Encoding	Apigee invia risposte compresse o non compresse a seconda delle intestazioni in entrata.

Cache-Control

Apigee supporta l'intestazione Cache-Control solo nelle 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 delle funzionalità delle intestazioni di risposta Cache-Control definite 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 il concetto di cache pubbliche. (Secondo la specifica HTTP, Cache-Control può essere pubblico (condiviso) o privato (per un singolo utente).)
Apigee supporta solo un sottoinsieme di direttive di risposta Cache-Control nelle specifiche HTTP/1.1. Per maggiori dettagli, consulta Supporto delle direttive dell'intestazione della risposta Cache-Control.

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

Apigee supporta un sottoinsieme di direttive della specifica HTTP/1.1 sulle risposte dei server di origine. 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 Cache-Control nelle specifiche HTTP/1.1.

Direttiva Cache-Control	Come Apigee elabora la direttiva
`cache-extension`	Non supportati.
`max-age`	Se le norme ResponseCache impostano l'elemento `<UseResponseCacheHeaders>` su `true`, la risposta può essere memorizzata nella cache per il numero di secondi specificato da questa direttiva. Questa direttiva viene sostituita dalla direttiva `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 Norme della cache delle risposte. Nota: i contenuti memorizzati nella cache con la policy 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 suggerisce il valore max-age (più vecchi di quanto sappia 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 di origine, ma deve essere convalidata nuovamente con il server di origine prima di essere utilizzata per soddisfare le richieste client successive. Questa regola consente all'origine di restituire una risposta 304 Not Modified 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, questa sostituisce la voce della cache esistente. Eventuali nomi di campi specificati con questa direttiva vengono ignorati. Nota:l'intestazione HTTP/1.0, `Pragma: no-cache`, è considerata equivalente 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 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 il contrario. In base alla specifica HTTP/1.1, l'unica eccezione a questa regola si verifica se la risposta include un'intestazione Authorization.
`s-maxage`	Se le norme ResponseCache impostano l'elemento `<UseResponseCacheHeaders>` su `true`, la risposta può essere memorizzata nella cache per il numero di secondi specificato da questa direttiva. Questa direttiva esegue l'override della direttiva `max-age` e dell'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 Norme della cache delle risposte. Nota:i contenuti memorizzati nella cache con il criterio ResponseCache manterranno il valore s-maxage impostato dalla sua origine. Ciò significa che, quando vengono recuperati dalla cache, i contenuti potrebbero essere più vecchi di quanto suggerisce il valore s-maxage (più vecchi di quanto sappia il client).

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 obsoleta. 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 e sostituiscono l'intestazione Expires. Per saperne di più, vedi "Impostazione della scadenza delle voci della cache" e <UseResponseCacheHeaders> in Norme della cache delle risposte.

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 Date/Time Formats nelle specifiche HTTP/1.1.

Nota: mentre 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 nel senso che la voce deve essere memorizzata nella cache fino alla data e ora specificate.

Per ulteriori informazioni sull'intestazione Expires, consulta Definizioni dei campi di intestazione nelle specifiche 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 quella attualmente memorizzata 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 nella cache l'ETag insieme alla risposta.

Puoi leggere ulteriori informazioni sui tag di entità in Protocol Parameters nelle specifiche HTTP/1.1.

If-Match

Con l'intestazione della richiesta If-Match, un'entità memorizzata nella cache è attuale se l'ETag nell'intestazione corrisponde all'ETag memorizzata 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.

Puoi scoprire di più su If-Match nelle definizioni dei campi di intestazione nelle specifiche 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 ETag sicuri in queste voci della 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 trasmessa al server di origine.
L'intestazione `If-Match` specifica "*"	La richiesta viene inoltrata al server di origine per garantire che eventuali strutture di memorizzazione nella cache di origine abbiano la possibilità di elaborarla.
Viene 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 al client senza modifiche

If-None-Match

Con l'intestazione If-None-Match, un'entità memorizzata nella cache è attuale se l'ETag nell'intestazione non corrisponde all'ETag memorizzata nella cache. Le richieste diverse da GET che contengono questa intestazione vengono trasmesse 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 ETag sicuri in queste voci della cache con quelli specificati nell'intestazione `If-None-Match`. Se viene trovata una corrispondenza, Apigee restituisce lo stato 304 Not Modified. Se non viene trovata alcuna corrispondenza, Apigee trasmette 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
Viene 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 che Apigee la restituisca al client
Apigee riceve un ETag da un server di origine	L'ETag viene restituito al client senza modifiche

If-Modified-Since

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

In questo modo, vengono presi in considerazione tutti gli aggiornamenti a una risorsa che non sono passati tramite 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 lo 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.

Accept-Encoding

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 arrivano senza 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 compresse e non compresse a seconda delle intestazioni in entrata senza tornare al server di origine.

Puoi aggiungere valori di intestazione Accept alle chiavi della cache per renderle più significative per ogni elemento memorizzato nella cache. Per maggiori dettagli, vedi "Configurazione di una chiave della cache" nelle norme della cache delle risposte.