mirror of
https://github.com/rmaake1/httpstatuses.git
synced 2024-11-07 11:12:30 +01:00
110 lines
4.8 KiB
Markdown
110 lines
4.8 KiB
Markdown
---
|
|
set: 2
|
|
code: 206
|
|
title: Partial Content
|
|
---
|
|
|
|
The 206 Partial Content status code indicates that 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 (see [RFC7233 Section 3.1][2]).
|
|
|
|
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, as defined in
|
|
[RFC7233 Appendix A][3], 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 (see [Section 4.2.2 of RFC7234][4]).
|
|
|
|
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>
|