Spécification du code d'état HTTP 206

Si une seule partie est transférée, le serveur générant la réponse 206 Partial Content DOIT générer un champ d'en-tête Content-Range, décrivant quel intervalle de la représentation sélectionnée est inclus, et une charge utile composée de l'intervalle. Par exemple :

HTTP/1.1 206 Partial Content Contenu partiel
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 octets de données d'image partielles ...

Si plusieurs parties sont transférées, le serveur qui génère la réponse 206 Partial Content DOIT générer une charge utile "multipart/byteranges", telle que définie dans l'annexe A, et un champ d'en-tête Content-Type contenant le type de média multipart/byteranges et son paramètre de délimitation requis. Pour éviter toute confusion avec les réponses en une seule partie, un serveur NE DOIT PAS générer un champ d'en-tête Content-Range dans la section d'en-tête HTTP d'une réponse en plusieurs parties (ce champ sera envoyé dans chaque partie à la place).

Dans la zone d'en-tête de chaque partie du corps de la charge utile multipartite, le serveur DOIT générer un champ d'en-tête Content-Range correspondant à la plage incluse dans cette partie du corps. Si la représentation sélectionnée aurait eu un champ d'en-tête Content-Type dans une réponse 200 (OK), le serveur DOIT générer ce même champ Content-Type dans la zone d'en-tête de chaque partie du corps.

Par exemple :

HTTP/1.1 206 Partial Content Contenu partiel
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

...la première plage....
--THIS_STRING_SEPARATES
Content-Type : application/pdf
Content-Range : bytes 7000-7999/8000

....la deuxième plage
--THIS_STRING_SEPARATES--

Lorsque plusieurs plages sont demandées, un serveur PEUT fusionner toutes les plages qui se chevauchent ou qui sont séparées par un écart inférieur au surcoût de l'envoi de plusieurs parties, quel que soit l'ordre dans lequel les spécifications de plage d'octets correspondantes sont apparues dans le champ d'en-tête de plage reçu. Étant donné que le surdébit typique entre les parties d'une charge utile multipart/byteranges est d'environ 80 octets, en fonction du type de média de la représentation sélectionnée et de la longueur du paramètre de délimitation choisi, il peut être moins efficace de transférer de nombreuses petites parties disjointes que de transférer l'intégralité de la représentation sélectionnée.

Un serveur NE DOIT PAS générer de réponse multipartite à une demande portant sur une seule plage, car un client qui ne demande pas de parties multiples peut ne pas prendre en charge les réponses multipartites. Toutefois, un serveur PEUT générer une charge utile multipart/byteranges avec une seule partie du corps si plusieurs plages ont été demandées et qu'une seule plage s'est avérée satisfaisante ou qu'il n'en reste qu'une après la fusion. Un client qui ne peut pas traiter une réponse multipart/byteranges NE DOIT PAS générer une requête demandant plusieurs intervalles.

Lorsqu'une charge utile de réponse multipartite est générée, le serveur DEVRAIT envoyer les parties dans l'ordre dans lequel la spécification de plage d'octets correspondante est apparue dans le champ d'en-tête Range reçu, en excluant les plages qui ont été jugées insatisfaisantes ou qui ont été regroupées dans d'autres plages. Un client qui reçoit une réponse en p