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)