I've solved this by removing the <security-constraint> completely and doing a 301 redirect to https:// in nginx (which is in front of Tomcat) instead: https://nginx.org/en/docs/http/converting_rewrite_rules.html
Also added HTST header as suggested in this thread: https://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#HTTP_Header_Security_Filter On Fri, Aug 17, 2018 at 8:24 PM, Christopher Schultz <ch...@christopherschultz.net> wrote: > -----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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
