El servidor está cumpliendo con éxito una solicitud de rango para el recurso de destino transfiriendo una o más partes de la representación seleccionada que corresponden a los rangos satisfechos encontrados en el campo de cabecera Range de la solicitud.
Si se está transfiriendo una sola parte, el servidor que genera la respuesta 206 DEBE generar un campo de cabecera Content-Range, que describa qué rango de la representación seleccionada se incluye, y una carga útil (payload) consistente en el rango. Por ejemplo:
HTTP/1.1 206 Partial Content
Date: Wed, 16 Apr 2014 05:21:19 GMT
Last-Modified: Wed, 16 Apr 2014 03:54:03 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif
... 26012 bytes de datos parciales de una imagen ...Si se transfieren varias partes, el servidor que genera la respuesta 206 DEBE generar una carga útil «multipart/byteranges » y un campo de cabecera Content-Type que contenga el tipo de multipart/byteranges media y su parámetro boundary (límite) requerido. Para evitar confusiones con las respuestas de una sola parte, el servidor NO DEBE generar un campo de cabecera Content-Range en la sección de cabecera HTTP de una respuesta de varias partes (este campo se enviará en cada una de las partes en su lugar).
Dentro del área de cabecera de cada parte del cuerpo en la carga útil multiparte, el servidor DEBE generar un campo de cabecera Content-Range correspondiente al rango que se incluye en esa parte del cuerpo. Si la representación seleccionada hubiera tenido un campo de cabecera Content-Type en una respuesta 200 OK, el servidor DEBERIA generar ese mismo campo Content-Type en el área de cabecera de cada parte del cuerpo. Por ejemplo:
HTTP/1.1 206 Partial Content
Date: Wed, 16 Apr 2014 05:21:19 GMT
Last-Modified: Wed, 16 Apr 2014 03:54:03 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=ESTE_STRING_SEPARA
--ESTE_STRING_SEPARA
Content-Type: application/pdf
Content-Range: bytes 500-999/8000
...el primer rango...
--ESTE_STRING_SEPARA
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000
...el segundo rango
--ESTE_STRING_SEPARA--Cuando se solicitan varios rangos, el servidor PUEDE unir cualquiera de los rangos que se superpongan o que estén separados por un espacio menor que la sobrecarga de enviar varias partes, independientemente del orden en que aparezca la correspondiente especificación de rango de bytes en el campo de cabecera Range recibido. Dado que la sobrecarga típica entre las partes de una carga útil multipart/byteranges es de unos 80 bytes, dependiendo del tipo de medio de la representación seleccionada y de la longitud del parámetro boundary elegido, puede ser menos eficiente transferir muchas partes pequeñas separadas que transferir la representación seleccionada completa.
El servidor NO DEBE generar una respuesta multiparte a una solicitud de un solo rango, ya que el cliente que no solicite múltiples partes podría no soportar respuestas multiparte. Sin embargo, el servidor PUEDE generar una carga útil multipart/byteranges con una sola parte del cuerpo si se solicitaron varios rangos y sólo uno de ellos resultó ser satisfactorio o sólo quedó un rango después de la unión. El cliente que no pueda procesar una respuesta multipart/byteranges NO DEBE generar una solicitud que pida varios rangos.
Cuando se genera una carga útil de respuesta multiparte, el servidor DEBERÍA enviar las partes en el mismo orden en que apareció la correspondiente especificación de rango de bytes en el campo de cabecera Range recibido, excluyendo aquellos rangos que se consideraron insatisfactibles o que se unieron en otros rangos. El cliente que recibe una respuesta multiparte DEBE inspeccionar el campo de cabecera Content-Range presente en cada parte del cuerpo para determinar qué rango contiene esa parte del cuerpo; el 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 cabecera, además de los requeridos anteriormente, si el campo se hubiera 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 cabecera If-Range, el remitente NO DEBERÍA generar otros campos de cabecera de representación más allá de los requeridos anteriormente, porque se entiende que el cliente ya tiene una respuesta anterior que contiene esos campos de cabecera. En caso contrario, el remitente DEBE generar todos los campos de cabecera de representación que se habrían enviado en una respuesta HTTP 200 OK a la misma solicitud.
Una respuesta 206 es almacenable en caché por defecto; es decir, a menos que se indique lo contrario mediante controles explícitos de caché.
Referencias de programación del Código HTTP 206
- Symfony HTTP Status Constant
Response::HTTP_PARTIAL_CONTENT - Python2 HTTP Status Constant
httplib.PARTIAL_CONTENT - Python3+ HTTP Status Constant
http.client.PARTIAL_CONTENT - Python3.5+ HTTP Status Constant
http.HTTPStatus.PARTIAL_CONTENT - Go HTTP Status Constant
http.StatusPartialContent - Rails HTTP Status Symbol
:partial_content - .NET HTTP Status Constant
System.Net.HttpStatusCode.PartialContent - C# HTTP Status Enum
HttpStatusCode.PartialContent - Rust HTTP Status Constant
http::StatusCode::PARTIAL_CONTENT
