On 12 Jan 2006, at 00:39, Brian Sullivan wrote:
I will not do what you expect to do. The first cookie crumbler to do
authentication sets the cookie and even if other cookie crumblers get
involved they will not just overwrite that cookie because the
lifetime setting on their cookie is different.
In some testing I found that the headers (at least the upstream cache
setting which is what I was interested in) does seem to be different
depending on the first CookieCrumbler to handle the content (I set one
in a subdirectory to cache setting 'public' and the main system level
one to 'private')- which would seem to imply that higher placed ones
recognize the cache header setting and avoid changing it? This seemed
to do what I want.
If this isn't a strategy for doing what I want to do can anybody
thing of one?
I have a site that is authenticated using CookieCrumbler. I have a
whole bunch of static files/objects, some fairly large isolated in a
subfolder on the site. I want the static objects to be cached by
upstream proxies, but all other parts of the site not cacheable.
I don't know what you're talking about, the CookieCrumbler has
*nothing* to do with caching at all. Are you confusing tools here?
Could it be you're talking about the CachingPolicyManager?
By the way, the CookieCrumbler doesn't "authenticate", either. It
just makes cookie data look like regular basic auth headers so that a
real user folder can use that data.
jens
_______________________________________________
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
