Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Supporto per le intestazioni della risposta HTTP

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

Questo argomento descrive come Edge gestisce le intestazioni di memorizzazione nella cache HTTP/1.1 quando utilizzi la policy ResponseCache. Apigee Edge supporta attualmente un sottoinsieme delle intestazioni e delle 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, Edge esegue un'azione in base alle relative direttive. In alcuni casi, queste intestazioni della cache HTTP/1.1 sostituiscono il comportamento specificato nella policy ResponseCache. Ad esempio, se l'intestazione Cache-Control viene restituita da un server di backend, puoi avere la direttiva s-maxage dell'intestazione che può potenzialmente 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 Edge utilizzi le intestazioni della risposta quando crea le chiavi della cache delle risposte e imposta il TTL delle voci della cache. Per farlo, utilizza questi elementi flag della policy ResponseCache:

<UseResponseCacheHeaders> -- Se questo valore è impostato su true, Edge considera le intestazioni della risposta HTTP utilizzate per impostare il "time to live" (TTL) della risposta nella cache. Per i dettagli, consulta "Impostazione della scadenza delle voci della cache" e <UseResponseCacheHeaders> in policy ResponseCache.
<UseAcceptHeader> -- Se questo valore è impostato su true, Edge utilizzerà le intestazioni Accept della risposta per aumentare la chiave cache. Per saperne di più, consulta <UseAcceptHeader> nella policy ResponseCache.

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

Cache-Control

Apigee Edge 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 dei client sia nelle risposte dei 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 delle 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 dei client in entrata.
Apigee Edge supporta solo la nozione di cache pubbliche. (Secondo la specifica HTTP, Cache-Control può essere pubblico (condiviso) o privato (utente singolo ).)
Apigee Edge supporta solo un sottoinsieme delle direttive di risposta Cache-Control nella specifica HTTP/1.1. Per i dettagli, consulta Supporto per le direttive dell'intestazione della risposta Cache-Control.

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

Apigee supporta un sottoinsieme di direttive della specifica HTTP/1.1 nelle risposte dei server di origine. La tabella seguente descrive il supporto di Apigee Edge per le direttive dell'intestazione della risposta Cache-Control HTTP.

Per informazioni più dettagliate sulle direttive elencate qui, consulta Cache-Control nella specifica HTTP/1.1.

Direttiva Cache-Control	Come Apigee Edge elabora la direttiva
`cache-extension`	Non supportati.
`max-age`	Se la policy ResponseCache imposta 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' `Expires` intestazione. Può anche essere sostituita dall'elemento `<ExpirySettings>` della policy. Per saperne di più, consulta "Impostazione della scadenza delle voci della cache" e `<UseResponseCacheHeaders>` nella policy ResponseCache. 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 sa il client knows).
`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 di origine, ma deve essere riconvalidata con il server di origine prima di essere utilizzata per soddisfare le richieste dei 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, sostituisce la voce della cache esistente. I nomi dei campi specificati con questa direttiva vengono ignorati. Nota: l'intestazione HTTP/1.0, `Pragma: no-cache` viene trattata come equivalente a `Cache-Control: no-cache`.
`no-store`	Non supportati.
`no-transform`	Non supportati.
`private`	Non supportati. Se viene ricevuta questa direttiva, la risposta di 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 Edge non appena scadono.
`public`	Edge memorizza nella cache la risposta di origine, anche quando altre direttive indicano diversamente. In base alla specifica HTTP/1.1, l'unica eccezione a questa regola è se la risposta include un' intestazione Authorization.
`s-maxage`	Se la policy ResponseCache imposta l'elemento `<UseResponseCacheHeaders>` su `true`, la risposta può essere memorizzata nella cache per il numero di secondi specificato da questa direttiva. Questa direttiva sostituisce la direttiva `max-age` e l' `Expires` intestazione. Può essere sostituita dall'elemento `<ExpirySettings>` della policy. Per saperne di più, consulta "Impostazione della scadenza delle voci della cache" e `<UseResponseCacheHeaders>` nella policy ResponseCache. Nota: i contenuti memorizzati nella cache con la policy 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 suggerisce il valore s-maxage (più vecchi di quanto sa il client conosce).

Scadenza

Quando il flag UseResponseCacheHeaders nella policy ResponseCache è impostato su true, Edge può utilizzare l'intestazione Expires per determinare il time to live (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 segnalare quando è possibile restituire un valore memorizzato nella cache in base a un timestamp.

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

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

Expires: Thu, 01 Dec 1994 16:00:00 GMT

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

Nota: mentre la sezione 14.21 della specifica indica che un valore Expires di oltre 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 all'ora specificate.

Per saperne di più sull'intestazione Expires, consulta Definizioni dei campi di 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 quella attualmente memorizzata 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.

Puoi saperne di più sui tag di entità in Parametri del protocollo nella specifica 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 memorizzato nella cache. Tutte le richieste diverse da GET che specificano un'intestazione If-Match vengono trasmesse al server di origine per garantire che eventuali funzionalità di memorizzazione nella cache di origine abbiano la possibilità di elaborare la richiesta.

Puoi saperne di più su If-Match in 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:

Se non visualizzi l'icona	Poi
L'intestazione `If-Match` specifica uno o più ETag	Apigee Edge recupera eventuali voci della cache non scadute per la risorsa specificata e confronta gli ETag forti di queste voci della 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 eventuali funzionalità di memorizzazione nella cache di origine abbiano la possibilità di elaborare la richiesta
Viene 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 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 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:

Se non visualizzi l'icona	Poi
L'intestazione `If-None-Match` specifica uno o più ETag	Apigee Edge recupera eventuali voci della cache non scadute per l'URI specificato e confronta gli ETag forti di queste voci della cache con quelli specificati nell' `If-None-Match` intestazione. Se viene trovata una corrispondenza, Edge restituisce uno stato 304 Not Modified. Se non viene trovata alcuna corrispondenza, Edge passa la richiesta al server di origine.
L'`If-None-Match` header specifica "*" ed esiste una voce della cache non scaduta per l'URI richiesto	Edge restituisce uno stato 304 Not Modified
Viene 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 Edge la restituisca al client
Edge riceve un ETag da un server di origine	L'ETag viene restituito al client senza modifiche

If-Modified-Since

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 della cache valida.

In questo modo si garantisce che vengano presi in considerazione eventuali aggiornamenti a una risorsa che non sono passati tramite Apigee Edge e che sono stati contabilizzati. Se il server di origine restituisce una nuova entità, Edge sostituisce la voce della cache esistente con il nuovo valore. Se il server restituisce uno stato 304 Not Modified, Edge restituisce il valore della 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 i 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 i valori dell'intestazione Accept alle chiavi della cache per renderle più significative per ogni elemento memorizzato nella cache. Per maggiori dettagli, consulta "Configurazione di una chiave cache" in ResponseCache.