Per bug 35842, I've overhauled the persistent cookie handling in the MobileFrontend extension. I think my changes will work fine on the WMF architecture where most of our sites have a separate domain for their mobile version. However, for sites that use a shared domain for both desktop and mobile views, there is major browser caching-related weirdness that I have not been able to figure out. Details can be found in the bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=35842
A little more context about the issue: we need to be able to allow people to switch between desktop/mobile views. We're currently doing this by setting a cookie when the user elects to switch their view, in order to keep that view persistent across requests. On the WMF architecture, we do some funky stuff at the proxy layer for routing requests, depending on detected device type and whether or not certain cookies are set for the user. Generally speaking the sites hosted on our cluster have a separate domain set up for their mobile versions, even though they're powered by the same backend. This makes view switching a bit easier, although I think the long-term hope is to get rid of mobile-specific domains. For sites that do not have a separate domain set up, we rely solely on cookies to handle user-selected view toggling. This seemed to generally work OK with the way we were previously handling these 'persistent cookies', but the previous way of cookie handling has been causing caching problems on our cluster. The changes I've introduced to hopefully resolve those issues result in browser-caching issues on single-domain sites using MobileFrontend, where after toggling the view and browsing to a page that was earlier viewed in the previous context, you might see a cached copy of the page from the previous context. No good.
I'm stumped and am at a point where it's hard to see the forest through the trees. I could use some help to deal with this - if anyone has any insight or suggestions, I'm all ears!
Thanks, Arthur
On Thu, 12 Apr 2012 12:18:21 -0700, Arthur Richards arichards@wikimedia.org wrote:
Per bug 35842, I've overhauled the persistent cookie handling in the MobileFrontend extension. I think my changes will work fine on the WMF architecture where most of our sites have a separate domain for their mobile version. However, for sites that use a shared domain for both desktop and mobile views, there is major browser caching-related weirdness that I have not been able to figure out. Details can be found in the bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=35842
A little more context about the issue: we need to be able to allow people to switch between desktop/mobile views. We're currently doing this by setting a cookie when the user elects to switch their view, in order to keep that view persistent across requests. On the WMF architecture, we do some funky stuff at the proxy layer for routing requests, depending on detected device type and whether or not certain cookies are set for the user. Generally speaking the sites hosted on our cluster have a separate domain set up for their mobile versions, even though they're powered by the same backend. This makes view switching a bit easier, although I think the long-term hope is to get rid of mobile-specific domains. For sites that do not have a separate domain set up, we rely solely on cookies to handle user-selected view toggling. This seemed to generally work OK with the way we were previously handling these 'persistent cookies', but the previous way of cookie handling has been causing caching problems on our cluster. The changes I've introduced to hopefully resolve those issues result in browser-caching issues on single-domain sites using MobileFrontend, where after toggling the view and browsing to a page that was earlier viewed in the previous context, you might see a cached copy of the page from the previous context. No good.
I'm stumped and am at a point where it's hard to see the forest through the trees. I could use some help to deal with this - if anyone has any insight or suggestions, I'm all ears!
Thanks, Arthur
Might this be a browser caching issue, not a server caching issue?
Sounds like even more reason to do away with our logout cookie hacks and get proper ETags working.
As a temporary hack you could try updating the *_LoggedOut cookie when you change the view cookie to invalidate previous cached pages.
On Thu, Apr 12, 2012 at 12:43 PM, Daniel Friesen lists@nadir-seen-fire.comwrote:
Might this be a browser caching issue, not a server caching issue?
Yeah, I believe so.
As a temporary hack you could try updating the *_LoggedOut cookie when you change the view cookie to invalidate previous cached pages.
Intriguing - I'm unfamiliar with the logged out cookie hacks. Can you point me to an example? Would/does this actually have any affect on browser caches?
Thanks!
On Thu, 12 Apr 2012 12:54:41 -0700, Arthur Richards arichards@wikimedia.org wrote:
On Thu, Apr 12, 2012 at 12:43 PM, Daniel Friesen lists@nadir-seen-fire.comwrote:
Might this be a browser caching issue, not a server caching issue?
Yeah, I believe so.
As a temporary hack you could try updating the *_LoggedOut cookie when you change the view cookie to invalidate previous cached pages.
Intriguing - I'm unfamiliar with the logged out cookie hacks. Can you point me to an example? Would/does this actually have any affect on browser caches?
Thanks!
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=includes... https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=includes... https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=includes...
Basically we set a *_LoggedOut cookie when you log out of the wiki. That cookie includes the timestamp at which you logged out. And Last-Modified headers contain the current time. So when you visit a page after logging out MW looks at your If-Modified-Since timestamp, the page's timestamp, and your logged out cookie. If the If-Modified-Since is earlier than the time in your LoggedOut cookie MW will serve a new page with a new If-Modified-Since; Assuming that the page in your cache was cached when you were logged in and needs to be purged.
Of course this is a complete hack. It forces one lane of cache when a browser could be capable of keeping the anon cache around for when the logged in user logs back out. (I wish for the possibility of user caches that persist between logins -- re-login, or user switching -- but we update user_touched when you merely login) It forces us to purge anon cached pages to replace them with the same anon cached page (Visit <X> as anon, log in, visit <Y>, log out, visit <X> again; You should get a 200 instead of a 304 even though <X> should be the same anon page you visited before). And of course it falls apart when you 'log out' by letting cookies expire / purging them.
Relevant bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=31639
Although I believe there are some more recent revelations on the topic left in IRC logs that didn't make it into there.
MW needs full etag support, with hooks for extensions. Without it, we can't widely support caching in the case you've outlined.
Different browsers handle the Vary header differently. Some treat Varies as "don't cache." Chrome (possibly other webkit browsers) treats it as a marker to revalidate whatever varient is cached. It sends an If-Modified-Since and if there's an etag, If-None-Match header.
If MediaWiki provided etags, calculated them differently based on login status, mobilefrontend, etc., and used them for If-None-Match requests, we could handle browser caching sanely. The LoggedOut cookie behavior that Daniel described could provide a less than ideal workaround if set with an updated timestamp on each view switch but I'd rather not see this exploited further. It breaks squid caching in our setup which lessens the user experience.
On Thu, Apr 12, 2012 at 12:18 PM, Arthur Richards arichards@wikimedia.orgwrote:
Per bug 35842, I've overhauled the persistent cookie handling in the MobileFrontend extension. I think my changes will work fine on the WMF architecture where most of our sites have a separate domain for their mobile version. However, for sites that use a shared domain for both desktop and mobile views, there is major browser caching-related weirdness that I have not been able to figure out. Details can be found in the bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=35842
A little more context about the issue: we need to be able to allow people to switch between desktop/mobile views. We're currently doing this by setting a cookie when the user elects to switch their view, in order to keep that view persistent across requests. On the WMF architecture, we do some funky stuff at the proxy layer for routing requests, depending on detected device type and whether or not certain cookies are set for the user. Generally speaking the sites hosted on our cluster have a separate domain set up for their mobile versions, even though they're powered by the same backend. This makes view switching a bit easier, although I think the long-term hope is to get rid of mobile-specific domains. For sites that do not have a separate domain set up, we rely solely on cookies to handle user-selected view toggling. This seemed to generally work OK with the way we were previously handling these 'persistent cookies', but the previous way of cookie handling has been causing caching problems on our cluster. The changes I've introduced to hopefully resolve those issues result in browser-caching issues on single-domain sites using MobileFrontend, where after toggling the view and browsing to a page that was earlier viewed in the previous context, you might see a cached copy of the page from the previous context. No good.
I'm stumped and am at a point where it's hard to see the forest through the trees. I could use some help to deal with this - if anyone has any insight or suggestions, I'm all ears!
Thanks, Arthur
-- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org