Last modified: 2014-03-14 14:13:33 UTC
Right now MediaWiki supports browser caching of pages for both logged in and anonymous users through the Last-Modified header. MediaWiki uses a Loggedout cookie hack to prevent anons from being served a bad cache from when they were logged in. However there are a number of problems: - As a result of the logged out cookie, after you log out, for quite some time you are served 200 responses instead of proper 304's. In other words, even if you're capable of viewing a cache and your browser doesn't have a stale user cache in it you still won't get a cached page back. This means that logging in and then logging back out will make your wiki viewing potentially slower than being logged in. - As another result of the logged out cookie, even though you're an anon, you continue to bypass squid caches in most configurations and don't get the advantage of seeing the same efficiently cached pages as all the other anons. - And to top it off, the logged out cookie hack doesn't solve the issue in the other direction. You can view a page, get a Last-Modified header back, log in, go back to the page, and get a 304 that tells your browser to load it's cached page of you logged out instead of the proper one with your logged in interface. The only way to fix all these troubles is to drop the Logged out cookie hack and instead use ETags which include info about the user so that when a user logs out, logs in, has their talkpage edited (because we want notifications to be sent), changes ip (if they're an anon and their ip address is being shown in the header), etc... the ETag's contents will change. There's an interesting note about ETags. Browsers can send multiple ETags in their If-None-Match header. As a result a browser can actually have a logged out version and one (or maybe more) logged in versions of a page in their cache. If you view a page, log in, view it again, and log back out, when you go back to the page even though you viewed it with a different ETag and a different cached page, you could potentially end up getting a 304 because you still had a cached version for logged out users ;).
Sounds plausible... after a logout or session timeout (which the logout cookie doesn't currently handle), coming back will ask for the page with your last-seen logged-in etag... the caching proxies don't have it cached since it's set for local-only, so pass it on to the backend app servers. MediaWiki then checks the etag and sees that it doesn't match the user id now active in your session (if any), and kicks back an anonymous page, with the anonymous etag. Might need to distinguish between 'session but not logged in' and 'no session and not logged in'.
(In reply to comment #1) > Might need to distinguish between 'session but not logged in' and 'no session > and not logged in'. For anons we could include say the first 4 characters of an md5 of the session id in the ETag if there is a session.
