HTTP头字段“Content-Location”的目的是什么？

Question

对我的问题Do search engines respect the HTTP header field “Content-Location”?的评论感到困惑/启发，我想知道Content-Location header field in HTTP的确切目的是什么以及如何使用它。

Answer 1

响应于GET请求，当请求的资源具有多个可用表示时，可以使用HTTP中的内容位置，例如，多种语言。返回的资源选择将取决于原始GET请求中的Accept标头。

通常，Content-Location标头中指定的位置与原始请求的URI中指定的位置不同。

响应PUT或POST请求，

• 如果Content-Location URI与请求的URI不同，则指示的URI处的缓存条目无效。 （请参阅https://tools.ietf.org/html/rfc7234#section-4.4和https://tools.ietf.org/html/rfc2616#section-13.10）
• 如果Content-Location URI与请求的URI相同，则表示缓存对PUT / POST请求的响应与200响应GET请求时收到的响应相同相同的位置，因此可以缓存。 （请参阅https://tools.ietf.org/html/rfc7231#section-3.1.4.2）请注意，Firefox和Chrome似乎没有实现此功能。

Answer 2

Content-Location HTTP头应该声明用于响应HTTP GET的资源的唯一位置（例如请求是GET /frontpage HTTP/1.1，服务器可以添加HTTP头Content-Location: http://domain.com/frontpage.english.msie-optimized通知用户代理如果以后需要此特定响应，则应使用提供的位置，因为原始位置可能取决于各种事物，然后应通过“Vary”标题解释。

但是，请注意，HTTP Content-Location标头在实际使用中存在问题，因为不同的浏览器（用户代理）以不同方式处理它： http://mail.python.org/pipermail/web-sig/2004-October/000985.html

这是因为RFC 2616第14.14节说“Content-Location的值也定义了实体的基URI”。简而言之，一个符合要求的用户代理将使用Content-Location标头计算获取文档的BASE URL，如果获取的文档没有定义BASE url并且实际获取的URL和Content-Location足够不同，则可能导致使用不同的相对URL （URL的“目录”/“路径”部分不同）。

此外，我还没有看到使用HTTP内容位置的任何优势（我曾经希望这可以用于暗示永久书签位置，以防当前查看的URL不稳定，例如domain.com/news /最新，但似乎并非如此）。

我目前的建议是忘记HTTP的内容位置，但您可以将其用于MIME电子邮件。

Answer 3

Section 14.14 of RFC 2616州：

  

Content-Location实体标题字段可用于提供   消息中包含的实体的资源位置   可以从与请求分开的位置访问实体   资源的URI ......

这用于AtomPub (RFC 5023, Section 9.2)：

  

如果创建请求包含Atom Entry Document，那么   来自服务器的后续响应包含Content-Location标头   匹配Location头字符的字符，然后匹配   客户端被授权将响应实体解释为a   完整表示新创建的条目。没有匹配   Content-Location标头，客户端绝不能假设返回   entity是创建的Resource的完整表示。

Answer 4

如果您有兴趣，可以在http://www.faqs.org/rfcs/rfc2557.html查看RFC2557以获得更深入的解释。我正在为一堂课写这篇文章。它有点旧但仍然相关。