一个常见的"accept-ranges"标头是字节。 但是,对我来说,可能有数十种其他类型的范围是有道理的。
我正在编写一个采用日期范围的 API 资源。 在接受范围标头中指定日期并期望来自客户端的范围标头是否有意义?
我一直在研究与Accept-Range&Range标题相同的主题,似乎是传递分页数据的良好候选者。
HTTP1.1规范指出:
范围单位 = 字节单位 |其他范围单位
这表明您可以使用自己的单位类型,但接着说
HTTP/1.1 定义的唯一范围单位是字节。HTTP/1.1 实现可能会忽略使用其他单位指定的范围。
虽然唯一支持的范围单位是字节,但该声明确实强调 HTTP 1.1 可能(不应该)忽略其他单位中的范围 - 所以也许这取决于你?
但是,HTTP 标头包含与消息正文相关的数据,而不是消息正文所表示的数据,因此仅支持字节单位是有意义的,因为无论它表示什么资源,都可以将字节范围应用于消息正文。而日期范围是基于上下文的范围,仅适用于特定情况。
正如您在问题中提到的,实现日期范围的一种方法是在响应该 URL 的 HEAD 或 OPTIONS 请求时提供自定义的 Accept-Ranges 标头,然后将包含任何 GET 请求的范围标头传递给同一 URL
我认为是否以这种方式使用它取决于开发人员,但对我来说,这个孔对于这个方形钉子来说有点太圆了!传递查询字符串中的值。
参考:
3.12 Range Units
HTTP/1.1 allows a client to request that only part (a range of) the response entity be included within the response. HTTP/1.1 uses range units in the Range (section 14.35) and Content-Range (section 14.16) header fields. An entity can be broken down into subranges according to various structural units.
range-unit = bytes-unit | *other-range-unit*
bytes-unit = "bytes"
other-range-unit = token
The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units.
HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.12