-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Platonides wrote:
DanTMan wrote:
That's not what I'm talking about. Disable caching on the frontend caching device when the user is logged in. Your frontend cache is basically the same as Squid and Varnish. You have to disable them for users because those kind of caches can never cache user data right. I believe Wikimedia does this by having the frontend cache check for the user cookie.
It's stated on the Vary: header Vary: Accept-Encoding,Cookie
Note though that by default, just about everything's going to be marked as *private* in the Cache-Control header. This means that a shared cache like your proxy server shouldn't cache *anything*.
To mark output as cachable by an intermediate proxy cache, you need to delve into the terror that is $wgUseSquid... in which case your system needs to be set up to send notifications to the proxy cache to clear cached pages when they change.
This isn't very well documented... but I see there's some notes at: http://meta.wikimedia.org/wiki/Squid_caching
Furthermore, the exact cookies are statet at X-Vary-Options: but i think few caching devices would understand it.
X-Vary-Options is for our customized version of Squid, to tell it that it's ok to combine or ignore certain values of certain headers that we specify in Vary. In our case:
* It's told to ignore any cookies other than the ones our servers use for session and auth data -- this allows JavaScript tools to use cookies for their settings without disrupting the HTTP caching
* It's told to only pay attention to 'gzip' in Accept-Encoding, since that's the only non-plain encoding option we offer. This allows us to combine cached output for browsers which add various different things to that list which we ignore anyway.
This will have no effect on other system which don't know X-Vary-Options; they'll just fail to cache a few things.
- -- brion vibber (brion @ wikimedia.org)