覆盖 HTTP 301 响应答案

【问题标题】：Overwriting HTTP 301 responses覆盖 HTTP 301 响应
【发布时间】：2017-01-17 20:31:49
【问题描述】：

我在一个网站上有两个页面。最初 /a 返回一个 301 重定向到 /b。我已更改页面，以便 /b 现在返回 301 重定向到 /a（现在有内容而不是 /b）。我看到的行为是浏览器使从/a 到/b 的301 无效，并用从/b 到/a 的新301 替换它，从而防止重定向循环。

我想确认我在当前浏览器（Chrome、Firefox、IE 和 Edge）中看到的行为被理解为正确行为。我看过RFC 2616，但据我所知，它并没有涵盖这个极端情况。任何人都可以确认这是规范定义的行为，还是公认的先例（即浏览器多年来一直以这种方式行事）？

有关更多信息，我正在处理的具体案例是一个页面，该页面主动从 HTTPS 重定向到 HTTP。我想扭转这一点以强制使用 HTTPS。在我的例子中，/a 和 /b 实际上是同一个页面，只是通过不同的协议访问。

编辑

Section 10.3 of RFC 2616 说：

客户端应该检测无限重定向循环，因为这样的循环会为每个重定向生成网络流量。

我猜这是我所看到的缓存清除行为的指导原则。关于行为是否符合规范，或者只是唯一有意义的事情，仍然不是一个可靠的答案。

编辑 2

RFC 中的另一个相关位 (Section 13.12)

如果在缓存同一资源的任何现有响应时从资源接收到新的可缓存（参见第 14.9.2、13.2.5、13.2.6 和 13.8 节）响应，则缓存应该使用新响应来回复到当前请求。它可以将它插入到缓存存储中，并且如果它满足所有其他要求，则可以使用它来响应任何未来的请求，这些请求以前会导致旧的响应被返回。如果它将新响应插入缓存存储，则适用第 13.5.3 节中的规则。

根据我发布的部分，我看到的行为似乎是规范所建议的，如果没有完全说明的话。

【问题讨论】：

想详细说明一下？我了解浏览器会无限期地缓存 301。我特别好奇新的 301 取代旧的情况。
啊，对不起，我看错了。
这似乎在这个答案的第二部分讨论得很好：stackoverflow.com/a/21396547/1072229
@GrishaLevit 我看到了答案的那一部分。不幸的是，对于发布新的 301 是否真的有效，我对这个答案感到不舒服。
FWIW，RFC 2616 已过时。您确实需要查看 RFC 7231。

标签： http browser-cache

【解决方案1】：

Redirection 3xx section of RFC 7231 超文本传输协议 (HTTP/1.1)：语义和内容定义了该行为。相关摘录：

客户端应该检测并干预循环重定向（即， “无限”重定向循环）。

注意：本规范的早期版本建议使用最多五个重定向（[RFC2068]，第 10.3 节）。内容开发人员需要注意，一些客户端可能会实现这样的一个固定的限制。

【讨论】：