理想情况下,修改后的资源将在首次请求时无条件获取,然后从本地缓存中检索,直到它到期且没有后续服务器交互。
跟踪不同的排列可能会有些混乱,因此我创建了下表。这些观察结果是通过从Chrome向IIS发出请求并在开发人员控制台中观察响应/行为而生成的。
在所有情况下,新的URL都将产生HTTP200。重要的是 后续 请求会发生什么。
+---------------------+--------------------+-------------------------+
| Type | Cache Headers | Observed Result |
+---------------------+--------------------+-------------------------+
| Static filename | Expiration +1 Year | Taken from cache |
| Static filename | Expire immediately | Never caches |
| Static filename | None | HTTP 304 (not modified) |
| | | |
| Static query string | Expiration +1 Year | HTTP 304 (not modified) |
| Static query string | Expire immediately | HTTP 304 (not modified) |
| Static query string | None | HTTP 304 (not modified) |
| | | |
| Random query string | Expiration +1 Year | Never caches |
| Random query string | Expire immediately | Never caches |
| Random query string | None | Never caches |
+---------------------+--------------------+-------------------------+
但是 ,请记住,浏览器和Web服务器并不总是按照我们期望的方式运行。一个著名的例子:2012年,移动Safari开始缓存POST请求。开发人员不满意。
ASP.Net MVC Razor语法中的示例,但几乎适用于所有服务器处理语言。
…由于某些应用程序传统上使用带有查询URL的GETs和HEADs(在rel_path部分中包含“?”的URL)来执行具有明显副作用的操作,因此,除非服务器提供了响应,否则缓存不得将对此类URI的响应视为新鲜的明确的到期时间。这特别意味着,不应从缓存中获取来自HTTP / 1.0服务器对此类URI的响应。
将随机参数添加到HTML中包含的CSS URL的末尾将强制执行新请求,并且服务器应使用HTTP200响应(而不是304,即使尚未修改)。
<link href="normalfile.css?random=@Environment.TickCount" />
当然,如果我们对 每个 请求随机分配查询字符串,这将完全破坏缓存。
如果仅维护一些URL,则可以手动修改它们以包含内部版本号或日期:
@{
var assembly = Assembly.GetEntryAssembly();
var name = assembly.GetName();
var version = name.Version;
}
<link href="normalfile.css?build=@version.MinorRevision" />
这将在用户代理第一次遇到URL时引起一个新请求,但是后续请求将大部分返回304。这仍然会导致发出请求,但至少不会提供整个文件。
更好的解决方案是创建一条新路径。只需一点努力,即可自动完成此过程,以使用版本号(或其他一致的标识符)重写路径。
该答案显示了用于非Microsoft平台的一些简单而优雅的选项。
微软开发人员可以使用HTTP模块来拦截给定文件类型的所有请求,或者可以利用MVC路由/控制器组合来提供正确的文件(我还没有看到这样做,但是我相信这是可行的)。