IIS 7 返回 304 而不是 200

根据HTTP1.1 规范的第 14.9 节，Cache-Control 标头的no-cache指令只能由源服务器强制执行，这意味着 IIS 会忽略您请求中的标头。

缓存控制指令可以分为以下一般类别：

  - Restrictions on what are cacheable; these may only be imposed

由源服务器。

第 14.9.1 节将public、private和定义no-cache为限制可缓存内容的指令，这些指令只能由服务器强制执行。

如果您不希望缓存 .js 文件，则需要no-cache在应用程序中设置指令（即 ASP.NET 代码），或者您需要更改Cache-Control请求中的标头以使用该no-store指令而不是no-cache.

编辑：
根据您的评论 - 是的，我假设您不希望缓存文件。那么，304 可能是由于文件位于 IIS 的内部缓存之一中而出现的。看看这些：

• 在 IIS7 中配置输出缓存
• IIS7 中的缓存

我遇到同样的问题已经有一段时间了，并且所有缓存都关闭了……但是，我在某个时候为 IIS7 安装了压缩模块，默认情况下，它在我现有的站点上启用了静态文件的压缩。我关闭了受影响站点的所有压缩功能，现在它们似乎可以正常工作。

我们也遇到了这个错误，但我们使用的是资产管理库（Cassette）。在对此问题进行广泛调查后，我们发现此问题的根本原因在于 ASP.NET、IIS 和 Cassette 的组合。我不确定这是否是您的问题（使用HeadersAPI 而不是CacheAPI），但模式似乎是相同的。

错误 #1

Cassette 将Vary: Accept-Encoding标头设置为对捆绑包的响应的一部分，因为它可以使用 gzip/deflate 对内容进行编码：

• BundleRequestHandler：https ://github.com/andrewdavey/cassette/blob/a2d9870eb0dc3585ef3dd542287595bc6162a21a/src/Cassette.Aspnet/BundleRequestHandler.cs#L78
• HttpResponseUtil：https ://github.com/andrewdavey/cassette/blob/a2d9870eb0dc3585ef3dd542287595bc6162a21a/src/Cassette.Aspnet/HttpResponseUtil.cs#L45

但是，ASP.NET 输出缓存将始终返回首先缓存的响应。例如，如果第一个请求有Accept-Encoding: gzip并且 Cassette 返回 gzip 压缩的内容，则 ASP.NET 输出缓存会将 URL 缓存为Content-Encoding: gzip. 对相同 URL 但使用不同的可接受编码（例如 ）的下一个请求Accept-Encoding: deflate将返回缓存的响应Content-Encoding: gzip。

此错误是由 Cassette 使用HttpResponseBase.CacheAPI 设置输出缓存设置（例如Cache-Control: public）但使用HttpResponseBase.HeadersAPI 设置Vary: Accept-Encoding标头引起的。问题是 ASP.NETOutputCacheModule不知道响应头；它只能通过CacheAPI 工作。也就是说，它希望开发人员使用不可见的紧密耦合 API，而不仅仅是标准 HTTP。

错误 #2

使用 IIS 7.5 (Windows Server 2008 R2) 时，错误 #1 可能会导致 IIS 内核和用户缓存出现单独的问题。例如，一旦使用 成功缓存了一个包Content-Encoding: gzip，就可以在 IIS 内核缓存中使用netsh http show cachestate. 它显示带有 200 状态代码和“gzip”内容编码的响应。如果下一个请求具有不同的可接受编码（例如 Accept-Encoding: deflate）和与捆绑包哈希匹配的If-None-Match标头，则进入 IIS 内核和用户模式缓存的请求将被视为未命中。因此，导致请求由返回 304 的 Cassette 处理：

• BundleRequestHandler：https ://github.com/andrewdavey/cassette/blob/a2d9870eb0dc3585ef3dd542287595bc6162a21a/src/Cassette.Aspnet/BundleRequestHandler.cs#L44

但是，一旦 IIS 的内核和用户模式处理了响应，他们将看到 URL 的响应发生了变化，并且应该更新缓存。如果netsh http show cachestate再次检查 IIS 内核缓存，缓存的 200 响应将替换为 304 响应。对捆绑包的所有后续请求，无论是否Accept-Encoding将If-None-Match返回 304 响应。我们看到了这个 bug 的破坏性影响，所有用户都被我们的核心脚本提供了 304，因为随机请求有一个意外的Accept-Encoding和If-None-Match.

问题似乎是 IIS 内核和用户模式缓存无法根据Accept-Encoding标头而变化。作为这一点的证据，通过将CacheAPI 与下面的解决方法一起使用，似乎总是会跳过 IIS 内核和用户模式缓存（仅使用 ASP.NET 输出缓存）。这可以通过netsh http show cachestate使用下面的解决方法检查是否为空来确认。ASP.NET 直接与 IIS 工作线程通信，以根据请求选择性地启用或禁用 IIS 内核和用户模式缓存。

我们无法在较新版本的 IIS（例如 IIS Express 10）上重现此错误。但是，错误 #1 仍然是可重现的。

我们对这个错误的最初修复是只对其他提到的 Cassette 请求禁用 IIS 内核/用户模式缓存。通过这样做，我们在我们的 Web 服务器前部署额外的缓存层时发现了错误 #1。查询字符串 hack 起作用的原因是，如果OutputCacheModuleAPI未Cache用于根据QueryString QueryString.

解决方法

无论如何，我们一直在计划离开 Cassette，因此我们没有维护我们自己的 Cassette 分支（或尝试合并 PR），而是选择使用 HTTP 模块来解决这个问题。

public class FixCassetteContentEncodingOutputCacheBugModule : IHttpModule
{
    public void Init(HttpApplication context)
    {
        context.PostRequestHandlerExecute += Context_PostRequestHandlerExecute;
    }

    private void Context_PostRequestHandlerExecute(object sender, EventArgs e)
    {
        var httpContext = HttpContext.Current;

        if (httpContext == null)
        {
            return;
        }

        var request = httpContext.Request;
        var response = httpContext.Response;

        if (request.HttpMethod != "GET")
        {
            return;
        }

        var path = request.Path;

        if (!path.StartsWith("/cassette.axd", StringComparison.InvariantCultureIgnoreCase))
        {
            return;
        }

        if (response.Headers["Vary"] == "Accept-Encoding")
        {
            httpContext.Response.Cache.VaryByHeaders.SetHeaders(new[] { "Accept-Encoding" });
        }
    }

    public void Dispose()
    {

    }
}

我希望这对某人有帮助?！