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(a)wikimedia.org>wrote;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
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l