Andrew Sawyers wrote:
I'm willing to eat a little crow on this one. I blame it on being on a lap
top on prone to mucho interruptions (excuse mode off). The condition for
this was actually more then the response I originally thought. When a
unauthorized page is accessed on zope.org - you get a 302 to a require_login
script, which in turn does a 302 to the login form. The below was the
response from the final redirect - not the initial one! The initial
redirect actually has a cache hit....thus the problem was obvious. The page
which generated the intial redirect was a file system skin, which is cache
policy manager aware - and thus was getting the default policy applied. As
of now, zope.org caches nothing explicity in the cache policy manager EXCEPT
for .css and .js files. The squid servers explicitly are configured to NOT
cache pages rendered by zope which do not have explicit cache headers
already set. So, any further weird caching should be traceable to the
various ram caches and/or httpd accelerated caches in the zope.org site and
not attributable to the framework cache policy or squid itself.
We are caching the release files themselves. I hope.
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope-web maillist - Zopeemail@example.com