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

Questo argomento descrive in che modo Edge gestisce le intestazioni di memorizzazione nella cache HTTP/1.1 quando utilizzi il criterio ResponseCache. Al momento Apigee Edge 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) del backend.

Inoltre, con alcune intestazioni Edge 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.s-maxage

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

<UseResponseCacheHeaders>: se questo valore è impostato su true, Edge prenderà in considerazione le intestazioni di risposta HTTP utilizzate per impostare il "time to live" (TTL) della risposta 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, Edge utilizzerà le intestazioni di risposta Accept per aumentare la chiave della cache. Per saperne di più, consulta <UseAcceptHeader> nelle norme relative alla cache delle risposte.

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

Cache-Control

Apigee Edge supporta l'intestazione Cache-Control solo per le 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 Edge sia quelli creati utilizzando le chiamate API TargetServer.

Limitazioni del supporto di Cache-Control

Apigee Edge supporta un sottoinsieme di Cache-Control funzionalità delle intestazioni di risposta 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 direttive di risposta Cache-Control nella specifica HTTP/1.1. Per maggiori dettagli, consulta la sezione Supporto per le direttive delle intestazioni di risposta Cache-Control.

Supporto per le direttive delle intestazioni di 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 Edge per le direttive dell'intestazione della risposta HTTP Cache-Control.

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 il criterio 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 dall'intestazione `Expires`. Può anche essere ignorato dall'elemento `<ExpirySettings>` del criterio. 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 Edge non appena scadono.
`no-cache`	Edge memorizza nella cache la risposta dell'origine, ma deve essere convalidata di nuovo con il server di origine prima di essere utilizzata 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, 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. Eventuali nomi di campo specificati con questa direttiva 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 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 Edge non appena scadono.
`public`	Edge 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 l'elemento `<UseResponseCacheHeaders>` su `true`, la risposta può essere memorizzata nella cache per il numero di secondi specificato da questa direttiva. Questa istruzione sostituisce la direttiva `max-age` e l'intestazione `Expires`. Può essere ignorato dall'elemento `<ExpirySettings>` del criterio. 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, quando vengono recuperati dalla cache, i contenuti potrebbero essere meno recenti di quanto suggerito dal valore s-maxage (meno recenti di quanto il cliente sappia).

Scadenza

Quando il flag UseResponseCacheHeaders nel criterio ResponseCache è impostato su true, Edge 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 obsoleta. Questo intestazione consente ai server di indicare quando è consentito restituire un valore memorizzato nella cache basato su 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 della voce della cache" e <UseResponseCacheHeaders> in Norme relative alla cache delle risposte.

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

Scade il: 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 un valore Expires superiore a un anno nel futuro indica che una voce della cache non scade mai, Apigee interpreta questo valore come un'indicazione che la voce deve essere memorizzata nella cache fino alla data e all'ora specificate.

Per ulteriori informazioni sull'intestazione Expires, consulta Definizioni dei campi dell'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 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 scoprire di più sugli elementi Entity Tag nella sezione Parametri di protocollo della 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. Eventuali richieste diverse da GET che specificano un If-Match intestazione vengono trasmesse al server di origine per garantire che eventuali strutture di memorizzazione nella cache dell'origine abbiano la possibilità di elaborare la richiesta.

Puoi scoprire di più su If-Match nella sezione Definizioni dei campi dell'intestazione della specifica HTTP/1.1.

Se Edge 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 Edge 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 trasmessa al server di origine per garantire che eventuali strutture di memorizzazione nella cache dell'origine abbiano la possibilità di elaborarla
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 Edge riceve una richiesta GET in entrata con questa intestazione:

Se	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 eventuali ETag sicuri su queste voci memorizzate nella cache con quelli specificati nell'intestazione `If-None-Match`. Se viene trovata una corrispondenza, Edge restituisce uno stato 304 Non modificato. Se non viene trovata alcuna corrispondenza, Edge inoltra 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 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 Edge la restituisca al client
Edge riceve un ETag da un server di origine	L'ETag viene restituito invariato al client

If-Modified-Since

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

In questo modo, vengono considerati tutti gli aggiornamenti a una risorsa che non è passata da Apigee Edge. 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 della risposta se l'intestazione Last-Modified della risposta memorizzata nella cache indica che non è stata modificata.

Accept-Encoding

Quando una richiesta in arrivo 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 includono 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 maggiori dettagli, consulta "Configurazione di una chiave della cache" in Norme della cache delle risposte.