-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 8/17/18 11:49 AM, Mark Thomas wrote: > 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. That's essentially the same thing. The server can still return a 304 response if the browser thinks it has an up-to-date copy, but it's still a round-trip to the server that might be avoided. >>> 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. That's very good to know. There are very few headers that Tomcat automatically adds (at any stage). Could those be described somewhere including when/where they are added and whether they can be overridden? For example, I tried (and failed) to override the "Date" response header at some point while testing my "replay response" sample code. It might be nice to know that Tomcat adds (overwrites) that header fairly late in the process. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlt3EskACgkQHPApP6U8 pFg9TQ/9E2lLXq8ZjBBU1bMvd66jHJ4RgruQYG3sViaTA6xkk0zF1YWmAH0fquZV Xnid0102FteOZ7uqsMvzIRNywvnuL6S1nq9ItIvBMIQofZZnTnu275Xetq6smOHR j+o51S1sq5WwFP1ypijnYwT1KHmc1eQ9XwubsxmWgxVw33nJNhfsLr2BWMs9xWsT lG+iHA1ArIxRjx/oTtjuZAXgyH2PsB5T91huOmrzeR9uXbXfUGj+/qCoS33KcMyq +qQT/iDFH/z6i0g50a95fl6dLb3Tizmpwk7xikhd4eZ+D05qJEQAH0Vnyff8a/NA leHjeouGgo0ZaSBGWByYDZno1q34QkwOUfv6UGaHD0fw21yGsxWt1mfo6jedHNQ3 ZhXbEQMhM8uYIHYuKAaMcXSEbOvMkd7SsoqZGRzK6t1HptgtGN6NyRQA9U6hLT8I 5eGad3Bdx2nbnR7KDqcizJZ/Ulx5Be6XIQE4pncf2OLgfB6H3EkJ8FUkeU74i6W5 se0z9vECh7zBxEAaCm0u7bVH1NK5zZKcOgPxzFvtHrkj7bnpBXcN9Qm6G1OkEfjG d7rxnQtzG/d38YL0LQy3VsMp+q0Va9sRSztKpmmSU+se2904R/mj4ITz3M7e6VTE 1+LhS4WSf4yriC7qmShd5d/CzDW3Pvz0S0uyoV5MduQWtBbnDbQ= =8Svp -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
