What is HTTP 206 Partial Content? Understanding Partial Downloads with Range

About This Article
This article was created using an automated generation workflow utilizing generative AI. Based on the HTTP Range specification (RFC 9110), it organizes how to read and verify partial content requests.

Verification Status: 📘 Official Specification Verified, Actual Network Communication Not Performed

When you want to download a large file from a specific point onward, HTTP allows you to request not the entire file from the beginning, but ratheronly the necessary byte range. This is where Range requests and 206 Partial Content come into play. This article explains how to determine what happened from the communication headers without confusing 200, 206, and 416.

First test: Request the first 100 bytes

Select a public test file URL for which you have verified the rights and terms of use. The URL must not include an authentication token or a signed query. The following is an example for readers to execute, not a record of a successful execution at the time of writing.

1. Verify the HTTP status and Content-Length using a standard GET request with curl. Since the HEAD result is not necessarily identical to the GET result, also verify the actual GET response.

2. Request the same URL using curl with the "–range 0-99" option, and check the response headers and the number of received bytes.

3. If 206 is returned, read Content-Range and verify that the requested range matches the returned range. If 200 is returned, the server may have ignored Range and returned the entire content.

For example, if the hypothetical file for explanation is 1000 bytes, the Range header will be "Range: bytes=0-99", and the Content-Range of the 206 response will be like "bytes 0-99/1000". Because both the start and end positions are inclusive,0 to 99 is 100 bytesThis is an expected example and not an output observed on an actual site.

Conditions for returning 206 and conditions for returning 200

Range in RFC 9110 applies to GET. The server may ignore the Range header, in which case a normal 200 OK and the entire body may be returned. Therefore, "not 206" does not mean "server failure".

A 206 status is a success response, but it differs from successfully fetching the entire file. To use partial data as a file, you need to manage and merge the missing parts, as well as verify file integrity. Video players and download resume features sometimes utilize such partial retrieval.

Interpreting Content-Range

Content-Range: bytes 200-299/1000 means that 100 bytes from 200 to 299 were returned out of a total length representation of 1000 bytes. The unit bytes does not mean character count. There is a possibility that multi-byte characters such as UTF-8 Japanese text may be cut off midway, andreading the result of a partial retrieval directly as a stringis not necessarily appropriate.

When requesting multiple ranges at once, the response may be in the multipart/byteranges format. Programs that assume a simple structure of one Content-Range and one body cannot handle this. Limiting your initial experiments to a single range makes troubleshooting easier.

The presence of Accept-Ranges: bytes serves as an indicator that range requests are supported. However, the absence of this header alone does not conclusively mean range retrieval is unsupported. Determine support based on the actual GET response and Content-Range.

Change one parameter and observe the failure

For a hypothetical file with a total length of 1000 bytes, try changing the start position from 0 to 1000. Since Range: bytes=1000-1099 exceeds the end of the file, it typically results in a 416 status. If the 416 Content-Range returns bytes */1000, it provides a clue about the total length. However, actual server responses depend on the environment.

What is important here are the two rules: 0-indexed and inclusive of the end position. The last byte position of a 1000-byte file is 999. If the start position is 1000, it does not exist. Miscalculating the offset when resuming a download can cause the final byte to be duplicated or missing.

Pay attention to If-Range when resuming downloads

When resuming a partially saved file, the content on the server may have been updated. Simply combining the first half of an old file with the second half of a new file can result in a corrupted file.

If-Range is a mechanism for performing range retrieval if the ETag or date validation condition is met, and fetching the entire file otherwise. There are constraints on handling strong and weak ETags. Simply adding Range does not guarantee the identity of the file after resumption. In practice, also consider designing your workflow to verify the entire file with a reliable checksum after the download completes.

Troubleshooting when things do not work

If 206 is not returned, check URL redirects, whether the method is GET or HEAD, CDNs and proxies, the presence of compressed transfer, and both the request and response. If the transfer representation changes due to Content-Encoding, the local file position and the byte position in the server's representation may not be equivalent. Do not forcefully combine partial data.

If 416 occurs, compare the saved size with the current total length on the server. Check whether the target file has changed or if the Range start position is greater than or equal to the total length. Instead of repeating retries infinitely, review the conditions and, if necessary, fetch from the beginning.

While operational monitoring should not treat 206 as an error, verify application-level processing if an expected full retrieval finishes with a 206. Even if the HTTP request succeeds, it does not necessarily mean the application has all the data it requires.

Tracing with Diagrams: How does a GET request with Range respond?

Consider an example of retrieving only the first 100 bytes from a fictional 1,000-byte file. A 206 Partial Content is a successful response in terms of HTTP communication, but it does not mean "the entire file was successfully saved." The conditions for determining success differ between a preview function that only needs the first fragment and a process that wants to download the entirety completely.

sequenceDiagram
    participant C as クライアント
    participant S as サーバー
    C->>S: GET と Range bytes=0-99
    S-->>C: 206 と Content-Range bytes 0-99/1000
    Note over C: 先頭100バイトを取得
    C->>S: GET と Range bytes=100-199
    S-->>C: 206 と Content-Range bytes 100-199/1000
    Note over C: 必要な断片を管理してから結合

Even if the first response in the diagram is normal, 900 bytes still remain. When retrieving in multiple chunks, you must verify whether the start and end positions of the received part match the destination position. 0 to 99 equals 100 bytes because the start position is counted as 0 and the end position is inclusive. Miscalculating ranges results in overlapping or missing data by a single byte.

How to interpret curl results

When experimenting, prepare a public Range-enabled file that you manage or are authorized to investigate. The following URL is an explanatory example for replacement, and the existence or behavior of any actual file is not verified. It is also not an assertion that the execution result was successful. Ensure credentials and signed URLs are not left in logs.

# 自分で確認した公開テストファイルのURLを指定する

URL='https://example.org/replace-with-your-test-file.bin'
curl --show-error --location --range 0-99 --dump-header headers.txt --output first100.bin "$URL"
wc -c first100.bin

The order of investigation is the HTTP status of the final response, Content-Range, and the byte size of the saved file. If there are redirects, multiple HTTP responses may be recorded in the header destination. Do not judge by reading only the first status that appeared; check the conditions of the final response that actually returned the body. The mere fact that the saved file was 100 bytes is not proof that Range was processed, as the original file might happen to be 100 bytes and the server simply returned 200.

For 206, cross-check the start and end positions of Content-Range with the actual received length. If the entire file is returned with 200, it must be treated as a full response rather than appending to the end of an existing file. If 416 is returned, check whether the start position exceeds the current total length on the server. Combining the status code, the requested byte range, and the meaning of the returned data makes it easier to figure out where the communication issue lies.

flowchart TD
    A["Range付きGETの最終応答"] --> B{"ステータス"}
    B -->|"206"| C["Content-Rangeと受信長を照合"]
    B -->|"200"| D["範囲を無視した全体応答の可能性"]
    B -->|"416"| E["開始位置と現在の全長を確認"]
    B -->|"その他"| F["認証・経路・サーバーを別途調査"]
    C --> G["必要な断片がそろったか確認"]
    D --> G
    E --> H["条件を直してから再要求"]

This decision tree does not automatically determine the cause of a failure, but rather indicates the order of investigation. For example, if 416 occurs, the file content may have actually been updated, shortening the total length. If you do not know whether the saved fragment is the same version as the current file on the server, you must not force a resume.

In professional work, separate "resumption succeeded" from "correctly completed"

Suppose you download a distribution file of several gigabytes halfway and resume it after some time. If the file has been updated on the server to a newer version with the same name, inconsistencies can occur where the first half is the old version and the second half is the new version. Merely being able to receive the remainder via Range does not mean the entire file is correct. Version condition checks using If-Range or final verification with a reliable checksum from the distributor may be necessary.

Even if 206 is a success in HTTP, if the data required by the application is missing, it is incomplete from a business perspective. Conversely, for processes that only require a part of the data, such as video streaming or previews, avoiding full retrieval is the intended goal. Treating 206s in web access logs as errors uniformly may result in counting intentional partial retrievals as failures. The intended use case for Range is the premise for judgment.

Another easily overlooked aspect is Japanese text. HTTP ranges are specified in bytes, not character counts. In UTF-8, a single Japanese character can consist of multiple bytes, meaning a partially retrieved fragment might cut off in the middle of a character. Rather than decoding it as-is, you need to consider whether there are missing byte sequences and how to handle boundary positions.

Furthermore, in configurations where proxies or CDNs perform compressed transfers, you must also verify the relationship between the received data and the representation of the target file. Record Content-Encoding and Content-Range first to verify that no unintended transformations occurred. File integrity cannot be guaranteed simply by looking at network responses.

Summary

Range specifies the desired range, 206 indicates that part was returned, and Content-Range shows which part was actually returned. Understand 200 and 416 as normal normative branches, andchecking the HTTP status alongside the response headers and received byte countmakes it easier to isolate the cause.

Official Documentation

• RFC 9110 §14 Range Requests

• RFC 9110 §15.3.7 206 Partial Content

• RFC 9110 §15.5.17 416 Range Not Satisfiable

• curl manual: –range

The communication examples in this article are hypothetical examples based on the specification. Execution and display results with specific curl versions, web servers, and WordPress have not been verified.