HTTP头字段“Content-Location”的目的是什么？
困惑/启发我的问题的评论search引擎是否尊重HTTP头字段“Content-Location”？ ，我想知道， HTTP中的Content-Location头域的确切目的是什么，以及如何使用它。
当请求的资源具有多个表示可用时，可以使用HTTP中的内容 – 位置，例如多种语言。 返回资源的select取决于原始GET请求中的Accept头。
通常情况下，Content-Location头中指定的位置与原始请求URI中指定的位置不同。
我不相信Content_Location有任何已定义的行为来响应PUT或POST请求。
Content-Location 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
这是因为RFC 2616第14.14节，它说“Content-Location的值也定义了实体的基本URI”。 简而言之，一个合适的用户代理将使用Content-Location头部计算获取文档的BASE URL，如果获取的文档没有定义BASE URL和实际获取的URL并且Content-Location差异足够的话，可能导致使用不同的相对URL （URL的“目录”/“path”部分不同）。
此外，我还没有看到使用HTTP内容 – 位置（我曾经希望这可以用于暗示关于永久书签位置，以防万一当前浏览的url是易变的，如domain.com/news/latest这似乎并不是这样）。
我目前的build议是忘记HTTP的Content-Location，但是您可以将其用于MIME电子邮件。
RFC 2616第14.14节规定：
Content-Location实体标题字段可以用来提供消息中包含的实体的资源位置，当该实体可以从与请求资源的URI分开的位置访问时…
这在AtomPub（RFC 5023，第9.2节）中使用 ：
如果创build请求包含primefaces条目文档，并且来自服务器的后续响应包含一个与Location头字符为字符匹配的Content-Location头，则客户端有权将响应实体解释为完整的新创build的条目。 如果没有匹配的Content-Location头，客户端不能假定返回的实体是创build的资源的完整表示。
如果您有兴趣，请查阅RFC2557： http ： //www.faqs.org/rfcs/rfc2557.html 。 我目前正在为这个课程写这个。 这有点老，但仍然相关。
