我正在调试HTTP 301永久重定向的问题。经过快速测试后,似乎Safari在重启时清除了301s的缓存,但Firefox却没有。
IE,Chrome,Firefox和Safari什么时候清除301s的缓存?
更新:例如,如果我想将example1.com
重定向到example2.com
,但我不小心将其设置为重定向到example3.com
,这是一个问题。我可以纠正这个错误,但是在此期间访问过example1.com
的任何人都会缓存错误的重定向到example3.com
,因此他们将无法访问example1.com
或example2.com
,直到他们的缓存被清除。经过调查,我发现没有设置Cache-Control
和Expires
标头。不正确的301响应的标头将是这样的:
HTTP/1.1 301 Moved Permanently
Date: Wed, 27 Feb 2013 12:05:53 GMT
Server: Apache/2.2.21 (Unix) DAV/2 PHP/5.3.8
X-Powered-By: PHP/5.3.8
Location: http://example3.com/
Content-Type: text/html
我自己的测试表明:
至少有两个浏览器 - Chrome和Firefox - 将缓存301重定向,但没有过期日期。
也就是说,只要浏览器的缓存可以容纳缓存,它就会保持缓存状态。如果手动清除缓存,或者清除缓存条目以便为新缓存条目腾出空间,它将从缓存中删除。
你可以通过访问about:cache
并在磁盘缓存下找到它来至少在Firefox中验证这一点。
我不知道其他浏览器的行为,例如IE10 / IE11。但是,鉴于其他浏览器无限期地缓存它,您无论如何都必须适应这种情况。
在所有浏览器中,包括Chrome / Firefox,仍然可以使用标头覆盖此默认行为,如下所述:
注意:此答案是在2014年编写的,浏览器行为可能会随着时间而改变。
如果您不希望缓存重定向
这种不确定的缓存只是这些浏览器在没有Cache-Control头的情况下的默认缓存。逻辑是你指定一个“永久”重定向,而不是给他们任何其他缓存指令,所以他们会把它当作你想要它无限期缓存的对待。
如果指定了浏览器,浏览器仍然会像使用任何其他响应一样尊重Cache-Control和Expires标头。
您可以在301重定向中添加Cache-Control: max-age=3600
或Expires: Thu, 01 Dec 2014 16:00:00 GMT
等标题。您甚至可以添加Cache-Control: no-cache
,以便浏览器或Cache-Control: no-store
不会永久缓存它,因此浏览器甚至无法将其存储在临时存储中。
但是,在我看来,更好的选择是使用302或307重定向。这些并不意味着它们是“永久”重定向的浏览器或缓存,因此不应缓存在缓存控制头的缺失中。
对我来说,似乎发布301重定向但将其标记为不可缓存是违背301重定向的精神,即使它可能在技术上有效。 YMMV,您可能会发现边缘情况,“永久”重定向有时间限制。
如果您之前发布了301重定向但想要取消该重定向
如果人们仍然在浏览器中拥有缓存301重定向,则无论源页面是否仍具有重定向,它们都将继续被带到目标页面。您解决此问题的方法包括:
此外,预防胜于治疗 - 如果您不确定是否要永久取消旧URL,请避免301重定向。
作为@thomasrutter的回答
如果您之前发布了301重定向但想要取消该重定向
如果人们仍然在浏览器中拥有缓存301重定向,则无论源页面是否仍具有重定向,它们都将继续被带到目标页面。您解决此问题的方法包括:
最简单和最好的解决方案是再次发出另一个301重定向。
浏览器将意识到它被引导回到它之前认为是退役的URL,这应该导致它再次重新获取该URL以确认旧的重定向不存在。
如果您无法控制上一个重定向目标所在的站点,那么您将无法运气。尝试并请求网站所有者重定向回您。
事实上,这意味着:
然后它工作。
使用隐身/ InPrivate模式测试重定向,因此当您关闭浏览器时,它将刷新该缓存并重新打开窗口将不包含缓存。
正如其他答案所示。缓存可能无限期地在浏览器中。这非常危险。所以不要这样做。至少添加缓存标头。在htaccess中,我总是这样做,现在缓存:
<IfModule mod_rewrite.c>
RewriteCond %{HTTP_HOST} ^(www\.)?example\.com$ [NC]
# The E=nocache:1 sets the environment variable nocache to the value of one
RewriteRule ^/?(.*) https://www.example.org/$1 [L,R=301,E=nocache:1]
</IfModule>
<IfModule mod_headers.c>
## Set the response header if the "nocache" environment variable is set
## in the RewriteRule above.
Header always set Cache-Control "no-store, no-cache, must-revalidate" env=nocache
## Set Expires too ...
Header always set Expires "Thu, 01 Jan 1970 00:00:00 GMT" env=nocache
</IfModule>
为解决本地主机地址的问题,我更改了网站运行的端口号。这适用于Chrome版本73.0.3683.86。
要清除永久重定向,请转到chrome:// net-internals。在顶部红色状态栏的右侧,单击向下箭头▼打开下拉菜单,然后在“工具”组下,选择“清除缓存”。
从版本48开始,这是我唯一能够清除缓存301的东西。
更新:遗憾的是,自版本71(2018年12月)起,Google已删除了net-internals功能。
答案可以帮助那些迫切想要摆脱重定向缓存的人:
Chrome无限地缓存301重定向(在本地磁盘缓存中)。要清除此缓存:
F12
)F5
)当一切正常时,您可以取消选中“禁用缓存”,一切都将按预期继续工作。
让用户在该URL上提交一个帖子表单,缓存的重定向已经消失:)
<body onload="document.forms[0].submit()">
<form action="https://forum.pirati.cz/unreadposts.html" method="post">
<input type="submit" value="fix" />
</form>
</body>
301
是每个HTTP RFC的可缓存响应,浏览器将根据您对响应的HTTP缓存标头缓存它。使用FireBug或Charles检查响应标头,以了解响应缓存的确切持续时间。
如果您想控制缓存持续时间,可以使用HTTP响应头Cache-Control
和Expires
来执行相同操作。或者,如果您根本不想缓存301
响应,请使用以下标头。
Cache-Control: no-store, no-cache, must-revalidate
Expires: Thu, 01 Jan 1970 00:00:00 GMT
确认!让用户向受影响的网址提交帖子请求,忘记缓存的重定向。
如果您能够:快速获胜将在浏览器控制台中输入:
fetch('example.com/affected/link', {method: 'post'}).then(() => {})
如果您了解受影响的浏览器(特别是在开发期间),则非
或者,如果您可以访问之前的301重定向页面,则可以将此脚本添加到页面中,并且只要访问该页面,就会忘记缓存的301。
出于测试目的(避免缓存重定向),人们可以打开新的私人窗口:点击CTRL+SHIFT+
N
[如果你使用Mozilla,使用P
]
我有简单的解决方案,适用于所有主流浏览器(最新版本),包括IE,Chrome和FF