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 <[email protected]>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 > > -- > Arthur Richards > Software Engineer, Mobile > [[User:Awjrichards]] > IRC: awjr > +1-415-839-6885 x6687 > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
