Last modified: 2014-02-12 23:45:52 UTC
The presence of a "useformat=desktop" cookie disables squid caching for the regular site. I think this has to do with the way X-V-O is implemented. And if caching became possible when that cookie set, it would be varied upon and we'd have to cache two desktop-format copies of every page (with useformat=desktop and without.) Instead of setting useformat=desktop, delete the cookie when switching to the desktop view. Then, a cookie that isn't used for varying needs to be set that's just used for disabling the squid level mobile redirector, so set the old stopMobileRedirect=true cookie at the same time. It's still in the squid config so this can be fixed without ops involvement.
Fix for this: https://gerrit.wikimedia.org/r/#change,4761
The fix I created seems to work fine for sites that use MobileFrontend on a domain separate from their desktop site (like we do for most sites on the WMF cluster). However, for single-domain sites, there are still issues around browser caching that I have not yet been able to sort out. Some browsers seem to handle the view switching with the cookies just fine (FF on OS X, IE 9 on Vista), but other browsers (Safari [iOS, OS X], Chrome [OS X], Android native browser, Dolphin HD) do not. When you toggle your view preference in these browsers and then surf to a page that had been viewed recently in the previous view, you will likely see a cached copy of the wrong version of the page. In Chrome, this often seems to happen when the browser requests a resource but gets an HTTP 304 status back. Safari, on the other hand, seems to display this behavior even with HTTP 200 status. An easy way out of this predicament is to simply say that sites using MF will need to set up a separate mobile domain until we figure out mobile-specific paths in the URLs. Otherwise, I'm totally stumped and not sure how to resolve this issue - any help is greatly appreciated. (In reply to comment #1) > Fix for this: > https://gerrit.wikimedia.org/r/#change,4761
Asher, since the cookie handling changes have been deployed, are we still experiencing the issue you brought up here with frontend caching?
bump
Closing due to lack of activity.
There are still issues that result in the mobile cache hitrate being considerably less than squids, but they are fundamental to the way we currently have to vary on so many factors in mobile. Patrick has discussed utilizing ESI to eliminate all of the various per-device and service (zero per-carrier) variances, and that would fix it. If Patrick doesn't have time to implement ESI before transitioning off the mobile team, someone else should pick this up.
I'll reopen then. Who would be suitable to pick this up?
Get Arthur to put this into our backlog and we can prioritize it.
I've put this in the backlog to get fleshed out. Please can someone flesh out this story to clearly articulate the outcomes: https://mingle.corp.wikimedia.org/projects/wlm_android_app/cards/237 I'm not sure bugzilla is the right place for this as it's not 100% clear currently how this should be done and what the outcomes should be.
I'm closing this issue since the orignal posted problem has been resolved. Improving the mobile cache hit rate is a separate from 'breaking frontend caching', and is already actively being worked on as an enhancement: https://mingle.corp.wikimedia.org/projects/mobile/cards/446
