Hi Martynas,
On 16.08.2018 14: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?
Without looking at the code, but with you stating this as an
observation, I'd say yes, there's a good chance for it to be correct
(well, you obviously observe it, and I can imagine it being on purpose)
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.
There's a better way to redirect to HTTPS, rather than using this
declaration. You can either do this in a servlet filter, proxy through
Apache httpd or similar (where you can redirect/rewrite), or just deny
tomcat to serve on port 80 anyways (just have a static redirect on port
80). Add a pinch of HSTS, and you're set.
If an application declares CONFIDENTIAL, it might not like the content
to be stored on any disc cache. Sending expired content will serve that
purpose beautifully. And you're asking for CONFIDENTIAL, not ENCRYPTED
(note: the ENCRYPTED declaration doesn't exist AFAIK)
Why in the world would those two things be conflated? And how do I
disable this header override behavior?
My best guess: Because one is not meant to be The Solution (TM) for the
other.
Does disableProxyCaching attribute need to be set to false to in order
to do that? [2]
I'm running the tomcat:8.0-jre8 on Docker.
Pardon the sneaky comment:
Why on earth would someone ask for security related features on a server
that has reached its end of life?
(this won't solve your problem, but static redirecting will)
I hope that helps,
Olaf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
