tomcat security-constraint impact cache

|▌冷眼眸甩不掉的悲伤 提交于 2019-12-30 08:08:44

问题


I have a problem in caching my application.

when this code is added to web.xml of tomcat :

<security-constraint>
    <web-resource-collection>
        <web-resource-name>HTTPSOnly</web-resource-name>
        <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>

I get this response :


Cache-Control   private
Date    Tue, 18 Feb 2014 01:18:17 GMT
Etag    W/"200-1391558564593"
Expires Thu, 01 Jan 1970 00:00:00 WET
Server  Apache-Coyote/1.1

Without this code everything is fine :

Accept-Ranges   bytes
Cache-Control   max-age=604800
Content-Length  1496
Content-Type    text/css
Date    Tue, 18 Feb 2014 01:21:26 GMT
Etag    W/"1496-1391558561359"
Expires Tue, 25 Feb 2014 01:21:27 GMT
Last-Modified   Wed, 05 Feb 2014 00:02:41 GMT
Server  Apache-Coyote/1.1

Anyone can tell what cause the problem? and why this code change the cache-controle to private of my application. thanks a lot

Tomcat 7.0
JDK : 1.6

回答1:


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!




回答2:


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.




回答3:


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; } }



来源:https://stackoverflow.com/questions/21829553/tomcat-security-constraint-impact-cache

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