12 messages in org.apache.tomcat.usersRE: Cache-Control headers not being a...| From | Sent On | Attachments |
|---|---|---|
| Zampani, Michael | Aug 16, 2011 1:42 pm | |
| Christopher Schultz | Aug 16, 2011 1:57 pm | |
| Richard Frovarp | Aug 16, 2011 2:01 pm | |
| Zampani, Michael | Aug 16, 2011 2:20 pm | |
| Mark Thomas | Aug 17, 2011 12:33 am | |
| Zampani, Michael | Aug 22, 2011 2:38 pm | |
| Christopher Schultz | Aug 23, 2011 6:47 am | |
| Zampani, Michael | Aug 23, 2011 11:08 am | |
| Christopher Schultz | Aug 23, 2011 12:10 pm | |
| Mark Thomas | Aug 23, 2011 12:48 pm | |
| Zampani, Michael | Aug 23, 2011 1:39 pm | |
| Mark Thomas | Aug 23, 2011 1:43 pm |
| Subject: | RE: Cache-Control headers not being added to secure requests | |
|---|---|---|
| From: | Zampani, Michael (zamp...@amazon.com) | |
| Date: | Aug 22, 2011 2:38:47 pm | |
| List: | org.apache.tomcat.users | |
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:mar...@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