Crosspost: 'Reply-To' set to 'zope-cmf'. We nearly escaped a catastrophy: a page with sensitive personal information ended in a shared cache and was delivered to arbitrary people. This happened despite the fact that the template generating the page contained a "response.setHeader('Cache-Control', 'no-cache')" (and related headers for non HTTP/1.1 clients). The analysis quickly revealed broken design in the CMF Caching Policy Manager (CPM) as the cause: * it has applied its general policy depite the fact that the template itself has provided more adequate decisions with respect to caching * the caching policy manager action affects the complete response. Therefore, only the top level object, the object that controls the response content, should influence the CPM decisions. In the concrete case, the primary template did not trigger the CPM but the call of a secondary template responsible only for a tiny part of the response. The same problem also affects Zope's HTMLCacheManager. The description indicates in what direction the CPM should get fixed: * If the response already provides cache control, the CPM should not override it, as it is likely that the specific information available to the response generating process is more trustworthy then the general CPM policies. This is arguable, especially as it changes the current behaviour. Maybe, it should be controlled by an additional configuration option. * The CPM (and Zope's HTTP Cache Manager) must set cache headers only based on the object that generated the (complete) response entity and not based on other objects called during the request (and probably only responsible for part of the entity). -- Dieter