On 17/08/18 14:57, Christopher Schultz wrote: > Mark, > > On 8/17/18 4:09 AM, Mark Thomas wrote: >> 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. > > Expires: 1970 certainly effectively disables browsed caching.
My understanding was that the browser caches the resource but marks it as stale which means it needs validation on the next request. >> 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. > > I'm curious, too: I can understand the "Cache-Control" header, but why > the "Expires" one? What about some CSS file that can surely be cached > by the browser? Looks like an HTTP/1.0 solution from a very short amount of research. Revalidation for a static file shouldn't be too expensive. > Is it possible for a servlet to override a single header -- say, the > "Expires" header? It might be nice to have a facility to allow > applications to override maybe just this one header (or, optionally, > just one *other* header). I glossed-over the servlet spec and I don't > see much in the way of proscriptions for precisely how to handle > security-constraints e.g. when it comes to setting headers. It depends when the header is added. In this case the Authenticator adds them before the filter chain is invoked so it should be possible for an application to remove them. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
