HTTP 标头字段“Content-Location”的用途是什么？

Question

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

Answer 1

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

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

响应 PUT 或 POST 请求，

• 如果 Content-Location URI 与请求的 URI 不同，则指定 URI 处的缓存条目无效。 （见https://www.rfc-editor.org/rfc/rfc7234#section-4.4和https://www.rfc-editor.org/rfc/rfc2616#section-13.10）
• 如果 Content-Location URI 与请求的 URI 相同，则表明缓存对 PUT/POST 请求的响应与对 GET 请求的 200 响应接收到的响应相同相同的位置，因此可以被缓存。 （请参阅https://www.rfc-editor.org/rfc/rfc7231#section-3.1.4.2）请注意，Firefox 和 Chrome 似乎没有实现这一点。

Answer 2

Content-Location HTTP 标头应该声明用于响应 HTTP GET 的资源的唯一位置（例如请求是 GET /frontpage HTTP/1.1，服务器可以添加 HTTP 标头 Content-Location: @987654321@ 通知用户代理，如果这稍后需要具体响应，应使用提供的位置，因为原始位置可能取决于各种事物，然后应通过“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 Content-Location 的任何优势（我曾经希望这可以用于提示永久书签位置，以防当前查看的 URL 不稳定，例如 domain.com/news /latest 但似乎并非如此）。

我目前的建议是忘记 HTTP 的 Content-Location，但您可以将它用于 MIME 电子邮件。

Answer 3

Section 14.14 of RFC 2616 状态：

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

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

如果创建请求包含 Atom 条目文档，并且 来自服务器的后续响应包含一个 Content-Location 标头 与 Location 标头逐个字符匹配，然后 客户端被授权将响应实体解释为 新创建的条目的完整表示。没有匹配 Content-Location 标头，客户端不得假定返回的 entity 是已创建资源的完整表示。

Answer 4

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