如何禁用Ajax缓存？

Question

我遇到了ajax缓存问题，这在IE浏览器中也存在问题，但我通过编写以下代码解决了问题。

    response.setHeader("Cache-Control", "no-cache");
    response.setHeader("expires","-1");
    response.setHeader("pragma","no-cache");

但我发现Safari4.0在MAC上缓存Ajax请求（我们有支持此要求的需求）。 Firefox从来没有问题。关于这个“Expire”，我将其设置为-1，我看到很多地方它被设置为0或一些过去的旧日期。这会有影响吗？

- pushya

Answer 1

在GET请求中发送一个额外的参数，该参数永远不会相同，例如当前时间戳。像这样：

url = url + '&nocache=' + new Date().getTime();

这将防止缓存。

- Ry-

---

虽然这个方法可以起作用，但它其实是一个 hack -- 我想知道为什么 Safari 显然忽略了头部信息并错误地缓存了某些内容。 - josh3736

@josh3736：我不确定。可能是因为变量名是response，而头部应该在request上设置，使用setRequestHeader。但这是防止缓存的“行业标准”方式，比设置头部要好得多 :) - Ry-

@minitech 我们正在设置 new Date().getTime() 的新日期。我们在使用自己的 ajax 库时发现了这一点。这是我们正在执行的操作。 this.get = function(queryString) { m_requestId = new Date().getTime(); m_request.open("GET", queryString, true); m_request.send(null); return m_requestId; }; - pushya

@minitech 我几乎不会说设置头文件是一种黑客行为。设置头文件是处理缓存的适当方式 - 日期技巧是由于IE的强制ajax缓存而使用的。 - Snuffleupagus

我假设response.setHeader调用是服务器代码，我们将在其中设置响应头。关于头部与缓存破坏参数，你实际上是相反的：HTTP头部是控制客户端和代理缓存的适当、RFC指定的位置。缓存破坏查询字符串参数只是一种常用的hack，依赖于副作用而不是标准。 - josh3736

Answer 2

首先，关于您的“Expires”头信息。由于您的问题没有说明使用的服务器框架，因此我不确定这是否适用。但是，看起来您可能正在发送一个无效的“Expires”头信息。

RFC要求“Expires”必须是日期，但是您似乎将头信息设置为文字“-1”。许多框架在其HTTP响应对象上具有一个过期属性，该属性接受一个整数并自动计算从现在开始的该秒数对应的日期。

使用HTTP检查器确保您的服务器发送的是格式正确的日期，而不是“Expires”头信息中的“-1”。

---

你可以尝试让你的Cache-Control头更加严格：

response.setHeader("Cache-Control", "private, no-cache, no-store, must-revalidate");

must-revalidate告诉缓存它们必须遵守您提供的任何新鲜度信息。HTTP允许缓存在特定条件下提供陈旧的表示; 通过指定此标头，您告诉缓存您希望它严格遵循您的规则。^[1]

- josh3736

Answer 3

根据RFC 2616第9.5节关于POST。

   Responses to this method are not cacheable, unless the response
   includes appropriate Cache-Control or Expires header fields. However,
   the 303 (See Other) response can be used to direct the user agent to
   retrieve a cacheable resource.

因此，除非响应另有规定，否则浏览器不得缓存POST响应。与此同时，浏览器可以缓存GET响应，除非响应另有规定。所以，对于不应该被缓存的请求，例如AJAX请求，POST是首选的方法。

如果您出于任何原因不想使用 AJAX 进行 POST，请使用minitech提到的“技巧”，这实际上是强制浏览器加载任何资源的当前版本的常用方法。

- Danubian Sailor