--- set: 2 code: 206 title: Partial Content references: "Rails HTTP Status Symbol": ":partial_content" "Go HTTP Status Constant": "http.StatusPartialContent" "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" --- 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[1](#ref-1). 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[2](#ref-2), 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[3](#ref-3). --- * 1 Range [RFC7233 Section 3.1][2] * 2 Internet Media Type multipart/byteranges [RFC7233 Appendix A][3] * 3 Calculating Heuristic Freshness [RFC7234 Section 4.2.2][4] * Source: [RFC7233 Section 4.1][1] [1]: [2]: [3]: [4]: