JSF 缓存静态资源过滤器 [英] JSF Cache Static Resources Filter
问题描述
我如何编写一个过滤器来适当缓存 Google 推荐的静态资源(https://developers.google.com/speed/docs/best-practices/caching).
创建一个将最后修改日期设置为某个静态日期的过滤器是否足够(每次服务器重新启动时都会更改)?
<块引用>指定 Expires 或 Cache-Control max-age 之一很重要，和 Last-Modified 或 ETag 之一，用于所有可缓存资源.它是多余的同时指定 Expires 和 Cache-Control: max-age，或者指定 Last-Modified 和 ETag.
上面的链接似乎表明您需要指定 Expires 或 Cache-Control.为什么有必要?
如何编写一个过滤器来适当缓存 Google 推荐的静态资源
如果您的意思是使用 JSF 资源，则 /resources 文件夹中的文件完全由 JSF 内置资源处理程序处理 (因此都通过<h:graphicImage>, #{resource} 并且因此不是通过纯 HTML 方式)，那么你就不需要自产自销了作业的过滤器.为了满足 Google 的建议，您唯一需要做的就是将 Expires 日期设置得更远一些.即默认为 7 天(604800000 毫秒)，而 Google Page Speed 和 Yahoo YSlow 等性能测试工具建议至少为 30 天(2592000000 毫秒).
在 Mojarra 中，您可以在 web.xml 中使用以下上下文参数进行设置:
<param-name>com.sun.faces.defaultResourceMaxAge</param-name><参数值>2592000000</参数值><!-- 30 天--></context-param> 并在 MyFaces 中使用以下内容:
<param-name>org.apache.myfaces.RESOURCE_MAX_TIME_EXPIRES</param-name><参数值>2592000000</参数值><!-- 30 天--></context-param> <小时><块引用>
创建一个将最后修改日期设置为某个静态日期的过滤器是否足够(每次服务器重新启动时都会更改)?
您不需要也不应该设置Last-Modified.JSF 资源处理程序已自动执行此操作.如果您因为更改了资源而想强制重新加载资源，请使用资源库版本控制.另请参见 什么是 JSF资源库用于以及如何使用?
请注意，每次服务器重新启动时更改它是没有意义的，因为 Expires 标头仍会继续告诉浏览器仅在一段时间后重新测试缓存的有效性.在浏览器实际请求资源之前，浏览器永远不会注意到资源的 Last-Modified 的变化.唯一迫使浏览器难以完全重新请求资源的是 URL 的更改，通常通过更改查询字符串参数值来实现.JSF 资源库版本控制正是这样做的.
还要注意 OmniFaces CombinedResourceHandler 使用资源的最后修改时间戳作为查询字符串中的资源版本"而不是资源库版本.因此，如果您正在使用它，则不一定需要资源库版本控制机制.
上面的链接似乎表明您需要指定 Expires 或 Cache-Control.为什么有必要这样做?
Expires 标头告诉浏览器何时通过条件 GET 请求重新测试缓存资源的有效性.所以，在那之前浏览器不会这样做，而是会继续使用缓存中的那个.Cache-Control 告诉浏览器使用哪种缓存策略.请注意，当它设置为例如no-cache 而不是 public，则 Expires 标头将不起作用.另请注意，缺少 Cache-Control 标头意味着 public(如 JSF 资源所做的那样).
How do I write a filter which will appropriately cache static resources as recommended by Google (https://developers.google.com/speed/docs/best-practices/caching).
Is it sufficient to create a filter which sets the last-modified date to some static date (this will change every time the server restarts)?
It is important to specify one of Expires or Cache-Control max-age, and one of Last-Modified or ETag, for all cacheable resources. It is redundant to specify both Expires and Cache-Control: max-age, or to specify both Last-Modified and ETag.
The link above seems to suggest you need to specify Expires or Cache-Control. Why is that necessary?
How do I write a filter which will appropriately cache static resources as recommended by Google
If you mean with JSF resources the files in /resources folder which are fully handled by JSF builtin resource handler (and thus all referenced via <h:outputStylesheet>, <h:outputScript>, <h:graphicImage>, #{resource} and thus not via the plain HTML way), then you don't need to homegrow a filter for the job. The only thing which you need to do to satisfy Google recommendations is to set the Expires date a bit further in the future. It namely defaults to 7 days (604800000 milliseconds) while performance testing tools like Google Page Speed and Yahoo YSlow recommends a minimum of 30 days (2592000000 milliseconds).
In Mojarra, you can set it with the following context parameter in web.xml:
<context-param>
<param-name>com.sun.faces.defaultResourceMaxAge</param-name>
<param-value>2592000000</param-value> <!-- 30 days -->
</context-param>
And in MyFaces with the following one:
<context-param>
<param-name>org.apache.myfaces.RESOURCE_MAX_TIME_EXPIRES</param-name>
<param-value>2592000000</param-value> <!-- 30 days -->
</context-param>
Is it sufficient to create a filter which sets the last-modified date to some static date (this will change every time the server restarts)?
You don't and shouldn't need to set the Last-Modified. The JSF resource handler already does that automatically. If you'd like to force reloading by resources because you changed them, then use resource library versioning. See also What is the JSF resource library for and how should it be used?
Note that changing it everytime the server restarts makes no sense as the Expires header would still keep telling the browser to re-test the validity of the cache after a certain period only. Until the browser actually requests the resource, the browser would never notice the change in the Last-Modified of a resource. The only thing which forces the browser hard to re-request the resource fully is a change in the URL, usually achieved by a changed query string parameter value. The JSF resource library versioning does exactly that.
Also note that the OmniFaces CombinedResourceHandler uses the resource's last modified timestamp as "resource version" in the query string instead of the resource library version. So if you're using that, you don't necessarily need resource library versioning mechanism.
The link above seems to suggest you need to specify Expires or Cache-Control. Why is that necessary?
The Expires header tells the browser when to re-test the validity of the cached resource by a conditional GET request. So, until that time the browser won't do that and will keep using the one in the cache. The Cache-Control tells the browser which caching strategy to use. Note that when it's set to e.g. no-cache instead of public, then the Expires header would have no effect. Also note that the absence of Cache-Control header implies public (as done by JSF resources).
这篇关于JSF 缓存静态资源过滤器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
