避免 301 重定向缓存

Posted 2023-02-22

【中文标题】避免 301 重定向缓存

【英文标题】：Avoiding 301 redirect caching

【发布时间】：2012-02-19 16:00:34

【问题描述】：

这是Using 301/303/307 redirects for dynamic short urls 的后续问题，我在其中尝试确定在目标 URL 频繁更改时实现短 URL 重定向的最佳方法。

虽然 301 和 307 重定向似乎都以相同的方式执行，但我担心的问题是 301 重定向缓存（如文档所述 here）- 是避免这种情况的最佳方法，而是使用 307 重定向（我假设 307 重定向永远不会缓存？），还是显式发送 no-cache 标头（“Cache-Control: no-cache, must-revalidate”）？

【问题讨论】：

相关：***.com/questions/12192590/…

【参考方案1】：

不要试图避免 301 缓存。如果您不希望任何用户代理缓存您的重定向，那么就不要使用 301 重定向。换句话说，301 缓存将继续存在，从语义上讲，它是一个 永久 重定向，因此如果您打算更改目标 URL，则 301 不是要使用的正确状态代码。另一方面，307 responses are not cached by default。

【讨论】：

您的解释违反了 HTTP 规范。当Cache-Control 出现在 301 上时，客户必须关注它。

RFC 说“301（永久移动）状态代码表明目标资源已被分配一个新的永久 URI”，所以是的，这意味着它是永久的。当然，从技术上讲，您可以将其用于其他目的，但是您误用了 HTTP 语义。

您对名称的解读过多。没有什么事情是永远的。域名被出售。公司破产。甚至有技术限制阻止了这一点：tools.ietf.org/html/draft-ietf-httpbis-p6-cache-24#page-28[...] extremely large values have been demonstrated to cause problems [...] 总之：Forever 只是意味着until the resource is deleted, or a reasonably long time.

您遗漏了最后一点：301 是 URI 规范化的唯一合理响应。代码 303 和 307 要求客户端在原始 URI 上重复请求（破坏 URI 规范化点）：tools.ietf.org/html/… Since the redirection can change over time, the client ought to continue using the original effective request URI for future requests. URI 规范化意味着客户端应该能够使用规范 URI 而不是重定向的别名给他们。代码 303 和 307 可以防止这种情况发生。

你说对了一件事：OP想要在不缓存的情况下重定向。在这种情况下，307 是更好的解决方案。我只是说301 和Cache-Control 标头是完全合理的，不应排除其他用途。

【参考方案2】：

在您希望 301 重定向带来的行为的情况下，例如更新浏览器书签和更改 google bot 中的 URL，但同时希望跟踪重定向或执行一些其他类型的功能，您可以始终将缓存控制标头添加到“无缓存”

HTTP/1.0 301 Moved Permanently
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires: Sat, 26 Jul 1997 05:00:00 GMT
Location: http://example.com

在 php 中是这样的：

header('Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0');
header('Expires: Sat, 26 Jul 1997 05:00:00 GMT');
header('Location:'.$url, true, 301);

相关： https://***.com/a/19003320/175071