3. Richieste di intervallo
3.1 Range
Il campo di intestazione "Range" in una richiesta GET modifica la semantica del metodo, in modo da richiedere il trasferimento di uno o più sottointervalli dei dati della rappresentazione selezionata anziché di tutti i dati della rappresentazione selezionata.
Range = byte-ranges-specifier / other-ranges-specifier
other-ranges-specifier = other-range-unit "=" other-range-set
other-range-set = 1*VCHAR
Un server può ignorare il campo di intestazione Range (MAY). Tuttavia, i server di origine e le cache intermedie dovrebbero supportare gli intervalli di byte quando possibile, poiché Range consente un recupero efficiente da trasferimenti parzialmente falliti e l'acquisizione parziale di rappresentazioni di grandi dimensioni. Un server deve ignorare un campo di intestazione Range ricevuto con un metodo di richiesta diverso da GET (MUST).
Un server di origine deve ignorare un campo di intestazione Range che contiene un'unità di intervallo che non comprende (MUST). Un proxy può scartare un campo di intestazione Range che contiene un'unità di intervallo che non comprende (MAY).
Un server che supporta le richieste di intervallo può ignorare o rifiutare un campo di intestazione Range costituito da più di due intervalli sovrapposti, oppure da un insieme di molti piccoli intervalli non elencati in ordine crescente, poiché entrambi i casi indicano un client difettoso o un attacco denial-of-service deliberato (Sezione 6.1) (MAY). Un client dovrebbe evitare di richiedere più intervalli il cui trattamento e trasferimento siano intrinsecamente meno efficienti di un unico intervallo che comprenda gli stessi dati (SHOULD NOT).
Un client che richiede più intervalli dovrebbe elencarli in ordine crescente (l'ordine in cui sarebbero normalmente ricevuti in una rappresentazione completa), a meno che non abbia un'esigenza specifica di ottenere prima una parte successiva (SHOULD). Per esempio, un user agent che elabora una rappresentazione di grandi dimensioni con un catalogo interno di parti potrebbe dover richiedere prima le parti successive, in particolare se la rappresentazione è costituita da pagine memorizzate in ordine inverso e l'user agent desidera trasferire una pagina alla volta.
Il campo di intestazione Range è valutato dopo i campi di intestazione di precondizione definiti in [RFC7232], e soltanto se il risultato in assenza del campo di intestazione Range sarebbe una risposta 200 (OK). In altre parole, Range viene ignorato quando un GET condizionale produrrebbe una risposta 304 (Not Modified).
Il campo di intestazione If-Range (Sezione 3.2) può essere usato come precondizione per l'applicazione del campo di intestazione Range.
Se tutte le precondizioni sono vere, se il server supporta il campo di intestazione Range per la risorsa di destinazione e se gli intervalli specificati sono validi e soddisfacibili (come definito nella Sezione 2.1), il server dovrebbe inviare una risposta 206 (Partial Content) con un payload contenente una o più rappresentazioni parziali corrispondenti agli intervalli soddisfacibili richiesti, come definito nella Sezione 4 (SHOULD).
Se tutte le precondizioni sono vere, se il server supporta il campo di intestazione Range per la risorsa di destinazione e se gli intervalli specificati non sono validi o non sono soddisfacibili, il server dovrebbe inviare una risposta 416 (Range Not Satisfiable) (SHOULD).
3.2 If-Range
Se un client possiede una copia parziale di una rappresentazione e desidera ottenere una copia aggiornata della rappresentazione intera, può usare il campo di intestazione Range con un GET condizionale (usando If-Unmodified-Since, If-Match o entrambi). Tuttavia, se la precondizione fallisce perché la rappresentazione è stata modificata, il client dovrebbe poi effettuare una seconda richiesta per ottenere l'intera rappresentazione corrente.
Il campo di intestazione "If-Range" consente a un client di "cortocircuitare" la seconda richiesta. In modo informale, il suo significato è il seguente: se la rappresentazione è immutata, inviami la o le parti che sto richiedendo in Range; altrimenti, inviami la rappresentazione intera.
If-Range = entity-tag / HTTP-date
Un client non deve generare un campo di intestazione If-Range in una richiesta che non contenga un campo di intestazione Range (MUST NOT). Un server deve ignorare un campo di intestazione If-Range ricevuto in una richiesta che non contiene un campo di intestazione Range (MUST). Un server di origine deve ignorare un campo di intestazione If-Range ricevuto in una richiesta per una risorsa di destinazione che non supporta le richieste di intervallo (MUST).
Un client non deve generare un campo di intestazione If-Range contenente un entity-tag contrassegnato come debole (MUST NOT). Un client non deve generare un campo di intestazione If-Range contenente una HTTP-date, a meno che il client non disponga di alcun entity-tag per la rappresentazione corrispondente e che la data sia un validatore forte nel senso definito nella Sezione 2.2.2 di [RFC7232] (MUST NOT).
Un server che valuta una precondizione If-Range deve usare la funzione di confronto forte per confrontare gli entity-tag (Sezione 2.3.2 di [RFC7232]) (MUST) e deve valutare la condizione come falsa se viene fornita una HTTP-date che non è un validatore forte nel senso definito nella Sezione 2.2.2 di [RFC7232] (MUST). Un entity-tag valido può essere distinto da una HTTP-date valida esaminando se i primi due caratteri sono un DQUOTE.
Se il validatore fornito nel campo di intestazione If-Range corrisponde al validatore corrente per la rappresentazione selezionata della risorsa di destinazione, il server dovrebbe elaborare il campo di intestazione Range come richiesto (SHOULD). Se il validatore non corrisponde, il server deve ignorare il campo di intestazione Range (MUST). Si noti che questo confronto per corrispondenza esatta, anche quando il validatore è una HTTP-date, differisce dal confronto "precedente o uguale" usato per valutare una condizione If-Unmodified-Since.