On 16/08/18 13:40, Martynas Jusevičius wrote: > Hi, > > my initial observations suggest, and SO post [1] seems to confirm, that when > > <user-data-constraint> > <transport-guarantee>CONFIDENTIAL</transport-guarantee> > </user-data-constraint> > > is specified on a security-constraint in web.xml, Tomcat does two things: > 1. automatically redirects to HTTPS > 2. appends Cache-Control: private and Expires: Thu, 01 Jan 1970 > 01:00:00 CET response headers > > Is that correct?
It is broader than that. Tomcat adds those headers to any resource that is protected by any security constraint. > I had added the CONFIDENTIAL because I want the redirect to HTTPS. > What I don't want is Tomcat overriding my caching headers and > effectively disabling browser caching. Those headers shouldn't disable browser caching. They will mean the client has to revalidate the request. How relatively expensive that is will depend on the resources. > Why in the world would those two things be conflated? Security. Any resource protected by a security constraint should not be stored in a shared cache else information disclosure could occur. > And how do I > disable this header override behavior? > > Does disableProxyCaching attribute need to be set to false to in order > to do that? [2] That would work. The consequence is that the application has to take responsibility for setting all of the caching headers - including those served by container servlets such as static resources and JSPs. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
