この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。RFC 9110のRange仕様を確認し、curlでファイル全体ではなく指定したbyte範囲だけを要求したとき、206・Content-Range・416がどう関係するかを整理します。検証ステータス：📘 RFC・curl仕様確認済み、外部サーバー実通信未確認
情報確認基準日：2026年10月5日
大きなファイルの先頭100byteだけ確認したい、途中からダウンロードを再開したい、といった場面ではHTTPのRange requestが使われます。
curlなら --range で指定できます。
先頭100byteを要求する
Range対応の検証用URLへ次のように送ります。
curl --range 0-99 --dump-header - --output /dev/null https://example.com/large-file.bin
0-99 はbyte位置0から99まで、つまり100byteです。
サーバーが要求を満たした場合、典型的には次のような情報を確認します。
HTTP/1.1 206 Partial Content Content-Range: bytes 0-99/12345
RFC 9110では、Content-Range は206応答で、返した範囲と完全な表現の長さを示すために使われます。
200と206は意味が違う
通常のGETで全体を返すなら 200 OK が一般的です。
一方、Range要求に対して一部分を返す場合は 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など"]
Rangeヘッダーを送ったからといって、必ず206になるとは限りません。サーバーがRangeを無視して全体を返す場合もあります。
Content-Rangeを読む
例えば、
Content-Range: bytes 0-99/12345
なら、
bytes：単位0-99：今回返した範囲12345：完全な表現の長さ
という意味です。
「100byte受け取った」だけではなく、元データ全体のどこを受け取ったか分かります。
Accept-Rangesは何を見る？
HEADで確認すると、
Accept-Ranges: bytes
が返ることがあります。
curl -I https://example.com/large-file.bin
これはbyte rangeを受け付けることを示す手掛かりです。
ただしRFC 9110でも、Range対応状況は条件や中継経路等で変わり得ます。最終的には実際にRange requestを送り、レスポンスコードと Content-Range を確認します。
末尾100byteも指定できる
curl --range -100 https://example.com/large-file.bin
のように末尾側を指定する方法もあります。
一方、
curl --range 1000-1999 https://example.com/large-file.bin
なら特定の中間範囲を要求します。
範囲外なら416になることがある
存在しない範囲を要求すると、416 Range Not Satisfiable が返る場合があります。
RFC 9110では416応答で、
Content-Range: bytes */12345
のように完全な長さを示す場合があります。
flowchart TD
A["Range要求"] --> B{"指定範囲は妥当?"}
B -- Yes --> C["206 + Content-Range"]
B -- No --> D["416 Range Not Satisfiable"]
D --> E["Content-Range: bytes */全体長"]
ダウンロード再開と関係する
Rangeは大きなダウンロードを途中から再開する仕組みの基礎にもなります。
ただし、途中で対象ファイルそのものが更新されていたら、古い前半と新しい後半をつないでしまう危険があります。
そのため実務の再開処理ではRangeだけでなく、ETagやLast-Modifiedなどによる同一性確認も重要です。 検索意図を混ぜないため、ETag/304の詳しい説明は別テーマとし、ここではbyte rangeの要求と応答に絞ります。
1か所だけ変える
最初の、
--range 0-99
を、
--range 100-199
へ変えます。
レスポンスの Content-Range も対応して変わるか確認します。
さらに、
--range 999999999-
のように対象サイズを超える範囲を安全な検証用URLへ指定すると、416の挙動も観察できます。
curlの出力を本文とヘッダーで分ける
本文を保存せずヘッダーだけ観察したいなら、
curl --range 0-99 --dump-header - --output /dev/null https://example.com/large-file.bin
とします。
これなら巨大ファイルを記事の確認だけのために保存しません。
実務で見る順番
Range関連の障害では次の順で見ると整理しやすくなります。
HEADで
Accept-Rangesを確認小さい範囲を実際に要求
HTTP statusを確認
Content-Rangeを確認想定したbyte数か確認
proxy/CDNを経由する場合は経路差も確認
「Accept-Rangesがないから絶対に非対応」「Rangeを付けたから絶対に部分取得」と早合点しないことが大切です。
Daily-Code-Samples
URLとbyte範囲を引数で渡し、HEADとRange応答ヘッダーを確認するスクリプトを用意しています。
