Accept-Ranges Inspect

キャッシュ関連ヘッダーを横断して判定します。入力はサーバーへ送信しません。再検証やCDN差分の一次切り分けに使えます。

状態

ブラウザ内で処理します。入力はサーバーへ送信しません。まずはここで一次切り分けしてください。

使い方

Accept-Ranges か Response Headers を貼り付けて「解析」。レンジ対応の有無を整理します。

注意（このツール）

  • Accept-Ranges: のヘッダー行でも解析できます（複数行の貼り付けもOK）。

このページについて

何をするツール？

Accept-Ranges を分解し、Range リクエストが可能かどうかを一覧表示します。

動画/大容量ファイルの途中再生、レジューム、分割ダウンロードの切り分けに向きます。

基本（Accept-Ranges と Range）

  • Accept-Ranges: bytes は「Range に対応」を示します。
  • Accept-Ranges: none は「対応しない」を示します。
  • Range リクエストの成功時は 206 Partial Content が返ります。

入力の例

  • Accept-Ranges: bytes
  • Accept-Ranges: none
  • Response Headers をまるごと貼り付け

よくある落とし穴

  • Accept-Ranges が無い（実際は対応していてもヘッダーが出ないケースがある）
  • Range を送っても 200 が返る（実質的に未対応）
  • CDNがRangeを吸収して挙動が変わる

切り分け手順（おすすめ）

  • Response Headers Parser で Accept-Ranges を抽出
  • このツールで対応可否を整理
  • Range Request Builder で Range ヘッダーを試作
  • Range Request Builder
  • Content-Length Inspect
  • Response Headers Parser

推奨（実務）

  • 大きいファイル配信は Accept-Ranges を有効化
  • Range を受けるなら Content-Range と 206 を返す
  • ETag/Last-Modified と組み合わせると安全

このツールでできること

  • Accept-Ranges の値を整理
  • Range 対応有無の判定補助

注意（運用）

  • キャッシュ挙動はブラウザ/CDN/プロキシの層で変わるため、同一点観測で比較してください。
  • ヘッダー診断だけでは不十分な場合があります。アプリ側の更新戦略とキー設計も確認してください。

参照仕様

  • RFC 9110（HTTP Semantics）
  • MDN: Accept-Ranges

FAQ

Accept-Ranges が無いとRangeは使えない？

必ずしもそうではありませんが、対応有無が不明になるため実装としては出すのが無難です。

Range の成功時に返るステータスは？

206 Partial Content が返ります。

参考リンク

  1. RFC 9110
  2. MDN: Accept-Ranges

site_map ルールに基づいて、次に確認すべきページを表示しています。

  1. Range Request Builder — Range リクエストヘッダーを生成
  2. Content-Length Inspect — Content-Length を解析してサイズ整合を確認
  3. Content-Range Inspect — Content-Range を解析して返却範囲を確認
  4. If-Range Inspect — If-Range を解析して再取得条件を確認

Range/部分取得

Range/Content-Range/If-Range を突き合わせて部分取得の可否を確認