tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zampani, Michael" <zamp...@amazon.com>
Subject RE: Cache-Control headers not being added to secure requests
Date Mon, 22 Aug 2011 21:39:10 GMT
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:markt@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Mime
View raw message