Thank you for the explanation.
However, I'm still confused about
> - {request.isSecure()} means that the headers are only added if the request
> is not secure since responses from secure requests must not be cached
I don't see anything regarding secure requests in RFC2616
http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.4
or RFC2818
http://www.ietf.org/rfc/rfc2818.txt
Also, since the code in question is limiting the cacheability of the response,
what is the downside of sending the no-cache header on secure requests?
I ask because we're seeing problems with IE8 caching these responses where it
previously did not when the headers were being automatically appended.
While it may be a client problem, it seems like the change that was removed was
made to work around a similar client problem.
Thanks,
Michael
-----Original Message-----
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Wednesday, August 17, 2011 12:34 AM
To: Tomcat Users List
Subject: Re: Cache-Control headers not being added to secure requests
On 16/08/2011 22:20, Zampani, Michael wrote:
> It was my understanding that the fix for IE was just the
> securePagesWithPragma change, which changes cache-control:no-cache to
> cache-control:private by default.
> According to the bug report, this should fix IE downloads even for secure
> requests.
> The problem is, this entire block is now ignored for secure requests, which
> results in no headers at all.
> Have I misunderstood something?
The current behaviour is as intended. The cache control headers are only added
when necessary. Working through each component of that if statement:
- {constraints != null} means that this test is only made if the requested
resource is protected by one or more security constraints (unprotected
resources may be cached, protected resources may not)
- {disableProxyCaching} checks to see if this feature is enabled (it is by
default). As per the docs, disabling this feature will trigger a security
problem
- {request.isSecure()} means that the headers are only added if the request is
not secure since responses from secure requests must not be cached
- {!"POST".equalsIgnoreCase(request.getMethod())} means that the headers are
only added if the request is not a POST since responses to POST requests must
not be cached
If you have a client or proxy that is caching responses for secure requests
then I would say that this is a client problem.
If you need those headers for some other reason (can't think what) a simple
filter that adds them for secure requests should only take a few minutes to
write.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
