我想知道搜索引擎是否尊重HTTP头字段Content-Location.
这可能很有用,例如,当您要从URL中删除会话ID参数时:
GET /foo/bar?sid=0123456789 HTTP/1.1
Host: example.com
…
HTTP/1.1 200 OK
Content-Location: http://example.com/foo/bar
…
澄清:
我不想重定向请求,因为删除会话ID会导致完全不同的请求,因此可能也会产生不同的响应.我只是想声明所附的响应也可以在其"主URL"下找到.
也许我的例子不能很好地反映我的问题的意图.那么请看一下HTTP头字段"Content-Location"的目的是什么？.
根据http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10，客户端必须在 POST、PUT 或 DELETE 请求后使与 URL 关联的缓存无效。
是否可以指示 Web 浏览器使任意 URL 的缓存失效，而不向其发出 HTTP 请求？
例如：
PUT /companies/Nintendo创建一家名为“任天堂”的新公司GET /companies列出所有公司GET /companies. 浏览器不会自动执行此操作，因为两者在不同的 URL 上运行。该Cache-Control机制是否不适合这种情况？我应该使用no-cachewithETag来代替吗？对于这种情况，最佳做法是什么？
no-cache我知道下次可以通过，GET /companies但这需要应用程序跟踪 URL 失效，而不是将责任推给浏览器。意思是，我想在步骤 1 之后使 URL 失效，而不是必须保留此信息并在步骤 2 中应用它。有什么想法吗？
暂时忽略3xx响应,我想知道为什么HTTP位置标头仅与POST请求/ 201(创建)响应一起使用.
来自RFC 2616规范:
对于201(已创建)响应,Location是请求创建的新资源的位置.
这是一种受到广泛支持的行为,但为什么不应该将其与其他HTTP方法一起使用？以JSON API规范为例:
它为JSON有效负载内的当前资源定义了一个自引用链接(对于RESTful API来说并不罕见).此链接包含在每个有效负载中.该规范说,你必须包括HTTP标头的位置,如果你创建通过POST,且这个值是一样的,在有效载荷自参考链接一个新的文件,但是这仅需要POST.如果您可以使用HTTP位置标头,为什么还要使用自引用链接的自定义格式？
注意:这不是特定于JSON API的.这是对同一HAL,JSON的Hyper-模式或其他标准.
注意2:它甚至不是特定于HTTP位置标头,因为它与HTTP链接标头相同.正如您所看到的,JSON API,HAL和JSON Hyper-Schema不仅定义了自引用链接的约定,还表达了有关资源的相关资源或可能的操作的信息.但似乎他们都可以使用HTTP链接头.(如果他们不想使用HTTP位置标头,他们甚至可以将自引用链接放入HTTP链接头.)
我不想咆哮,它似乎只是某种"重新发明轮子".它似乎也是非常有限的:如果你只是使用HTTP位置/链接头,那么你在HTTP接受头中询问JSON,XML或其他什么并不重要,你会获得关于你的资源的有用的元信息HEAD请求,如果您使用JSON API,HAL或JSON Hyper-Schema,则不包含链接.