正确的HTTP响应标头在内容过期后导致304s

时间:2010-09-23 21:21:06

标签: http caching http-headers

我希望HTTP响应从现在起24小时后过期(这意味着浏览器明天才会对该URL发出任何请求)。但是,如果请求在到期后明天重新发出,我想确保浏览器将发送正确的请求标头,以便服务器发送304而不是强制客户端重新下载整个响应主体,如果它没有在服务器上没有改变。而且我希望304也会在24小时后过期。

首先,这个场景可能吗?或者我必须在Expiration风格的缓存和304风格的缓存之间做出选择,但不是两者都有?如果可能的话,那么正确的响应头(初始响应和后续的304)是什么?

如果经常发生,答案会根据浏览器类型/版本而有所不同,那么哪些标题适用于哪些浏览器 - 以及哪些浏览器无法完成我想要的操作?我只对目前使用的最常见的浏览器感兴趣(例如IE6 +,FF3 +,Chrome最新版,Safari最新版)?

如果已经在SO上询问了这个答案,我会道歉 - 我搜索了一会儿,然后空白了。

澄清:我问的是这个问题,因为我正在组建一个自动化测试套件来验证,无论服务器平台如何,Web应用程序正在生成正确的HTTP标头以生成客户端 - 我们希望所有Web应用程序都具有的缓存行为。所以我对如何配置Apache / IIS / PHP / Rails / Django / JSP / ASP.NET /等不感兴趣(至少现在)。生成正确的标题。我只是想知道,只在HTTP层,正确的标题是什么。

更新:我发现this SO question回答了我的部分问题。根据{{​​3}},它说,我应该在服务器返回的304s中包含Expires:Cache-Control: max-age标头。这绝对是理想的行为。

然而,这个问题没有回答的是这种符合RFC的方法是否适用于现有的流行浏览器,尤其是IE6 / 7/8,它们是通常的标准兼容罪魁祸首,还有IE9,FF4 +,最新Chrome ,以及我们的应用程序也必须支持的最新Safari。如果这些浏览器中的任何一个不符合RFC的要求,我可以使用变通方法吗?

2 个答案:

答案 0 :(得分:5)

发送ETAG标头,以便客户端可以发出条件HTTP请求,以在其新鲜度生命周期结束后重新验证响应。

发送Cache-Control: max-ageExpires指令以指定您希望资源过期的时间。

避免使用Vary标头或任何禁止缓存的指令。

这些指令适用于所有流行的浏览器(IE6 +,Firefox,Chrome),但Windows上的Safari除外,它本身缺少可在多个会话中使用的持久性HTTP缓存。

http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx解释了当您未能提供正确的缓存标头时会发生什么。

Fiddler的缓存响应检查器将帮助您了解如何缓存特定响应。

答案 1 :(得分:0)

我建议使用the ETag header