On Jan 3, 2004, at 17:33, Gabriel Wicke wrote:
If the client sent an If-Modified-Since header, we compare the given time against the last-touched timestamp (which is updated for cases where link rendering would change as well as direct edits).
Ah- so this would be the point to hook in for downstream cache invalidation (PURGE requests). Great news, then the timeout for anonymous views could be really high on the squids, practically static serving. Reallly fast...
In theory, yeah, that should rock. :)
Squid would cache both the compressed and the decompressed page- Vary: Accept-Encoding, Cookie does this. It will most propably cache two or three variants of the Accept-Encoding value (Browsers differ in what they advertise).
I seem to recall some trouble with Vary headers other than "Vary: User-Agent" and Internet Explorer. This can probably be worked around in some way, I hope.
What is the reason for sending a session cookie for anonymous users? User tracking? This collides with downstream caching (Vary: Cookie), so if this could be switched off the only issue would be solved.
There's no real good reason for it, just laziness. Session tracking isn't actually used outside of a login session, so it's just annoying for people who browse in with their browser set to prompt about cookies.
In theory, we should be able to switch on the session system only after either a) checking that a session cookie is present or b) establishing a login session on Special:Userlogin.
Note however that we want to be able to display talk page notifications to individual anonymous users, as well; currently this requires a hit to the server to check if the IP is marked. It may be sufficient to start up the cookie session on edit; most casual visitors may never get there, and talk notifications aren't too likely to happen to somebody who's not editing at the time.
-- brion vibber (brion @ pobox.com)