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
