Mailing List Archive: Wikipedia: Wikitech

MobileFrontend persistent cookie overhaul and caching weirdness

Index | Next | Previous | View Threaded

arichards at wikimedia

Apr 12, 2012, 12:18 PM

Post #1 of 5 (99 views)
Permalink

MobileFrontend persistent cookie overhaul and caching weirdness

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 [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

lists at nadir-seen-fire

Apr 12, 2012, 12:43 PM

Post #2 of 5 (92 views)
Permalink

Re: MobileFrontend persistent cookie overhaul and caching weirdness [In reply to]

On Thu, 12 Apr 2012 12:18:21 -0700, Arthur Richards
<arichards [at] wikimedia> 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.

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

arichards at wikimedia

Apr 12, 2012, 12:54 PM

Post #3 of 5 (86 views)
Permalink

Re: MobileFrontend persistent cookie overhaul and caching weirdness [In reply to]

On Thu, Apr 12, 2012 at 12:43 PM, Daniel Friesen
<lists [at] nadir-seen-fire>wrote:
>
>
> 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!

--
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

lists at nadir-seen-fire

Apr 13, 2012, 1:49 AM

Post #4 of 5 (89 views)
Permalink

Re: MobileFrontend persistent cookie overhaul and caching weirdness [In reply to]

On Thu, 12 Apr 2012 12:54:41 -0700, Arthur Richards
<arichards [at] wikimedia> wrote:

> On Thu, Apr 12, 2012 at 12:43 PM, Daniel Friesen
> <lists [at] nadir-seen-fire>wrote:
>>
>>
>> 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/Article.php;h=393f770bf79dafe3e6b05c608e738e77247696d4;hb=HEAD#l468
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=includes/OutputPage.php;h=beaca5f46f8e93e4eff6114675fb13a8de4796f1;hb=HEAD#l607
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=includes/User.php;h=af923ffeeb2b60e981109a1d34e6550dee3f23a7;hb=HEAD#l875

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.

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

afeldman at wikimedia

Apr 13, 2012, 6:50 AM

Post #5 of 5 (88 views)
Permalink

Re: MobileFrontend persistent cookie overhaul and caching weirdness [In reply to]

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 [at] wikimedia>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 [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads