mirror of
https://github.com/rmaake1/httpstatuses.git
synced 2024-11-02 00:32:36 +01:00
118 lines
5.1 KiB
Markdown
118 lines
5.1 KiB
Markdown
---
|
|
set: 2
|
|
code: 206
|
|
title: Partial Content
|
|
references:
|
|
"Rails HTTP Status Symbol": ":partial_content"
|
|
---
|
|
|
|
The server is successfully fulfilling a range request for the target resource by
|
|
transferring one or more parts of the selected representation that correspond to
|
|
the satisfiable ranges found in the request's Range header
|
|
field<sup>[1](#ref-1)</sup>.
|
|
|
|
If a single part is being transferred, the server generating the 206 response
|
|
MUST generate a Content-Range header field, describing what range of the
|
|
selected representation is enclosed, and a payload consisting of the range. For
|
|
example:
|
|
|
|
```
|
|
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 ...
|
|
```
|
|
|
|
If multiple parts are being transferred, the server generating the 206 response
|
|
MUST generate a "multipart/byteranges" payload<sup>[2](#ref-2)</sup>, and a
|
|
Content-Type header field containing the multipart/byteranges media type and its
|
|
required boundary parameter. To avoid confusion with single-part responses, a
|
|
server MUST NOT generate a Content-Range header field in the HTTP header section
|
|
of a multiple part response (this field will be sent in each part instead).
|
|
|
|
Within the header area of each body part in the multipart payload, the server
|
|
MUST generate a Content-Range header field corresponding to the range being
|
|
enclosed in that body part. If the selected representation would have had a
|
|
Content-Type header field in a [200 OK](/200) response, the server SHOULD
|
|
generate that same Content-Type field in the header area of each body part.
|
|
For example:
|
|
|
|
```
|
|
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--
|
|
```
|
|
|
|
When multiple ranges are requested, a server MAY coalesce any of the ranges that
|
|
overlap, or that are separated by a gap that is smaller than the overhead of
|
|
sending multiple parts, regardless of the order in which the corresponding
|
|
byte-range-spec appeared in the received Range header field. Since the typical
|
|
overhead between parts of a multipart/byteranges payload is around 80 bytes,
|
|
depending on the selected representation's media type and the chosen boundary
|
|
parameter length, it can be less efficient to transfer many small disjoint parts
|
|
than it is to transfer the entire selected representation.
|
|
|
|
A server MUST NOT generate a multipart response to a request for a single range,
|
|
since a client that does not request multiple parts might not support multipart
|
|
responses. However, a server MAY generate a multipart/byteranges payload with
|
|
only a single body part if multiple ranges were requested and only one range was
|
|
found to be satisfiable or only one range remained after coalescing. A client
|
|
that cannot process a multipart/byteranges response MUST NOT generate a request
|
|
that asks for multiple ranges.
|
|
|
|
When a multipart response payload is generated, the server SHOULD send the parts
|
|
in the same order that the corresponding byte-range-spec appeared in the
|
|
received Range header field, excluding those ranges that were deemed
|
|
unsatisfiable or that were coalesced into other ranges. A client that receives a
|
|
multipart response MUST inspect the Content-Range header field present in each
|
|
body part in order to determine which range is contained in that body part; a
|
|
client cannot rely on receiving the same ranges that it requested, nor the same
|
|
order that it requested.
|
|
|
|
When a 206 response is generated, the server MUST generate the following header
|
|
fields, in addition to those required above, if the field would have been sent
|
|
in a [200 OK](/200) response to the same request: Date, Cache-Control, ETag,
|
|
Expires, Content-Location, and Vary.
|
|
|
|
If a 206 is generated in response to a request with an If-Range header field,
|
|
the sender SHOULD NOT generate other representation header fields beyond those
|
|
required above, because the client is understood to already have a prior
|
|
response containing those header fields. Otherwise, the sender MUST generate all
|
|
of the representation header fields that would have been sent in a
|
|
[200 OK](/200) response to the same request.
|
|
|
|
A 206 response is cacheable by default; i.e., unless otherwise indicated by
|
|
explicit cache controls<sup>[3](#ref-3)</sup>.
|
|
|
|
---
|
|
|
|
* <span id="ref-1"><sup>1</sup> Range [RFC7233 Section 3.1][2]</span>
|
|
* <span id="ref-2"><sup>2</sup> Internet Media Type multipart/byteranges
|
|
[RFC7233 Appendix A][3]</span>
|
|
* <span id="ref-3"><sup>3</sup> Calculating Heuristic Freshness
|
|
[Section 4.2.2 of RFC7234][4]</span>
|
|
* Source: [RFC7233 Section 4.1][1]
|
|
|
|
[1]: <http://tools.ietf.org/html/rfc7233#section-4.1>
|
|
[2]: <http://tools.ietf.org/html/rfc7233#section-3.1>
|
|
[3]: <http://tools.ietf.org/html/rfc7233#appendix-A>
|
|
[4]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
|