HTTP头字段内容位置的用途是什么?

为了响应GET请求,当请求的资源具有多个可用表示(例如多种语言)时,可以使用HTTP中的内容位置。返回资源的选择将取决于原始GET请求中的Accept头。

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

响应PUT或POST请求,

• 如果内容位置URI不同于请求的URI,则指示URI处的缓存项将无效。(见 https://www.rfc-editor.org/rfc/rfc7234#section-4.4 https://www.rfc-editor.org/rfc/rfc2616#section-13.10 )
• 如果内容位置URI与请求的URI相同,则这向缓存指示对PUT/POST请求的响应与对相同位置的GET请求的200响应将接收到的响应相同,因此可以缓存。(见 https://www.rfc-editor.org/rfc/rfc7231#section-3.1.4.2 )请注意,Firefox和Chrome似乎没有实现这一点。

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

这是因为RFC2616第14.14节说“内容位置的值还定义了实体的基本URI”。简言之,comforming用户代理将使用Content Location标头计算获取的文档的基本URL,如果获取的文档未定义基本URL和实际获取的URL以及内容位置差异足够大(URL的“目录”/“路径”部分不同),则可能会导致使用不同的相对URL。

此外,我还没有看到使用HTTP内容位置的任何优势(我曾经希望,如果当前查看的URL不稳定,例如domain.com/news/latest,但事实似乎并非如此,那么可以使用HTTP内容位置来暗示永久书签位置)。

Section 14.14 of RFC 2616 国家:

消息中包含的实体的资源位置 可以从与请求的实体分离的位置访问实体

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

如果创建请求包含Atom条目文档 匹配每个字符的位置标头字符,然后 新创建条目的完整表示形式。没有匹配的

查看RFC2557网址: http://www.faqs.org/rfcs/rfc2557.html 如果你感兴趣的话,请提供更深入的解释。我目前正在为一个班级写这篇文章。这有点旧,但仍然相关。