206 Partial Content

El servidor está cumpliendo exitosamente con una solicitud de rango para el recurso objetivo transfiriendo una o más partes de la representación seleccionada que corresponden a los rangos satisfacibles encontrados en el campo de encabezado Range de la solicitud¹.

Si se está transfiriendo una sola parte, el servidor que genera la respuesta 206 DEBE generar un campo de encabezado Content-Range, describiendo qué rango de la representación seleccionada está incluido, y un contenido que consiste en el rango. Por ejemplo:

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 ...

Si se están transfiriendo múltiples partes, el servidor que genera la respuesta 206 DEBE generar un contenido “multipart/byteranges”², y un campo de encabezado Content-Type que contenga el tipo de medio multipart/byteranges y su parámetro boundary requerido. Para evitar confusión con respuestas de una sola parte, un servidor NO DEBE generar un campo de encabezado Content-Range en la sección de encabezados HTTP de una respuesta de múltiples partes (este campo será enviado en cada parte en su lugar).

Dentro del área de encabezados de cada parte del cuerpo en el contenido multipart, el servidor DEBE generar un campo de encabezado Content-Range correspondiente al rango que está siendo incluido en esa parte del cuerpo. Si la representación seleccionada hubiera tenido un campo de encabezado Content-Type en una respuesta 200 OK, el servidor DEBERÍA generar ese mismo campo Content-Type en el área de encabezados de cada parte del cuerpo. Por ejemplo:

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--

Cuando se solicitan múltiples rangos, un servidor PUEDE combinar cualquiera de los rangos que se superponen, o que están separados por un espacio que es más pequeño que la sobrecarga de enviar múltiples partes, independientemente del orden en que apareció el byte-range-spec correspondiente en el campo de encabezado Range recibido. Dado que la sobrecarga típica entre partes de un contenido multipart/byteranges es de alrededor de 80 bytes, dependiendo del tipo de medio de la representación seleccionada y la longitud del parámetro boundary elegido, puede ser menos eficiente transferir muchas partes pequeñas disjuntas que transferir toda la representación seleccionada.

Un servidor NO DEBE generar una respuesta multipart a una solicitud para un solo rango, ya que un cliente que no solicita múltiples partes podría no soportar respuestas multipart. Sin embargo, un servidor PUEDE generar un contenido multipart/byteranges con solo una parte del cuerpo si se solicitaron múltiples rangos y solo se encontró que un rango era satisfacible o solo quedó un rango después de la combinación. Un cliente que no puede procesar una respuesta multipart/byteranges NO DEBE generar una solicitud que pida múltiples rangos.

Cuando se genera un contenido de respuesta multipart, el servidor DEBERÍA enviar las partes en el mismo orden que apareció el byte-range-spec correspondiente en el campo de encabezado Range recibido, excluyendo aquellos rangos que fueron considerados insatisfacibles o que fueron combinados en otros rangos. Un cliente que recibe una respuesta multipart DEBE inspeccionar el campo de encabezado Content-Range presente en cada parte del cuerpo para determinar qué rango está contenido en esa parte del cuerpo; un cliente no puede confiar en recibir los mismos rangos que solicitó, ni el mismo orden que solicitó.

Cuando se genera una respuesta 206, el servidor DEBE generar los siguientes campos de encabezado, además de los requeridos arriba, si el campo hubiera sido enviado en una respuesta 200 OK a la misma solicitud: Date, Cache-Control, ETag, Expires, Content-Location, y Vary.

Si se genera un 206 en respuesta a una solicitud con un campo de encabezado If-Range, el remitente NO DEBERÍA generar otros campos de encabezado de representación más allá de los requeridos arriba, porque se entiende que el cliente ya tiene una respuesta previa que contiene esos campos de encabezado. De lo contrario, el remitente DEBE generar todos los campos de encabezado de representación que hubieran sido enviados en una respuesta 200 OK a la misma solicitud.

Una respuesta 206 es cacheable por defecto; es decir, a menos que se indique lo contrario por controles de caché explícitos³.

• ¹ Range RFC7233 Section 3.1
• ² Internet Media Type multipart/byteranges RFC7233 Appendix A
• ³ Calculating Heuristic Freshness RFC7234 Section 4.2.2
• Source: RFC7233 Section 4.1