http - 接受范围请求的 HTTP 资源是否总是指定内容长度？

Question

在开始 Range 请求之前，我首先使用 HEAD 请求检查它是否受支持。通常我会得到这样的结果:

curl -X HEAD -i http://bits.wikimedia.org/images/wikimedia-button.png

HTTP/1.1 200 OK
...
Content-Length: 2426
Accept-Ranges: bytes
...

在这种情况下，Content-Length 是否根据 HTTP/1.1 规范得到保证？我找不到明确的答案，但在执行 Range 请求之前，我似乎需要知道 Content-Length。

Answer 1

没有。

根据任何其他具有 200 状态代码的响应，这样的响应应该(在 RFC 2119 意义上的“应该”可以概括为“最好有一个该死的好理由为什么不，并且能够说出那个该死的好理由是什么”)包括一个长度(RFC 2616 §14.13)禁止它被禁止的一些场景(§4.4)(特别是，该值必须是 实体和传输长度，因此仅在传输编码为“身份”[默认值] 时才有效。没有理由不需要将 Accept-Ranges header 与分块和/或压缩的传输编码一起发送。 (与压缩内容编码不同，在这种情况下，range，如 content-length 指的是压缩后的大小)。

一些值得注意的事情:

1. 服务器可能总是忽略range 请求并以完整长度响应，即使它另有建议也是如此。 (§14.35.2) 因此，您应该随时准备好接受这个。
2. 服务器可能会接受 Range 或 If-Range，即使它没有表明它会通过 Accept-Ranges。 (§14.5)
3. 有效的 Range 可以是例如123- 意思是“向我发送从八位字节 123 到结尾的所有内容。(§14.35.1)
4. Range 例如123-500 即使实体的大小小于 500 也是有效的，在这种情况下将发送尽可能多的可用八位字节。但是，如果整个实体中的八位字节少于 123 个，则它是无效的。 (§14.35.1)
5. bytes 以外的值有效，但未定义 Accept-Range。 (§3.12)这意味着服务器正在做一些非标准的事情，所以除非还提到了 bytes，否则您应该将其解释为不包括 Accept-Range。
6. 虽然在包含 Accept-Range 的响应中不包含 Content-Length 是有效的，但可能性不大。通常，如果您将此类响应视为它们没有包含 Accept-Range header ，那么您将不会在面对此类行为时出现失误，同时还可以从范围行为在绝大多数情况下都会出现。