Re: [Zope-CMF] Re: [Warning] Danger from Zope caching, especially the CMF Caching Policy Manager
Miles Waller wrote at 2006-12-18 12:57 +:
> ...
>At the moment, the CPM fires after rendering, so setting it's own
>headers and overwriting any headers set in the template. If it fired
>before rendering, then a template would be free to set whatever policy
>it wanted.
>
>Is there a special reason why it needs to set the headers after
>rendering, rather than before? I can't think of a reason, but then our
>policies are about as simple as can be.
I expect this was to counter the effect that "recursively" called
templates could trigger the CPM as well. If the CPM is activated
before the actual rendering, then these "recursive" activations
would override the effect of the "top" activation.
The latest CMF version tries to detect "recursive" activations
and suppress them. Nevertheless, your proposal would not be
safe, as shown this this example:
You have a script "someScript" with the following body
container.REQUEST.response.setHeader('Cache-Control', 'no-cache')
...
context.someTemplate(...)
then the call to "someTemplate" may override the "Cache-Control"
set before, even with your proposal.
Of course, the script could set the header after the template call --
*IF* it were aware of the danger. However, I doubt that this will be the
case
--
Dieter
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [Warning] Danger from Zope caching, especially the CMF Caching Policy Manager
Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17 Dec 2006, at 18:52, Dieter Maurer wrote: 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. I don't know if it is possible to have any sane policy about "what to do if the response already has caching headers". First of all, when should this exception policy trigger? Which headers should tell the CPM that someone else already decided on caching? Secondly, what is the behavior supposed to be? "Do nothing"? "DWIM"? This obviously needs exact specifications and use cases. At the moment, the CPM fires after rendering, so setting it's own headers and overwriting any headers set in the template. If it fired before rendering, then a template would be free to set whatever policy it wanted. Is there a special reason why it needs to set the headers after rendering, rather than before? I can't think of a reason, but then our policies are about as simple as can be. Miles ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
