HTTP Content Negotiation和Range标头

Question

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...

     

中途转移，约翰停止下载以赶上他的航班。约翰恢复了他的下载   一旦他到达纽约。

 GET /uri HTTP/1.1
 Host: example.com
 Range: 2000-3000

     

同样，由于客户端的偏好信息很少，服务器这次决定   发送URI的英文表示（IP被识别为来自纽约。）

到目前为止，该文件已损坏，因为部分文件是法文，另一部分是英文。

猜想：

• 客户端可能会记住第一个响应中的内容类型和语言 将该信息发送回服务器以获取第二个请求（在Accept: text/html Accept-Language: fr下）。 但是，由于nether 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

在上面，范围适用于所请求资源的哪种表示？！

Answer 1

简答：如果没有If-Match，请不要使用Range请求：etag请求标题字段。