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

困惑/受到对我的问题的评论的启发搜索引擎是否尊重HTTP标题字段"Content-Location"？,我想知道,Content-LocationHTTP中头字段的确切目的是什么以及如何使用它.

1> Rob Wells..：

---

响应于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请求的响应与对同一位置的GET请求的200响应所接收的响应相同因此可以缓存.(请参阅https://tools.ietf.org/html/rfc7231#section-3.1.4.2)请注意,Firefox和Chrome似乎没有实现此目的.

---

响应PUT或POST的Content-Location使指示的URI的高速缓存无效.它在最初的HTTP 1.1规范中:http://tools.ietf.org/html/rfc2616#section-13.10

2> Mikko Rantal..：

---

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

但请注意,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/latest但似乎并非如此).

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

3> Julian Resch..：

---

RFC 2616的第14.14节规定:

当从与请求资源的URI分开的位置访问该实体时,Content-Location实体头字段可用于为消息中包含的实体提供资源位置...

这在AtomPub中使用(RFC 5023,第9.2节):

如果创建请求包含Atom Entry Document,并且来自服务器的后续响应包含与Location-character字符匹配的Content-Location标头,则客户端有权将响应实体解释为完整表示新创建的条目.如果没有匹配的Content-Location标头,客户端绝不能假设返回的实体是创建的资源的完整表示.

---

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