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

16

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

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

响应于PUT或POST请求，

如果内容位置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似乎没有执行此操作。

来源

2009-01-15 20:25:53

+0

的确，HTTP RFC认为PUT和POST没有定义Content-Location的行为。 – ordnungswidrig 2010-06-17 15:05:46

+1

见httpbis：第2部分，第6.1节：http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-12.html#rfc.section.6.1 – 2011-02-27 09:58:31

+1

这与“自我”有何不同“链接关系？ – HDave 2012-01-12 21:27:01

8

Section 14.14 of RFC 2616状态：

的内容位置实体头字段时，可以使用的是实体是从独立的可访问的位置，以提供用于封闭该消息中的实体的资源位置所请求的资源的URI ...

这在AtomPub (RFC 5023, Section 9.2)使用：

如果创建请求中包含一个Atom Entry文档，从该服务器后续响应包含字符换字符匹配Location头一个Content-Location头，则客户端被授权解释响应实体作为新创建的条目的完整表示。如果没有匹配的Content-Location标头，客户端肯定不会假设返回的实体是创建的资源的完整表示。

来源

2009-02-02 09:20:57

1

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

来源

2011-02-27 00:41:42 seanAshmore

11

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

但是请注意，HTTP内容 - 位置标头是在现实世界中使用的问题，因为不同的浏览器（用户代理）不同的处理： http://mail.python.org/pipermail/web-sig/2004-October/000985.html

这是因为2616款14.14它说“的价值Content-Location也定义了实体的基本URI“。简而言之，一个合适的用户代理将使用Content-Location头部计算获取文档的BASE URL，如果获取的文档没有定义BASE URL和实际获取的URL并且Content-Location不同，则可能导致使用不同的相对URL （URL的“目录”/“路径”部分不同）。此外，我还没有看到使用HTTP Content-Location的任何优势（我曾希望这可以用于提示永久性书签位置，以防万一当前查看的URL变得不稳定，例如domain.com/新闻/最新，但似乎并非如此）。

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

来源

2011-06-27 10:07:23

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

回答

相关问题