【发布时间】：2015-04-01 19:01:54
【问题描述】：
Range 标头如何与Content Negotiation 一起使用？ 让我解释一下，但首先让我们都同意以下几点：HTTP 是无状态协议。
当 HTTP 服务器能够发送单个资源的多个表示形式时，内容协商用于确定要发送的表示形式：客户端可能会指示其偏好（即英语和 GIF），然后服务器将遵守或 - 在它不能的场景——服务器会通过一些启发式评估来选择发送给客户端的表示。
到目前为止一切顺利...但是当您将Range 加入其中时会发生什么？
想象以下场景：
John 在巴黎的一个机场，他的浏览器发送了一个 HTTP 请求。 出于某种原因，他的浏览器没有显示任何内容类型的偏好， 语言和压缩。
GET /uri HTTP/1.1 Host: example.com由于它几乎没有经过，服务器通过一些启发式方法来决定 发送 URI 的法语表示（IP 被识别为来自法国。）
200 Okay Accept-Ranges: bytes Content: text/html Content-Language: fr ....data...在传输过程中，John 停止下载以赶上他的航班。约翰继续下载 一旦他到达纽约。
GET /uri HTTP/1.1 Host: example.com Range: 2000-3000同样，在客户端偏好信息很少的情况下，服务器这次决定 发送 URI 的英文表示（IP 被识别为来自纽约。）
此时，文件已损坏，因为其中一部分是法语，另一部分是英语。
猜想：
- 客户端可能会记住第一个响应中的内容类型和语言，以便
将该信息发送回服务器以获取第二个请求（在
Accept: text/html Accept-Language: fr下）。 但是，由于下界 RFC2616 和 RFC7233 对此没有任何说明（甚至不是建议），我相信 HTTP 客户端 这种行为很少见......但我还没有测试它。
注意事项：
- 在上面的场景中，我们可以很容易地让客户端发送首选项而让服务器无法遵守……但仍会退回到其他启发式方法。问题依然存在。
- 作为另一个例子，这个问题也存在于另一个 SO 问题中：Sample http range request session
TL;DR
GET /uri HTTP/1.1
Host: example.com
Accept: text/html; q=1.0, text/plain; q=0.8, */*; q=0.1
Accept-Language: en; q=1.0, */*; q=0.1
Range: 100-200
在上面，范围适用于所请求资源的哪种表示？！
【问题讨论】：
标签： http http-headers content-negotiation http-range