强制浏览器缓存对 Castle MonoRail 操作的请求？答案

【问题标题】：Force the browser to cache a request to a Castle MonoRail action?强制浏览器缓存对 Castle MonoRail 操作的请求？
【发布时间】：2009-04-16 16:18:47
【问题描述】：

在我们的项目中，我们有一大堆小的 css/js 文件，所以当我们构建视图时，我们发现自己写了很多 <link> 或 <script> 标签，迫使浏览器对我们的 css/js 发出许多请求内容。为了解决这个问题，我们开始寻找一种方法让服务器将所有这些都支持到一个请求中，该请求将与操作关联的每个 css 文件或每个 js 文件转储到响应中。

没有太多细节，我们创建了一个 Helper 类，它接受文件，连接它们，并呈现如下标签：

<script type="text/javascript" src="/content/js15628453.rails"></script>

ContentController 然后有一个默认操作，它使用“js15628453”来查找 Helper 存储连接文件的位置并将其输出。这真的很好用。

但是，正如 Firebug 报告的那样，浏览器总是向“/content/js15628453.rails”发送请求以获取连接的文件，尽管 URL 始终相同并且响应始终相同。我已经尝试了 HTTP Cache-Control、Expires、Last-Modified 等标头的所有类型的组合，但还没有得到 Firebug 报告为从缓存中加载的内容。

为什么浏览器会忽略这些标头？是否有任何其他选项我可以尝试强制它被缓存？

【问题讨论】：

标签： caching http-headers castle-monorail

【解决方案1】：

好吧，我想通了，所以为了那些可能在搜索引擎中找到它的人的利益，我会继续回答我自己的问题。

基本上，我必须自己编写设置304状态的逻辑：

DateTime lastModified = // some date
string ifModifiedSince = Request.Headers["If-Modified-Since"];
if ( ifModifiedSince != null )
{
    var requestDate = DateTime.Parse( ifModifiedSince );
    if ( requestDate <= lastModified )
    {
        CancelView();
        Response.StatusCode = 304;
        return;
    }
}

Response.CachePolicy.SetLastModified( lastModified );

// Logic to write the file to the OutputStream

我错误地假设浏览器只会使用它的缓存副本，如果它存在并且没有过期，而它显然需要询问服务器它的缓存副本是否仍然有效。

【讨论】：

【解决方案2】：

@Tinister：那么实际上你所做的是处理有条件的 GET 也就是说 - 当一个 Get 请求确实从客户端发送到服务器时，询问“你有没有比 X 更新的东西”，如果没有，服务器会说 304。您确实避免了服务器生成 js 和 js 内容的流量，但是请求的成本（即 - 从浏览器向服务器发送 http 请求）仍然存在。这些东西由 Last-Modified/IfMOdifiedThen 标头（一个用于响应，一个用于请求）和/或 ETAG 标头处理。

缓存是另一回事——即当浏览器决定根本不发出 GET 请求时。它由“Expires”标头或 Cache-control 标头管理。

您可能在某处设置了 Cache-Control 标头，这会使客户端忽略“过期”。尝试设置“max-age 3600”或类似的东西，看看请求是否被缓存（忘记 FB - 而是设置断点或登录服务器以确保它没有被调用）

话虽如此 - 在处理 js/css 文件时 - 您可能不想要实际缓存。那是因为如果浏览器决定缓存，比如说一个星期，那么你不能强迫它重新加载一个新版本。因此，如果您将新版本部署到服务器，客户端将在一周过去之前看到它，无论新资源的新时间（oe etag）是什么 - 因为它甚至不会发出条件 GET 请求.

一个解决方案（如果您真的想减轻网络压力）是设置最长缓存时间（比如一年），当资源更改时，您更改 URI（按原样 - 添加任意查询字符串值）。这将强制浏览器重新加载新的 js 资源，并且不再打扰服务器，至少在下一次更新 + 下一个资源 URI 之前

【讨论】：

【解决方案3】：

我注意到，至少 firefox 在计算它是否甚至处理 HEAD 请求以检查“未修改”(304) 响应代码时似乎使用了初始请求中的“最后修改”标记。

拥有一个非常旧的“最后修改”时间戳似乎会导致它不检查文件的任何新版本，除非明确要求。

但是，我不会过度依赖它。

【讨论】：