Specifying HTTP Range with curl – Understanding 206 Partial Content and Content-Range

About this article
This article was created using an automated generation workflow powered by generative AI. It reviews the Range specification in RFC 9110 and clarifies how 206, Content-Range, and 416 interact when using curl to request a specific byte range rather than an entire file.

Verification Status: 📘 RFC and curl specifications verified; external server live communication unverified
Information Verification Reference Date: October 5, 2026

In scenarios where you want to check only the first 100 bytes of a large file or resume a download from a specific point, HTTPRange requestsare used.

With curl, you can specify this using--range.

Requesting the first 100 bytes

Send the following request to a Range-supported test URL:

curl --range 0-99   --dump-header -   --output /dev/null   https://example.com/large-file.bin

0-99is from byte position 0 to 99, which equals 100 bytes.

When the server fulfills the request, you typically verify the following information.

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-99/12345

In RFC 9110,Content-Rangeis used in a 206 response to indicate the returned range and the length of the complete representation.

200 and 206 have different meanings

If the entire content is returned via a normal GET, 200 OKis standard.

On the other hand, when returning a partial response to a Range request, it is 206 Partial Content .

flowchart LR
    A["GET 全体"] --> B["200 OK"]
    C["GET + Range: bytes=0-99"] --> D{"Rangeを満たせる?"}
    D -- Yes --> E["206 Partial Content"]
    D -- No/条件不一致 --> F["200や416など"]

Sending a Range header does not guarantee a 206 status code; the server may ignore the Range header and return the entire content.

Reading Content-Range

For example, for

Content-Range: bytes 0-99/12345

, it means

• bytes: unit

• 0-99: the range returned in this response

• 12345: the total length of the complete representation

.

This tells you not just that 100 bytes were received, but also where those bytes are located within the original dataset.

What to look for in Accept-Ranges?

When checking with a HEAD request,

Accept-Ranges: bytes

may be returned.

curl -I https://example.com/large-file.bin

This serves as an indicator that byte ranges are accepted.

However, as noted in RFC 9110, range support status can vary based on conditions and intermediaries. Ultimately, you should send an actual Range request and check the response code and Content-Range .

The last 100 bytes can also be specified

curl --range -100 https://example.com/large-file.bin

There is also a way to specify the tail end, such as

On the other hand,

curl --range 1000-1999 https://example.com/large-file.bin

Then, request a specific intermediate range.

If it is out of range, a 416 status code may be returned.

If you request a non-existent range,416 Range Not Satisfiablemay be returned.

In RFC 9110, a 416 response

Content-Range: bytes */12345

may indicate the complete length as shown in.

flowchart TD
    A["Range要求"] --> B{"指定範囲は妥当?"}
    B -- Yes --> C["206 + Content-Range"]
    B -- No --> D["416 Range Not Satisfiable"]
    D --> E["Content-Range: bytes */全体長"]

Related to resumable downloads

Range also serves as the basis for the mechanism to resume large downloads from where they left off.

However, if the target file itself has been updated in the meantime, there is a risk of concatenating an old first half with a new second half.

Therefore, in practical resumption handling, verifying identity using ETag or Last-Modified, in addition to Range, is important. To avoid mixing search intents, detailed explanations of ETag and 304 are left for another topic, and here we focus onbyte range requests and responses.

Change only one location

Change the first

--range 0-99

to

--range 100-199

.

Verify whether the responseContent-Rangealso changes accordingly.

Furthermore,

--range 999999999-

you can also observe the behavior of 416 by specifying a range that exceeds the target size, such as in a safe verification URL.

Separating curl output into body and headers

If you want to observe only the headers without saving the body,

curl --range 0-99   --dump-header -   --output /dev/null   https://example.com/large-file.bin

use this command.

This prevents saving large files just to verify the response.

Recommended inspection order in practice

For Range-related issues, following this order makes troubleshooting easier.

1. Check Accept-Ranges using HEAD

2. Request a small range explicitly

3. Verify the HTTP status

4. Content-RangeCheck

5. Verify if the byte count matches expectations

6. Check for routing differences when passing through a proxy or CDN

It is important not to jump to conclusions such as "no Accept-Ranges means absolutely unsupported" or "adding Range guarantees a partial response."

Daily-Code-Samples

A script is provided that takes a URL and byte range as arguments to inspect HEAD and Range response headers.

• Daily-Code-Samples — network/http-range-curl

Official Documentation

• RFC 9110 — HTTP Semantics

• curl documentation — Range