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

Question

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

httphttp-headers

45

在我的问题“搜索引擎是否尊重HTTP头字段Content-Location？”的评论中感到困惑/受到启发，我想知道HTTP头中Content-Location的确切目的是什么，以及它如何使用，但要确保不改变原来的意思。

- Gumbo

4个回答

14

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 Content-Location的任何优势（我曾经希望这可用于提示关于永久书签位置的信息，以防当前查看的URL是易变的，例如domain.com/news/latest，但似乎这不是情况）。

我的建议是忘记在HTTP中使用Content-Location，但您可以在MIME电子邮件中使用它。

- Mikko Rantalainen

请注意，https://datatracker.ietf.org/doc/html/rfc7231#section-3.1.4.2 更改了基本URL计算的定义，因此Content-Location不能安全地用于HTTP上的任何内容，因为其解释取决于用户代理是否遵循RFC 7231或RFC 2616的定义。有关详细信息，请参见https://datatracker.ietf.org/doc/html/rfc7231#appendix-B。 - Mikko Rantalainen

9

RFC 2616的第14.14节（链接）指出：

当实体可以从请求资源的URI分离的位置访问时，Content-Location实体标头字段可以用于提供消息中所包含实体的资源位置...

这在RFC 5023的AtomPub第9.2节（链接）中使用：

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

- Julian Reschke

2

请注意，AtomPub中描述的有关表示完整性的行为不受HTTP规范支持。 - ordnungswidrig

它将在httpbis: Part 2，第6.1节中：http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-12.html#rfc.section.6.1。 - Julian Reschke

请注意，RFC2616已被RFC7231所取代，您引用的文本不再适用于RFC7231！请参见第3.1.4.2节。 - exhuma

1

如果您感兴趣，可以查看RFC2557：http://www.faqs.org/rfcs/rfc2557.html以获取更深入的解释。我目前正在为一门课程撰写相关内容。虽然它有点老，但仍然具有相关性。

- seanAshmore

1

据我所知，RFC 2557与HTTP Content-Location无关。 - Mikko Rantalainen

1

我不确定我们是否在谈论同一件事，但RFC声明：该文档... b）指定了一个MIME内容头（Content-Location），允许multipart/related text/html根正文部分中的URI引用同一multipart/related结构中其他正文部分中的子资源。 - seanAshmore

1

据我所知，RFC 2557 是关于将多个资源作为单个文件包含在一起的聚合文档的，其中集合中某个资源的 "Content-Location" 标头用于定义可以用于引用该特定资源的 URI。 RFC 2557 定义的聚合文档类型通常不受称为 WWW 浏览器的软件支持。最接近的匹配是 Microsoft Internet Explorer 的 "保存为 HTML 存档" 功能。 - Mikko Rantalainen

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Rob Wells · Accepted Answer

在HTTP协议中，当请求的资源有多种表示方式（例如多种语言）时，可以使用Content-Location来响应GET请求。返回的资源选取依赖于原始GET请求中的Accept标头。

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

在响应PUT或POST请求时：

如果Content-Location 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请求的结果与通过同一位置发起200响应的GET请求获得的响应结果相同，并且可以进行缓存处理。（参见https://www.rfc-editor.org/rfc/rfc7231#section-3.1.4.2）请注意，Firefox和Chrome似乎没有实现这一点。