将HTTP Range Header与字节以外的范围说明符一起使用？

小编典典

将HTTP Range Header与字节以外的范围说明符一起使用？

ajax

核心问题是有关HTTP标头的使用，包括Range，If-
Range，Accept-
Ranges和用户定义的范围说明符。

这是一个虚构的示例，可以帮助说明我的问题。假设我有一个Web
2.0样式的应用程序，它显示某种人类可读的文档。这些文档在编辑上分为几页（类似于您在新闻网站上看到的文章）。对于此示例，假定：

有一个标题为“ HTTP范围问题”的文档分为三页。
外壳页面（/document/shell/http-range-question）知道有关文档的元信息，包括页面数。
文档的第一个可读页面是在页面onload事件期间通过ajax GET加载的，并插入到页面上。
一个看起来像 [1 2 3全部] 的UI控件位于页面的底部，单击数字将显示该可读页面（也通过ajax加载），然后单击“全部”将显示整个文档。假设针对1、2、3和所有用例的以下URL：
- /document/content/http-range-question?page=1
- /document/content/http-range-question?page=2
- /document/content/http-range-question?page=3
- /document/content/http-range-question

现在到问题。我可以使用HTTP Range标头代替URL的一部分（例如querystring参数）吗？也许这样的GET /document/content/http-range-question要求：

Range: page=1

看起来该规范仅将字节范围定义为允许的范围，因此，即使我使ajax调用与我的浏览器和服务器代码一起使用，中间的任何内容也可能破坏合同（例如，缓存代理服务器）。

Range: bytes=0-499

关于自定义范围说明符的任何观点或现实示例？

更新：我确实找到了有关Range标头在Rest
Collection中分页的类似问题，他们提到Dojo的JsonRestStore使用自定义Range标头值。

Range: items=0-24

阅读 480

2020-07-26

共1个答案

小编典典

绝对-您可以自由指定自己喜欢的任何范围单位。

根据RFC 2616：

3.12范围单位

HTTP / 1.1允许客户端请求仅将一部分
响应实体（一部分）包含在响应中。HTTP / 1.1在范围（第14.35节）和内容范围（第14.16节）
标头字段中使用范围单位。可以根据各种结构单元将实体分解为子范围。
  range-unit       = bytes-unit | other-range-unit
  bytes-unit       = "bytes"
  other-range-unit = token
HTTP / 1.1定义的唯一范围单位是“字节”。HTTP / 1.1
实现可以忽略使用其他单位指定的范围。

关键是最后一段。真正的意思是，当他们编写HTTP /
1.1规范时，他们只概述了“字节”令牌。但是，正如您从“其他范围单位”位可以看到的那样，您可以自由提出自己的令牌说明符。

提出自己的范围说明符确实意味着您必须控制使用该说明符的客户端和服务器代码。因此，如果您拥有公开“ / document / content / http-
range-question”
URI的后端，那您就很好了。大概您正在使用一个现代的Web框架，该框架可让您检查传入的请求标头。然后，您可以查看Range值以正确执行后备查询。

此外，如果您控制向后端发出请求的AJAX代码，则应该能够自行设置Range标头。

但是，您可能会想到一个潜在的弊端：破坏缓存的潜力。如果使用的是自定义范围单位，则客户端和原始服务器之间的所有高速缓存“可能会忽略使用[字节以外的单位]指定的范围”。因此，例如，如果您在前端和后端之间有一个Squid
/ Varnish缓存，则不能保证您希望的结果将从缓存中得到！

您可能还会考虑一种替代实现，其中使页面成为URI的“参数”而不是使用查询字符串。例如：/ document / content / http-range-
question / page / 1。对于您的服务器端来说，这可能需要做更多的工作，但是它是HTTP / 1.1兼容的，因此缓存应该适当地对待它。

希望这可以帮助。

2020-07-26