2. Il campo di intestazione di risposta HTTP Cache-Status

Il campo di intestazione di risposta HTTP Cache-Status indica come le cache hanno gestito quella risposta e la sua richiesta corrispondente. La sintassi di questo campo di intestazione è conforme a [STRUCTURED-FIELDS].

Il suo valore è una List. Ogni membro della List rappresenta una cache che ha gestito la richiesta. Il primo membro rappresenta la cache più vicina al server di origine, e l'ultimo membro rappresenta la cache più vicina all'utente (possibilmente inclusa la cache dello user agent stesso se aggiunge un valore).

Le cache determinano quando è appropriato aggiungere il campo di intestazione Cache-Status a una risposta. Alcune potrebbero aggiungerlo a tutte le risposte, mentre altre potrebbero farlo solo quando specificamente configurate per farlo, o quando la richiesta contiene un campo di intestazione che attiva una modalità di debug. Vedere la sezione 6 per le considerazioni sulla sicurezza correlate.

Un intermediario NON DOVREBBE (SHOULD NOT) aggiungere un membro Cache-Status alle risposte che genera localmente, anche se tale intermediario contiene una cache, a meno che la risposta generata non sia basata su una risposta memorizzata (ad esempio, 304 (Not Modified) e 206 (Partial Content) sono entrambi basati su una risposta memorizzata). Ad esempio, un proxy che genera una risposta 400 a causa di una richiesta malformata non aggiungerà un valore Cache-Status, perché quella risposta è stata generata dal proxy, non dal server di origine.

Quando si aggiunge un valore al campo di intestazione Cache-Status, le cache DOVREBBERO (SHOULD) preservare il valore del campo esistente, per consentire il debug dell'intera catena di cache che gestiscono la richiesta.

Ogni membro della List identifica la cache che l'ha inserito, e questo identificatore DEVE (MUST) essere una String o un Token. A seconda del deployment, questo potrebbe essere un nome di prodotto o servizio (ad esempio, "ExampleCache" o "Example CDN"), un hostname ("cache-3.example.com"), un indirizzo IP o una stringa generata.

Ogni membro della lista può avere parametri che descrivono la gestione della richiesta da parte di quella cache. Sebbene questi parametri siano OPZIONALI (OPTIONAL), le cache sono incoraggiate a fornire quante più informazioni possibili.

Questa specifica definisce i seguenti parametri.

2.1. Il parametro hit

Il valore di "hit" è un Boolean che, quando vero, indica che la richiesta è stata soddisfatta dalla cache; cioè, non è stata inoltrata e la risposta è stata ottenuta dalla cache.

Una risposta che è stata originariamente prodotta dall'origine ma è stata modificata dalla cache (ad esempio, un codice di stato 304 o 206) è ancora considerata un hit, purché non sia stata inoltrata (ad esempio, per la validazione).

Una risposta che era nella cache ma non poteva essere utilizzata senza essere inoltrata (ad esempio, perché era obsoleta o parziale) non è considerata un hit. Si noti che una risposta obsoleta che viene utilizzata senza essere inoltrata (ad esempio, perché il server di origine non è disponibile) può essere considerata un hit.

"hit" e "fwd" sono esclusivi; solo uno di essi dovrebbe apparire su ogni membro della lista.

2.2. Il parametro fwd

"fwd", quando presente, indica che la richiesta è stata inoltrata verso l'origine; il suo valore è un Token che indica il motivo.

I seguenti valori di parametro sono definiti per spiegare perché la richiesta è stata inoltrata, dal più specifico al meno specifico:

bypass: La cache è stata configurata per non gestire questa richiesta.

method: La semantica del metodo di richiesta richiede che la richiesta sia inoltrata.

uri-miss: La cache non conteneva alcuna risposta corrispondente all'URI della richiesta.

vary-miss: La cache conteneva una risposta corrispondente all'URI della richiesta, ma non è riuscita a selezionare una risposta in base ai campi di intestazione di questa richiesta e ai campi di intestazione Vary memorizzati.

miss: La cache non conteneva alcuna risposta che potesse essere utilizzata per soddisfare questa richiesta (da utilizzare quando un'implementazione non può distinguere tra uri-miss e vary-miss).

request: La cache è stata in grado di selezionare una risposta fresca per la richiesta, ma la semantica della richiesta (ad esempio, le direttive della richiesta Cache-Control) non ne ha permesso l'uso.

stale: La cache è stata in grado di selezionare una risposta per la richiesta, ma era obsoleta.

partial: La cache è stata in grado di selezionare una risposta parziale per la richiesta, ma non conteneva tutti i range richiesti (o la richiesta era per la risposta completa).

Il motivo più specifico noto alla cache DOVREBBE (SHOULD) essere utilizzato, nella misura in cui sia possibile implementarlo. Vedere anche [HTTP-CACHING], sezione 4.

2.3. Il parametro fwd-status

Il valore di "fwd-status" è un Integer che indica quale codice di stato (vedere [HTTP], sezione 15) il server next-hop ha restituito in risposta alla richiesta inoltrata. Il parametro fwd-status ha senso solo quando fwd è presente. Se fwd-status non è presente ma il parametro fwd lo è, assume come valore predefinito il codice di stato inviato nella risposta.

Questo parametro è utile per distinguere i casi in cui il server next-hop invia una risposta 304 (Not Modified) a una richiesta condizionale o una risposta 206 (Partial Content) a causa di una richiesta di range.

2.4. Il parametro ttl

Il valore di "ttl" è un Integer che indica la rimanente freshness lifetime della risposta (vedere [HTTP-CACHING], sezione 4.2.1) come calcolata dalla cache, come numero intero di secondi, misurato il più vicino possibile al momento in cui la sezione di intestazione della risposta viene inviata dalla cache. Questo include la freshness assegnata dalla cache attraverso, ad esempio, euristiche (vedere [HTTP-CACHING], sezione 4.2.2), configurazione locale o altri fattori. Può essere negativo, per indicare l'obsolescenza.

2.5. Il parametro stored

Il valore di "stored" è un Boolean che indica se la cache ha memorizzato la risposta (vedere [HTTP-CACHING], sezione 3); un valore vero indica che l'ha fatto. Il parametro stored ha senso solo quando fwd è presente.

2.6. Il parametro collapsed

Il valore di "collapsed" è un Boolean che indica se questa richiesta è stata accorpata insieme a una o più altre richieste di inoltro (vedere [HTTP-CACHING], sezione 4). Se vero, la risposta è stata riutilizzata con successo; in caso contrario, è stata necessaria una nuova richiesta. Se non presente, la richiesta non è stata accorpata con altre. Il parametro collapsed ha senso solo quando fwd è presente.

2.7. Il parametro key

Il valore di "key" è una String che trasmette una rappresentazione della chiave di cache (vedere [HTTP-CACHING], sezione 2) utilizzata per la risposta. Si noti che questo può essere specifico dell'implementazione.

2.8. Il parametro detail

Il valore di "detail" è una String o un Token che consente alle implementazioni di trasmettere informazioni aggiuntive non catturate in altri parametri, come stati specifici dell'implementazione o altre metriche relative alla cache.

Ad esempio:

Cache-Status: ExampleCache; hit; detail=MEMORY

La semantica di un parametro detail è sempre specifica per la cache che l'ha inviato; anche se un parametro details di un'altra cache condivide lo stesso valore, potrebbe non significare la stessa cosa.

Questo parametro è intenzionalmente limitato. Se lo sviluppatore o l'operatore di un'implementazione ha bisogno di trasmettere informazioni aggiuntive in modo interoperabile, è incoraggiato a registrare parametri di estensione (vedere sezione 4) o definire un altro campo di intestazione.