httpstatuses/contents/codes/206.md

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