tomcat security-constraint impact cache

家住魔仙堡 提交于 2019-12-01 03:20:37

According to the Oracle Java EE 6 tutorial, specifying a user-data-constraint of "CONFIDENTIAL" is to be used

when the application requires that data be transmitted so as to prevent other entities from observing the contents of the transmission.

For HTTP responses, that would mean ensuring that no proxies/caches along the way, from the server back to the client, would be able to cache that response and provide to any other requesting client. Thus the use of:

Cache-Control: private

While you might be tempted to use "INTEGRAL" instead of "CONFIDENTIAL", the same tutorial points out that many Java EE servers treat these two values identically.

If your application needs to allow caching, I suspect that you would need to remove the <user-data-constraint> element from your web.xml file.

Hope this helps!

So I'm wondering how should I configure tomcat application to have automatic SSL redirect, but with preserved caching of static resources? I mean the application going completely through SSL, along with with static resources that should be cached.

It seems that after setting <url-pattern>/*</url-pattern> or even <url-pattern>/</url-pattern> I cannot declare different url-pattern with transport-guarantee NONE. Everything started from my root URL has now Cache-Control: private anyway.

But I found the solution, working at least in Tomcat 7.0.55. These headers are fortunately set before the whole request is processed, so you can catch them on very first application filter. When you will reset the response here, you can setup your own headers and overwrite existing:

@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
    response.reset();
    chain.doFilter(request, response);
}

Then you can configure for example tomcat ExpiresFilter as the second filter, and here you can configure your own caching setup.

Posting another answer here since I find response.reset() is a bit too much because it essentially wipes the response and all other headers that may have been set.

Just extend isEligibleToExpirationHeaderGeneration and return true.

As it just happens the previous expires headers set by ROOT web.xml are not yet commited so it is a matter of overriding a certain behavior from catalina's Expires Filter. You can use your MyExpiresFilter exactly as ExpiresFiltersince it extends it.
public class MyExpiresFilter extends org.apache.catalina.filters.ExpiresFilter { @Override protected boolean isEligibleToExpirationHeaderGeneration( HttpServletRequest request, XHttpServletResponse response) { return true; } }

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!