Last modified: 2014-03-14 14:13:33 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 31639 - MediaWiki should use ETags instead of Last-Modified and the Logged out cookie hack
MediaWiki should use ETags instead of Last-Modified and the Logged out cookie...
Status: NEW
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on: 47529
Blocks: 32364
  Show dependency treegraph
Reported: 2011-10-12 05:20 UTC by Daniel Friesen
Modified: 2014-03-14 14:13 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Daniel Friesen 2011-10-12 05:20:58 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 ;).
Comment 1 Brion Vibber 2011-10-13 16:31:20 UTC
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'.
Comment 2 Daniel Friesen 2011-10-13 16:56:39 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.