由于我们的网络服务器配置错误，主域名将302重定向发送到新位置。我们解决了这个问题。当清空浏览器缓存时，一切正常。
对于未清空缓存的“普通”客户端：302重定向在浏览器中保留了多长时间？
我在默认设置下为每个主流浏览器（Chrome，Firefox，Safari，Opera，Edge，IE 12）寻找特定缓存时间（如果有）。
答案 0 :(得分：27)
除非Web服务器还返回Cache-Control或Expires标头，否则不应该缓存它。根据{{3}}
请求的资源暂时驻留在不同的URI下。由于重定向有时可能会被更改，因此客户端应该继续使用Request-URI来处理将来的请求。如果由Cache-Control或Expires头字段指示，则此响应仅可缓存。
答案 1 :(得分：12)
Jon Lin引用的标准使用＆＃34; SHOULD＆＃34;，这是RFC术语中的not as strong as "MUST"。这不仅仅是理论上的干扰;例如，Cloudflare does cache redirects：
如果没有提供缓存头（没有缓存控制或过期）和 url是可缓存的（.jpg，.css，.js等），然后CloudFlare缓存两者 301和302s。我们缓存301几个小时和302s一个 更短的时间（约20分钟）。
因此，您应该确保可以处理它或使用显式标头（例如Cache-Control: private, no-cache）来指导浏览器和中间人对其进行缓存。
答案 2 :(得分：3)
使用史蒂夫·桑德（Steve Sounder）的Redirect Caching Tests tool（感谢@LeonidVasilev），看来结果可能与预期不符。没有过期的标头或cookie，结果如下：
Chrome 71 ：未缓存✔
Firefox 64 ：已缓存✕
Safari 12 ：已缓存✕
因此，尽管RFC 2616, section 10.3.3 302 Found指出了什么，但并不是所有的浏览器都遵循这些准则或可能被视为预期的行为：（
答案 3 :(得分：1)
添加
Cache-Control: no-store
响应的标题，它不会被缓存。截至2020年7月20日，所有主流浏览器都对此予以尊重。
尽管要注意中间缓存（代理/ CDN）：如果中间媒介的最小TTL不为零，则无论您做什么都将缓存您的响应。参见例如：
Managing How Long Content Stays in an Edge Cache (Expiration)
表的最后一行（ Origin添加了Cache-Control：对象没有缓存，没有存储和/或私有指令）。在这种情况下，防止缓存的唯一方法是将TTL设置为0（并添加Cache-Control: no-store标头）。
答案 4 :(得分：0)
这取决于个人客户端的浏览器缓存设置：IE可以选择“从不”检查新页面，它对重定向具有相同的效果。
而AFAIR IE的“自动”设置（默认？）并没有好多少。
答案 5 :(得分：0)
Firefox
，不应对其进行缓存