1. Introduction (Introduzione)

L'Hypertext Transfer Protocol (HTTP) è un protocollo di richiesta/risposta senza stato a livello applicativo che utilizza semantica estensibile e messaggi auto-descrittivi per un'interazione flessibile con sistemi di informazione ipertestuale basati su rete. HTTP è comunemente utilizzato in sistemi di informazione distribuiti dove l'uso di cache di risposta (Response Caches) può migliorare le prestazioni. Questo documento definisce gli aspetti di HTTP relativi alla memorizzazione nella cache e al riutilizzo dei messaggi di risposta.

Una "cache (Cache)" HTTP è un archivio locale di messaggi di risposta e il sottosistema che controlla la memorizzazione, il recupero e l'eliminazione dei messaggi al suo interno. Una cache memorizza risposte memorizzabili nella cache per ridurre il tempo di risposta e il consumo di larghezza di banda di rete per future richieste equivalenti. Qualsiasi client o server può (MAY) utilizzare una cache, tranne quando agisce come tunnel (Tunnel) (vedere la sezione 3.7 di [HTTP]).

Una "cache condivisa (Shared Cache)" è una cache che memorizza risposte per il riutilizzo da parte di più utenti; le cache condivise sono tipicamente (ma non sempre) implementate come parte di un intermediario (Intermediary). Al contrario, una "cache privata (Private Cache)" è dedicata a un singolo utente; tipicamente, sono implementate come componenti di un user agent (User Agent).

L'obiettivo della memorizzazione nella cache HTTP è migliorare significativamente le prestazioni riutilizzando messaggi di risposta precedenti per soddisfare le richieste correnti. Come definito nella sezione 4.2, una cache considera una risposta memorizzata come "fresca (Fresh)" se può riutilizzare la risposta memorizzata senza "validazione (Validation)" (cioè senza verificare con il server di origine se la risposta memorizzata nella cache è ancora valida per questa richiesta). Quindi, ogni volta che una cache riutilizza una risposta fresca, la latenza e il sovraccarico di rete possono essere ridotti. Quando una risposta memorizzata nella cache non è fresca, può comunque essere riutilizzabile se la validazione può aggiornarla (sezione 4.3) o se il server di origine non è disponibile (sezione 4.2.4).

Questo documento rende obsoleto il RFC 7234, con un riepilogo delle modifiche nell'appendice B.

1.1 Requirements Notation (Notazione dei requisiti)

Le parole chiave "deve (MUST)", "non deve (MUST NOT)", "richiesto (REQUIRED)", "deve (SHALL)", "non deve (SHALL NOT)", "dovrebbe (SHOULD)", "non dovrebbe (SHOULD NOT)", "raccomandato (RECOMMENDED)", "non raccomandato (NOT RECOMMENDED)", "può (MAY)" e "opzionale (OPTIONAL)" in questo documento devono essere interpretate come descritto nel BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in maiuscolo, come mostrato qui.

La sezione 2 di [HTTP] definisce i criteri di conformità e contiene considerazioni sulla gestione degli errori.

1.2 Syntax Notation (Notazione sintattica)

Questa specifica utilizza la notazione Augmented Backus-Naur Form (ABNF) di [RFC5234], estesa con la notazione di stringa sensibile alle maiuscole/minuscole definita in [RFC7405].

Utilizza anche l'estensione di lista definita nella sezione 5.6.1 di [HTTP], che consente la definizione compatta di liste separate da virgole utilizzando l'operatore "#" (simile a come l'operatore "*" indica la ripetizione). L'appendice A mostra la grammatica raccolta con tutti gli operatori di lista espansi in notazione ABNF standard.

1.2.1 Imported Rules (Regole importate)

Le seguenti regole fondamentali sono incluse per riferimento come definito nell'appendice B.1 di [RFC5234]: DIGIT (decimale 0-9).

[HTTP] definisce le seguenti regole:

HTTP-date     = <HTTP-date, see [HTTP], Section 5.6.7>
OWS           = <OWS, see [HTTP], Section 5.6.3>
field-name    = <field-name, see [HTTP], Section 5.1>
quoted-string = <quoted-string, see [HTTP], Section 5.6.4>
token         = <token, see [HTTP], Section 5.6.2>

1.2.2 Delta Seconds (Secondi delta)

La regola delta-seconds specifica un intero non negativo che rappresenta il tempo in secondi.

delta-seconds  = 1*DIGIT

Un destinatario che analizza un valore delta-seconds e lo converte in forma binaria dovrebbe (ought to) utilizzare un tipo aritmetico di almeno 31 bit di intervallo di interi non negativi. Se una cache riceve un valore delta-seconds maggiore del massimo intero che può rappresentare, o se uno dei suoi calcoli successivi va in overflow, la cache deve (MUST) trattare quel valore come 2147483648 (2^31) o il massimo intero positivo che può comodamente rappresentare.

Nota: Il valore 2147483648 esiste per ragioni storiche, rappresentando l'infinito (oltre 68 anni), e non ha bisogno di essere memorizzato in forma binaria; le implementazioni possono generarlo come stringa anche se il calcolo utilizza un tipo aritmetico che non può rappresentare direttamente quel numero. Ciò che conta qui è che l'overflow venga rilevato piuttosto che trattato come valore negativo nei calcoli successivi.