更正HTTP响应头以在内容过期后导致304s

我希望HTTP响应在24小时后过期（这意味着浏览器在明天之前不会对该URL发出任何请求）。但是，如果请求在明天到期后重新发出，我希望确保浏览器将发送正确的请求头，以便服务器将发送304，而不是强制客户端重新下载整个响应体（如果服务器上没有更改）。我希望304也能在24小时后过期

首先，这可能吗？或者我必须在过期样式缓存和304样式缓存之间进行选择，但不能同时选择两者？如果可能的话，什么是正确的响应头（对于初始响应和后续的304s）将使其发生

如果像经常发生的那样，答案根据浏览器类型/版本而不同，那么哪些标题适用于哪些浏览器——哪些浏览器根本无法实现我想要的功能？我只对当今最常用的浏览器感兴趣（例如IE6+、FF3+、Chrome最新版本、Safari最新版本）

如果这个答案已经被问到了，我道歉。我搜索了一会儿，结果一无所获

澄清：我之所以提出这个问题，是因为我准备了一个自动化测试套件来验证，无论服务器平台如何，一个web应用程序是否正在生成正确的HTTP头，以生成我们希望所有web应用程序都具有的客户端缓存行为。因此，我对如何配置Apache/IIS/PHP/Rails/Django/JSP/ASP.NET/etc来生成正确的头文件不感兴趣（至少现在是这样）。我只是想知道，仅在HTTP层，正确的头是什么

更新：我找到了部分问题的答案。根据，它说，我应该在服务器返回的304s中包含

Expires:

或

Cache-Control:max-age

头。这绝对是我们想要的行为

---

然而，这个问题没有回答的是，这种符合RFC的方法是否适用于现有的流行浏览器，特别是IE6/7/8，它是标准遵从性的罪魁祸首，但我们的应用程序也必须支持IE9、FF4+、最新Chrome和最新Safari。如果这些浏览器中的任何一个不符合RFC的要求，我可以使用哪些变通方法？

我建议使用。

发送一个

ETAG

头，以便客户端可以发出一个有条件的HTTP请求，在响应的新鲜度生命周期到期后重新验证响应

发送

Cache Control:max age

或

Expires

指令以指定资源的过期时间

避免使用

Vary

标题或任何禁止缓存的指令

这些指令将在所有流行浏览器（IE6+、Firefox、Chrome）中运行，但Windows上的Safari除外，它本身缺乏跨多个会话运行的持久HTTP缓存

解释当无法提供正确的缓存标头时会发生什么情况

---

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

如果不知道该响应与哪个Web服务器相关，也不知道内容是由代码生成的，还是服务器提供的静态文件，则无法回答。在这种情况下，它们几乎肯定是动态请求，但我的问题是服务器平台不可知。我只是在寻找所需的HTTP响应头，以使客户端按照我的意愿进行缓存。我在问题的末尾添加了一个澄清来详细说明.ETag是不够的，因为客户端每次都会发出一个新的HTTP请求来检查ETag是否仍然是最新的。至少需要一个额外的标题来控制内容过期，以防止在检查新ETag之前24小时内发出任何请求。非常有用，谢谢Justin！因此，我想您需要将

Expires

标题与

ETag

一起使用，对吗？我不确定Expires+ETag是否会起到作用（即使可以，它是否可以跨多个浏览器工作？）。