What Is a 206 Status Code?

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

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², 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 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 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 response to the same request.

A 206 response is cacheable by default; i.e., unless otherwise indicated by explicit cache controls³.

• ¹ Range RFC7233 Section 3.1
• ² Internet Media Type multipart/byteranges RFC7233 Appendix A
• ³ Calculating Heuristic Freshness RFC7234 Section 4.2.2
• Source: RFC7233 Section 4.1

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

How does a server respond with a 206 status code?

When a server sends a 206 status code, the client requests only part of the resource, and the server delivers only that part. The server’s response includes the following:

• A 206 status code in the response header
• A “Content-Range” header, which specifies the range of bytes returned in the response
• The requested range of bytes in the response body

When is a 206 status code used?

A 206 status code gets used when the following are true:

• The client requests only part of the resource
• The server can provide only that part

The server may respond with a 206 status code in the following scenarios:

• When a client requests a large file and only needs a specific portion of it
• When a client requests a resource with multiple parts, such as a video or audio file, and only requests part of it
• When a client makes a request with a range header, requesting a specific portion of a resource

Common causes of a 206 status code

A 206 status code may happen for a few reasons, like:

• The client requests a specific portion of a resource using the range header, causing the server to respond with a 206 status code
• The server sends a partial response when the requested resource is too large to send at once
• The client or server experiences network latency, causing the server to send partial responses to the client

What is the difference between a 206 status code and other HTTP status codes?

A 206 status code is different from other status codes because it’s a partial content response.

It indicates that the server is delivering only part of the requested resource, and the client requested only that specific portion. Other status codes, such as 200 or 404, indicate the server is delivering either the entire resource or that the resource cannot be found.

Help! How do I troubleshoot a 206 status code error?

If a client receives a 206 status code error, try troubleshooting the issue by:

• Checking the network connection to ensure it’s stable and fast
• Ensuring the client’s range header is correct and within the acceptable range
• Contacting the server administrator to verify the server is configured correctly
• Checking the server logs for any errors or issues that may have caused the 206 status code

Additional resources

• Learn about web development
• Learn about SEO
• Web development services from WebFX
• SEO services from WebFX
• MDN Web Docs
• W3Schools

Return to List of HTTP Status Codes