Passa al contenuto principale

4. Risposte a una richiesta di intervallo

4.1 206 Partial Content​

Il codice di stato 206 (Partial Content) indica che il server sta soddisfacendo con successo una richiesta di intervallo per la risorsa di destinazione, trasferendo una o più parti della rappresentazione selezionata che corrispondono agli intervalli soddisfacibili trovati nel campo di intestazione Range della richiesta (Sezione 3.1).

Se viene trasferita una sola parte, il server che genera la risposta 206 deve generare un campo di intestazione Content-Range, che descrive quale intervallo della rappresentazione selezionata è incluso, e un payload costituito da tale intervallo (MUST). Per esempio:

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

... 26012 bytes of partial image data ...

Se vengono trasferite più parti, il server che genera la risposta 206 deve generare un payload "multipart/byteranges", come definito nell'Appendice A, e un campo di intestazione Content-Type contenente il tipo di media multipart/byteranges e il suo parametro boundary obbligatorio (MUST). Per evitare confusione con le risposte a parte singola, un server non deve generare un campo di intestazione Content-Range nella sezione di intestazione HTTP di una risposta a più parti (tale campo viene invece inviato in ciascuna parte) (MUST NOT).

All'interno dell'area di intestazione di ciascuna parte di corpo del payload multipart, il server deve generare un campo di intestazione Content-Range corrispondente all'intervallo incluso in quella parte di corpo (MUST). Se la rappresentazione selezionata avrebbe avuto un campo di intestazione Content-Type in una risposta 200 (OK), il server dovrebbe generare lo stesso campo Content-Type nell'area di intestazione di ciascuna parte di corpo (SHOULD). Per esempio:

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 500-999/8000

...the first range...
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000

...the second range
--THIS_STRING_SEPARATES--

Quando vengono richiesti più intervalli, un server può unire quelli che si sovrappongono, o che sono separati da uno spazio minore del sovraccarico dell'invio di più parti, indipendentemente dall'ordine in cui le corrispondenti byte-range-spec comparivano nel campo di intestazione Range ricevuto (MAY). Poiché il sovraccarico tipico tra le parti di un payload multipart/byteranges è di circa 80 byte, a seconda del tipo di media della rappresentazione selezionata e della lunghezza scelta per il parametro boundary, può essere meno efficiente trasferire molte piccole parti disgiunte di quanto lo sia trasferire l'intera rappresentazione selezionata.

Un server non deve generare una risposta multipart in risposta a una richiesta di un solo intervallo, poiché un client che non richiede più parti potrebbe non supportare le risposte multipart (MUST NOT). Tuttavia, un server può generare un payload multipart/byteranges con una sola parte di corpo se sono stati richiesti più intervalli e ne è risultato soddisfacibile uno solo, oppure se dopo l'unione è rimasto un solo intervallo (MAY). Un client che non è in grado di elaborare una risposta multipart/byteranges non deve generare una richiesta che chieda più intervalli (MUST NOT).

Quando viene generato un payload di risposta multipart, il server dovrebbe inviare le parti nello stesso ordine in cui le corrispondenti byte-range-spec comparivano nel campo di intestazione Range ricevuto, escludendo gli intervalli giudicati non soddisfacibili e quelli che sono stati uniti ad altri intervalli (SHOULD). Un client che riceve una risposta multipart deve esaminare il campo di intestazione Content-Range presente in ciascuna parte di corpo per determinare quale intervallo è contenuto in quella parte; un client non può contare né di ricevere gli stessi intervalli che ha richiesto, né di riceverli nello stesso ordine in cui li ha richiesti (MUST).

Quando viene generata una risposta 206, il server deve generare i seguenti campi di intestazione, in aggiunta a quelli richiesti in precedenza, se il campo sarebbe stato inviato in una risposta 200 (OK) alla stessa richiesta: Date, Cache-Control, ETag, Expires, Content-Location e Vary (MUST).

Se viene generata una 206 in risposta a una richiesta con un campo di intestazione If-Range, il mittente dovrebbe evitare di generare altri campi di intestazione di rappresentazione oltre a quelli richiesti in precedenza, poiché si presume che il client possieda già una risposta precedente contenente tali campi di intestazione (SHOULD NOT). In caso contrario, il mittente deve generare tutti i campi di intestazione di rappresentazione che sarebbero stati inviati in una risposta 200 (OK) alla stessa richiesta (MUST).

Una risposta 206 è memorizzabile in cache per impostazione predefinita, cioè salvo diversa indicazione da parte di controlli di cache espliciti (vedere la Sezione 4.2.2 di [RFC7234]).

4.2 Content-Range​

Il campo di intestazione "Content-Range" viene inviato in una risposta 206 (Partial Content) a parte singola per indicare l'intervallo parziale della rappresentazione selezionata incluso come payload del messaggio, in ciascuna parte di una risposta 206 multipart per indicare l'intervallo incluso in ciascuna parte di corpo, e nelle risposte 416 (Range Not Satisfiable) per fornire informazioni sulla rappresentazione selezionata.

Content-Range = byte-content-range / other-content-range

byte-content-range = bytes-unit SP
                     ( byte-range-resp / unsatisfied-range )

byte-range-resp = byte-range "/" ( complete-length / "*" )
byte-range = first-byte-pos "-" last-byte-pos
unsatisfied-range = "*/" complete-length

complete-length = 1*DIGIT

other-content-range = other-range-unit SP other-range-resp
other-range-resp = *CHAR

Se una risposta 206 (Partial Content) contiene un campo di intestazione Content-Range con un'unità di intervallo (Sezione 2) che il destinatario non comprende, il destinatario non deve tentare di ricombinarla con una rappresentazione memorizzata (MUST NOT). Un proxy che riceve tale messaggio dovrebbe inoltrarlo verso valle (SHOULD).

Per gli intervalli di byte, un mittente dovrebbe indicare la lunghezza completa della rappresentazione da cui l'intervallo è stato estratto, a meno che la lunghezza completa non sia nota o sia difficile da determinare (SHOULD). Un asterisco ("*") al posto della complete-length indica che la lunghezza della rappresentazione era sconosciuta quando il campo di intestazione è stato generato.

L'esempio seguente illustra il caso in cui il mittente sa che la lunghezza completa della rappresentazione selezionata è di 1234 byte:

Content-Range: bytes 42-1233/1234

e questo secondo esempio illustra il caso in cui la lunghezza completa è sconosciuta:

Content-Range: bytes 42-1233/*

Un valore del campo Content-Range non è valido se contiene una byte-range-resp con un valore last-byte-pos minore del suo valore first-byte-pos, oppure un valore complete-length minore o uguale al suo valore last-byte-pos. Il destinatario di un Content-Range non valido non deve tentare di ricombinare il contenuto ricevuto con una rappresentazione memorizzata (MUST NOT).

Un server che genera una risposta 416 (Range Not Satisfiable) a una richiesta di intervallo di byte dovrebbe inviare un campo di intestazione Content-Range con un valore unsatisfied-range, come nell'esempio seguente (SHOULD):

Content-Range: bytes */1234

La complete-length in una risposta 416 indica la lunghezza corrente della rappresentazione selezionata.

Il campo di intestazione Content-Range non ha significato per i codici di stato che non ne descrivono esplicitamente la semantica. Per la presente specifica, soltanto i codici di stato 206 (Partial Content) e 416 (Range Not Satisfiable) descrivono un significato per Content-Range.

I seguenti sono esempi di valori di Content-Range in cui la rappresentazione selezionata contiene un totale di 1234 byte:

  • I primi 500 byte: Content-Range: bytes 0-499/1234

  • I secondi 500 byte: Content-Range: bytes 500-999/1234

  • Tutti tranne i primi 500 byte: Content-Range: bytes 500-1233/1234

  • Gli ultimi 500 byte: Content-Range: bytes 734-1233/1234

4.3 Combinazione degli intervalli​

Una risposta può trasferire soltanto un sottointervallo di una rappresentazione se la connessione si è chiusa prematuramente o se la richiesta ha usato una o più specifiche Range. Dopo diversi trasferimenti di questo tipo, un client può aver ricevuto diversi intervalli della stessa rappresentazione. Questi intervalli possono essere combinati in sicurezza soltanto se hanno tutti in comune lo stesso validatore forte (Sezione 2.1 di [RFC7232]).

Un client che ha ricevuto più risposte parziali a richieste GET su una risorsa di destinazione può combinare tali risposte in un intervallo continuo più grande se condividono lo stesso validatore forte (MAY).

Se la risposta più recente è una risposta 200 (OK) incompleta, i campi di intestazione di tale risposta vengono usati per qualsiasi risposta combinata e sostituiscono quelli delle risposte memorizzate corrispondenti.

Se la risposta più recente è una risposta 206 (Partial Content) e almeno una delle risposte memorizzate corrispondenti è una 200 (OK), i campi di intestazione della risposta combinata sono quelli della risposta 200 più recente. Se tutte le risposte memorizzate corrispondenti sono risposte 206, la risposta memorizzata con i campi di intestazione più recenti viene usata come origine dei campi di intestazione per la risposta combinata, salvo che il client deve usare gli altri campi di intestazione forniti nella nuova risposta, a eccezione di Content-Range, per sostituire tutte le istanze dei campi di intestazione corrispondenti nella risposta memorizzata (MUST).

Il corpo del messaggio di risposta combinata è costituito dall'unione degli intervalli di contenuto parziale della nuova risposta e di ciascuna delle risposte selezionate. Se tale unione copre l'intera estensione della rappresentazione, il client deve elaborare la risposta combinata come se fosse una risposta 200 (OK) completa, incluso un campo di intestazione Content-Length che riflette la lunghezza completa (MUST). In caso contrario, il client deve elaborare l'insieme degli intervalli continui come uno dei seguenti: una risposta 200 (OK) incompleta se la risposta combinata è un prefisso della rappresentazione, una singola risposta 206 (Partial Content) contenente un corpo multipart/byteranges, oppure più risposte 206 (Partial Content), ciascuna con un intervallo continuo indicato da un campo di intestazione Content-Range (MUST).

4.4 416 Range Not Satisfiable​

Il codice di stato 416 (Range Not Satisfiable) indica che nessuno degli intervalli nel campo di intestazione Range della richiesta (Sezione 3.1) si sovrappone all'estensione corrente della risorsa selezionata, oppure che l'insieme di intervalli richiesto è stato rifiutato a causa di intervalli non validi o di una richiesta eccessiva di intervalli piccoli o sovrapposti.

Per gli intervalli di byte, il mancato superamento dell'estensione corrente significa che i first-byte-pos di tutti i valori byte-range-spec erano maggiori della lunghezza corrente della rappresentazione selezionata. Quando questo codice di stato viene generato in risposta a una richiesta di intervallo di byte, il mittente dovrebbe generare un campo di intestazione Content-Range che specifichi la lunghezza corrente della rappresentazione selezionata (Sezione 4.2) (SHOULD).

Per esempio:

HTTP/1.1 416 Range Not Satisfiable
Date: Fri, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022

Nota: poiché i server sono liberi di ignorare Range, molte implementazioni risponderanno semplicemente con l'intera rappresentazione selezionata in una risposta 200 (OK). Ciò è in parte dovuto al fatto che la maggior parte dei client è preparata a ricevere una 200 (OK) per portare a termine il compito (sia pure in modo meno efficiente) e in parte al fatto che i client potrebbero non smettere di effettuare una richiesta parziale non valida prima di aver ricevuto una rappresentazione completa. Pertanto i client non possono contare di ricevere una risposta 416 (Range Not Satisfiable), neppure quando sarebbe la più appropriata.