接受范围请求的HTTP资源是否始终指定内容长度？

Question

在开始范围请求之前，我首先检查是否使用HEAD请求支持它。通常我会得到这样的东西：

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

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

在这种情况下，每个HTTP / 1.1规范是否保证Content-Length？我找不到确定的答案，但似乎在我做范围请求之前我需要知道Content-Length。

Answer 1

没有

根据任何其他具有200状态代码的响应，这样的响应应该（在RFC 2119意义上的“应该”，可以概括为“更好”一个该死的好理由，为什么不，并且能够说出该死的好理由是什么？）包括一个长度（RFC2616§14.13）禁止禁止的几个场景（§4.4）（特别是，值必须是两者实体和传输长度，因此仅在传输编码为“identity”[默认]时才有效。没有理由不将Accept-Ranges标头与分块和/或压缩传输编码一起发送。 （与压缩内容编码不同，在这种情况下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即使实体的大小小于500，123-500也是有效的，在这种情况下，将发送可用的八位字节。但是，如果整个实体中少于123个八位字节，则无效。 （§14.35.1）
5. bytes以外的值有效，但Accept-Range未定义。 （§3.12）这意味着服务器正在做一些非标准的事情，所以除非还提到bytes，否则你应该将其解释为不包括Accept-Range。
6. 虽然在包含Content-Length的回复中不包括Accept-Range有效，但不太可能。作为一项规则，如果您将此类响应视为未包含Accept-Range标题，那么您在面对此类行为时可以避免误操作，同时也可以从范围行为中获益绝大多数它出现的时间。