1. Introduzione (Introduction)
HTTP viene solitamente utilizzato per sistemi informativi distribuiti in cui le prestazioni possono essere migliorate tramite l'uso di cache di risposta. Questo documento definisce gli aspetti di HTTP/1.1 relativi alla memorizzazione nella cache e al riutilizzo dei messaggi di risposta.
Una cache HTTP è un archivio locale per i messaggi di risposta e il sottosistema che ne controlla l'archiviazione, il recupero e l'eliminazione. Una cache memorizza le risposte cachesabili per ridurre il tempo di risposta e il consumo di larghezza di banda di rete per le richieste equivalenti future. Qualsiasi client o server PUÒ (MAY) utilizzare una cache, sebbene un server che funge da tunnel non possa utilizzare una cache.
Una cache condivisa (Shared Cache) è una cache che memorizza risposte destinate a essere riutilizzate da più di un utente; le cache condivise sono solitamente (ma non sempre) fornite come parte di un intermediario. Una cache privata (Private Cache), invece, è dedicata a un singolo utente; sono spesso fornite come componente di un user agent.
L'obiettivo della memorizzazione nella cache in HTTP/1.1 è di migliorare in modo sostanziale le prestazioni riutilizzando un precedente messaggio di risposta per soddisfare una richiesta corrente. Una risposta memorizzata è considerata « fresca » (Fresh), come definito nella sezione 4.2, se la risposta può essere riutilizzata senza « convalida » (Validation) (verifica presso il server di origine che la risposta memorizzata nella cache sia ancora valida per questa richiesta). Una risposta fresca può quindi ridurre sia la latenza sia l'overhead di rete a ogni riutilizzo. Se una risposta memorizzata nella cache non è fresca, può comunque rimanere riutilizzabile se può essere aggiornata tramite convalida (sezione 4.3) o se l'origine non è disponibile (sezione 4.2.4).
1.1. Conformità e gestione degli errori (Conformance and Error Handling)
Le parole chiave « MUST », « MUST NOT », « REQUIRED », « SHALL », « SHALL NOT », « SHOULD », « SHOULD NOT », « RECOMMENDED », « MAY » e « OPTIONAL » in questo documento devono essere interpretate come descritto in [RFC2119].
I criteri di conformità e le considerazioni sulla gestione degli errori sono definiti nella sezione 2.5 di [RFC7230].
1.2. Notazione di sintassi (Syntax Notation)
Questa specifica utilizza la notazione ABNF (Augmented Backus-Naur Form) di [RFC5234] con un'estensione di lista definita nella sezione 7 di [RFC7230] che consente una definizione compatta di elenchi separati da virgole utilizzando un operatore '#' (in modo simile all'operatore '*' che indica la ripetizione). L'appendice B descrive le regole importate da altri documenti. L'appendice C mostra la grammatica collezionata con tutti gli operatori di lista espansi in notazione ABNF standard.
1.2.1. Secondi delta (Delta Seconds)
La regola delta-seconds indica un numero intero non negativo che rappresenta il tempo in secondi.
delta-seconds = 1*DIGIT
Un ricevitore che analizza un valore delta-seconds e lo converte in forma binaria dovrebbe (ought to) utilizzare un tipo aritmetico con un intervallo di interi non negativi di almeno 31 bit. Se una cache riceve un valore delta-seconds maggiore del più grande intero che può rappresentare, o se uno dei suoi calcoli successivi va in overflow, la cache DEVE (MUST) considerare il valore sia come 2147483648 (2^31), sia come il più grande intero positivo che può comodamente rappresentare.
Nota: Il valore 2147483648 esiste per ragioni storiche e rappresenta l'infinito (oltre 68 anni), anziché essere memorizzato in forma binaria; le implementazioni possono generarlo come stringa fissa quando si verifica un overflow, anche se il tipo aritmetico utilizzato per i calcoli non può rappresentare direttamente tale numero. Ciò che è importante qui è che l'overflow sia stato rilevato e non venga successivamente trattato come un valore negativo.