在 curl 中指定 HTTP Range —— 解读 206 Partial Content 与 Content-Range

ネットワーク・RFCカテゴリを表すパンダのイラスト 网络・RFC

关于本文
本文是通过利用生成式 AI 的自动化生成流程创建的。本文将查阅 RFC 9110 的 Range 规范,并整理当使用 curl 请求指定字节范围而非整个文件时,206、Content-Range 和 416 之间的关联。

验证状态:📘 已确认 RFC 与 curl 规范,未进行外部服务器实际通信验证
信息核实基准日:2026年10月5日

在只想检查大文件的前 100 字节,或希望从中断处恢复下载等场景下,会使用 HTTP 的Range 请求。

对于 curl,可以使用 --range 进行指定。

请求前 100 字节

向支持 Range 的验证 URL 发送以下请求:

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

0-99 表示从字节位置 0 到 99,即 100 个字节。

如果服务器满足了该请求,通常会确认以下信息:

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:完整资源的长度

的意思。

不仅能知道“接收到了 100 字节”,还能知道接收到的是原始数据整体中的哪一部分。

Accept-Ranges 检查什么?

使用 HEAD 方法确认时,

Accept-Ranges: bytes

有时会返回。

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

这是指示服务器接受字节范围(byte range)请求的线索。

然而,根据 RFC 9110,Range 的支持情况也可能会因条件或中继路由等因素而异。最终还是要实际发送 Range 请求,并确认响应状态码和 Content-Range。

也可以指定最后的 100 字节

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 的详细说明将作为另一个主题,这里仅限于字节范围的请求与响应。

只更改一处

将最初的

--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 相关故障时,按以下顺序查看会更容易理清思路。

  1. 通过 HEAD 检查 Accept-Ranges 及对应内容

  2. 实际请求一个小范围

  3. 检查 HTTP 状态码

  4. Content-Range检查

  5. 确认是否为预期的字节数

  6. 如果经由代理/CDN,还需检查传输路径上的差异

切勿过早下定论,例如认为“没有 Accept-Ranges 就绝对不支持”或“加了 Range 就必定能部分获取”。

Daily-Code-Samples

我们准备了一个脚本,可以通过参数传入 URL 和字节范围,并检查 HEAD 与 Range 响应头部。

官方文档

文档信息

文章??
在 curl 中指定 HTTP Range —— 解读 206 Partial Content 与 Content-Range
?布日期
更新日期
来源
https://papanda925.com/?p=18049&lang=zh

?可: ?于本站?有相??利的正文及原??表,除非?有?明,可依据 CC BY 4.0 使用。本文可能包含使用生成式AI?建或??的内容。若代??有?可声明,或?接的GitHub???定了?可,?代?以??可?准。引用内容、第三方?料、?片及商?不在本?可范?内。 使用政策

标题和URL已复制