常见的“接受范围”标头是字节。但是,对我来说,可能有几十种其他类型的范围是有道理的。
我正在编写一个采用日期范围的 API 资源。在接受范围标头中指定日期并期望来自客户端的范围标头是否有意义?
常见的“接受范围”标头是字节。但是,对我来说,可能有几十种其他类型的范围是有道理的。
我正在编写一个采用日期范围的 API 资源。在接受范围标头中指定日期并期望来自客户端的范围标头是否有意义?
我一直在研究与 Accept-Ranges & Range 标头相同的主题,这似乎是传递分页数据的良好候选者。
HTTP1.1 规范指出:
范围单位 = 字节单位 | 其他范围单位
这表明您可以使用自己的单位类型,但接着说
HTTP/1.1 定义的唯一范围单位是字节。HTTP/1.1 实现可以忽略使用其他单位指定的范围。
尽管唯一支持的范围单位是字节,但该声明确实强调 HTTP 1.1 可以(不应该)忽略其他单位中的范围——所以这取决于你吗?
但是,HTTP 标头包含与消息正文相关的数据,而不是消息正文所代表的内容,因此仅支持字节单位才有意义,因为字节范围可以应用于消息正文,无论它代表什么资源。而日期范围是基于上下文的范围,仅适用于某些情况。
正如您在问题中提到的那样,实现日期范围的一种方法是在对该 URL 的 HEAD 或 OPTIONS 请求的响应中提供自定义Accept-Ranges标头,然后将带有任何 GET 请求的Range标头传递给相同的 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