Do we know how much of a burden it will be to vary the cache based on the user-agent? That seems like it would be a whole lot more cache objects and cache MISS, but this may not be a problem.

In T214998#5029596, @dbarratt wrote:

Do we know how much of a burden it will be to vary the cache based on the user-agent?

Yes, impact would be none as we already do this.

Desktop and mobile domains both have their page views cached in Varnish (with different output each), and the canonical desktop url varies by user agent to power the redirect we see today (cache/response variance). Note that MediaWiki never sees the m-dot domain. The caching and internal traffic always operates on the canonical domain, using the internal header to distinguish mobile mode.

Our Varnish logic today (simplified)

• Internally rewrite the Host name to strip m. from domain name.
• If original Host "en.m.wikipedia.org"
  • Set IsMobile to true for MobileFrontend.
  • Fetch from Apache backend (cached under "en.wikipedia.org" + IsMobile + Path).
• Request for Host "en.wikipedia.org"
  • If the user-agent matches a mobile user agent, then redirect to the same path+query on "(sub).m.(project.suffix)". This is an internal redirect from the Varnish VCL code at the edge.
  • Else, fetch from Apache backend (cached under "en.wikipedia.org" + IsMobile + Path).

What our Varnish logic could be (simplified):

• Internally rewrite the Host name to strip any m. from domain name.
• Request for Host "en.wikipedia.org"
  • If the user-agent matches a mobile user agent, then set IsMobile to true for MobileFrontend.
  • Fetch from Apache backend (cached under "en.wikipedia.org" + IsMobile + Path).

Impact

• Simpler VCL code.
• Same amount of cache objects.
• Fewer Varnish responses (fewer redirects, right now a canonical url opened on mobile is always 2 requests and 2 responses instead of 1).
• Better performance for end-users on mobile, by no longer requiring 2 full network roundtrips for them when they open a "wrong" url.

@tstarling, this problem:

The m. subdomain, as in en.m.wikipedia.org, is annoying. Links shared on social media are randomly mobile or non-mobile, and so desktop users often accidentally visit the mobile site.

can be easily resolved by detecting desktop/mobile client by User-Agent and 302 redirecting by default desktop clients from mobile version of site to desktop version of site. Now exists redirection only from desktop version to mobile version of site for mobile clients (detected by User-Agent).

I have standalone wiki based on MediaWiki engine and already create such logic using nginx web server and njs script. If you or someone else interested - I can share my njs code and nginx wiki config at github.

main idea of my code looks like this:

// ...
var arg_mobileaction = r.args.mobileaction;
var redirect_host;
if (arg_mobileaction === 'toggle_view_desktop') {
    redirect_host = desktop_host;
} else if( arg_mobileaction === 'toggle_view_mobile' ) {
    redirect_host = mobile_host;
} else {
    redirect_host = host;
}

var mobile_browser = is_mobile_browser(r.variables.http_user_agent);
var desktop_browser = !mobile_browser;
var cookie_stopMobileRedirect = r.variables.cookie_stopMobileRedirect;
var cookie_stopDesktopRedirect = r.variables.cookie_stopDesktopRedirect;

if (mobile_browser && arg_mobileaction !== 'toggle_view_desktop' && cookie_stopMobileRedirect !== 'true') {
    redirect_host = mobile_host;
}
if (desktop_browser && arg_mobileaction !== 'toggle_view_mobile' && cookie_stopDesktopRedirect !== 'true') {
    redirect_host = desktop_host;
}

// set $stop_redirect_cookie

if (mobile_browser && arg_mobileaction === 'toggle_view_desktop') {
    r.variables.stop_redirect_cookie = ['stopMobileRedirect=true', 'domain=' + wildcard_host(r), 'path=/', 'Max-Age=86400', 'HttpOnly', ''].join(';')
} else if (desktop_browser && arg_mobileaction === 'toggle_view_mobile') {
    r.variables.stop_redirect_cookie = ['stopDesktopRedirect=true', 'domain=' + wildcard_host(r), 'path=/', 'Max-Age=86400', 'HttpOnly', ''].join(';')
} else {
    r.variables.stop_redirect_cookie = '';
}
// ...

this allow by default redirect users to proper version of site, bit also this allow users to manually switch between desktop and mobile versions in any time.

I suppose what such simple logic can be also implemented using varnish.

Having separate domains complicates analytics and search engine optimisation.

Search engines already know about mobile and desktop versions of wikipedia and understand difference.

See https://developers.google.com/search/mobile-sites/mobile-seo/separate-urls for details.

The m. subdomain does not appear to reflect best current practice. Many websites are able to detect mobile clients and deliver the correct variant through an unmodified URL. For example, WikiTravel does this, using CloudFront and MediaWiki/MobileFrontend.

You are talking about https://wikitravel.org/en/Main_Page site?

Looks like this site is broken. I set mobile user agent, but this site still display me desktop version.

Also I don't see any ability to change from desktop to mobile site or from mobile site to desktop site manually.

I propose removing the m. subdomain. The frontend would detect the desired device variant based on UA and request cookies, and send it to MediaWiki in a single header, and would vary the resulting cache based on this request header. MediaWiki (MobileFrontend, or core after T100402 is fixed) would use this request header to select the skin.

If I use desktop browser - how I can manually switch to mobile version of site, is it possible after implementing your proposal?

Also, If I use mobile browser - how I can manually switch to desktop version of site, is it possible after implementing your proposal?

If answer is "No" - removing m. subdomain is bad idea, from my point of view.

Re: Wikitravel: Don't compare their custom HTML homepage in English. Compare (e.g.) https://wikitravel.org/wiki/en/index.php?title=Western_Sahara and https://wikitravel.org/wiki/en/index.php?title=Western_Sahara&mobileaction=toggle_view_mobile, which does work.

@Koavf, ok I see, it work. But WikiTravel don't allow me to browse mobile version of site if I have desktop browser and WikiTravel don't allow me to browse desktop version of site if I use mobile browser.

It permanently show mobile version for mobile users and desktop version for desktop users, and don't remember user choice. This is bug or feature?

For example, even if I manually switch to mobile version of page - https://wikitravel.org/wiki/en/index.php?title=Western_Sahara&mobileaction=toggle_view_mobile - all links on this page, for example https://wikitravel.org/en/North_Africa show me desktop version.

Sounds like a bug.

In T214998#5298484, @DIKW_Pyramid wrote:

If I use desktop browser - how I can manually switch to mobile version of site, is it possible after implementing your proposal?

Also, If I use mobile browser - how I can manually switch to desktop version of site, is it possible after implementing your proposal?

Yes, you will still be able to do this, and it will work the same way as today. Nothing is changing about this.

In T214998#5298484, @DIKW_Pyramid wrote:

Links shared on social media are randomly mobile or non-mobile, and so desktop users often accidentally visit the mobile site.

can be easily resolved by detecting desktop/mobile client by User-Agent and 302 redirecting by default desktop clients from mobile version of site to desktop version of site. [..]

Serving 50% of our social-traffic (or more) with redirects is not an acceptable resolution from a performance perspective.

handle (cookies and mode-switch logic) {
  …
}

if (domain is normal) {
  if (isMobileUserAgent) {
    exit (redirect to mobile domain);
    # user gets redirected...
    # browser makes new URL request over network ...
    # browser URL request arrives in our data centre, and we start another instance of this cache proxy logic ...
  }
}

if (domain is mobile) {
  exit (route to MediaWiki with MobileFrontend=on);
} else {
  exit (route to MediaWiki with MobileFrontend=off);
}

handle (cookies and mode-switch logic) {
  …
}

if (isMobileUserAgent) {
  exit (route to MediaWiki with MobileFrontend=on);
} else {
  exit (route to MediaWiki with MobileFrontend=off);
}

See also T214998#5038999. Basically:

• Better performance for our mobile users, by no longer forcing redirects for many of their page views.
• Better UX for our desktop users, by no longer serving the mobile site when they do not expect this (random switches based on sharer's url).
• Nothing else changes for users.

In T214998#5300227, @Krinkle wrote:

In T214998#5298484, @DIKW_Pyramid wrote:

If I use desktop browser - how I can manually switch to mobile version of site, is it possible after implementing your proposal? Also, If I use mobile browser - how I can manually switch to desktop version of site, is it possible after implementing your proposal?

Yes, you will still be able to do this, and it will work the same way as today. Nothing is changing about this.

This proposal already implemented on WikiTravel site, but browsing mobile version of site is not possible using browser with desktop User-Agent, and browsing desktop version of site is not possible using browser with mobile User-Agent. Manually user can switch mobile/desktop view only for each page, but globally, for entire site - can't:

In T214998#5298680, @DIKW_Pyramid wrote:

For example, even if I manually switch to mobile version of page - https://wikitravel.org/wiki/en/index.php?title=Western_Sahara&mobileaction=toggle_view_mobile - all links on this page, for example https://wikitravel.org/en/North_Africa show me desktop version.

If this is bug in WikiTravel configuration - probably this bug should be fixed before removing m. subdomain from all Wikipedia sites?

In T214998#5300227, @Krinkle wrote:

See also T214998#5038999.

As I understand, T214998#5038999 proposal forces mobile users to browse only mobile version of site and forces desktop users to browse only desktop version of site without ability to select which version of site user want to see and browse.

If mobile and desktop versions of site has the same uri - remembering user choice is only possible via cookies, something like this:

userPreferredVersion=mobile or userPreferredVersion=desktop and logic should be something like this:

# user choice has higher priority
if (cookie userPreferredVersion exists) {
  if (cookie userPreferredVersion === 'mobile') {
    exit (route to MediaWiki with MobileFrontend=on);
  }
  if (cookie userPreferredVersion === 'desktop') {
    exit (route to MediaWiki with MobileFrontend=off);
  }
}
# default fallback, if no userPreferredVersion cookie exists
# or if it value is not 'desktop' or 'mobile'
if (isMobileUserAgent) {
  exit (route to MediaWiki with MobileFrontend=on);
} else {
  exit (route to MediaWiki with MobileFrontend=off);
}

In T214998#5298484, @DIKW_Pyramid wrote:

In T214998#5300227, @Krinkle wrote:

[..] it will work the same way as today. Nothing is changing about this.

This proposal already implemented on WikiTravel site, but [..]. If this is bug in WikiTravel configuration - probably this bug should be fixed before removing m. subdomain from all Wikipedia sites?

WikiTravel have done something similar, but their architecture is quite different. It is not comparable. We do not have this bug currently on Wikipedia, and we will not introduce this bug as part of this change. You can rest assured it will keep working. The code for it already exists, it works fine today, and will continue to work. It will not change with this proposal.

Regarding your code suggestion, note that this Phabricator task is not a code review. We are not yet at the implementation stage. I simplified the code in my comment so that it can explain the impact to a wider audience. The actual Wikipedia configuration is in a different syntax and more complex. If and when the plan is accepted, the team implementing it will apply the changes as necessary. Then, you can review the code in the Gerrit.

Please do this. I come from an example of these .m. urls being obnoxious in the wild: https://www.reddit.com/r/wikipedia/comments/dwuli2/the_dionne_quintuplets_are_the_first_quintuplets/f7lktsv/

What does this mean for me as for a user who edits Wikimedia projects from mobile using desktop view for almost 9 years? Does it mean I would not be able to continue doing so and would have to stick to limited in functionality mobile view instead? (Well, in Firefox for Android there is also a "require desktop view" flag, but I am not sure if I can use this preference per web-site and thus it is an undesirable way).

It could be a good idea as long as there is a preference to opt out of mobile view for good for registered users and a long living cookie remembering the view used for anonymous users. Otherwise it sounds like a terrible idea.

In T214998#5863413, @Base wrote:

What does this mean for me as for a user who edits Wikimedia projects from mobile using desktop view for almost 9 years?

The proposal here is to provide the current mobile experience by default to visitors with detected mobile devices, and the current desktop experience to visitors with detected desktop devices, with the ability to switch experiences back and forth. Logged in users would continue to get the skin of their preference. However, it's too early to make commitments about exactly how this would work and what the experience would be, if we did this.

@Jdlrobson If I understand correctly, you're saying that it is considered a requirement that a user can still find an easy way into the mobile/minerva experience from a desktop browser and stay there when browsing around. In other words, what they can do today by manually going to en.m.wikipedia.org, which they presumably have stumbled upon by accident or figured out by reproducing the url they see on mobile.

Preserving this seems fair indeed. However, to what extent is this not already satisfied by the skin preference and/or the "Mobile view" footer link? The latter also works with a session-bound cookie for logged-out users. And the former is a sticky preference that works across devices for logged-in users.

This change would affect MobileFrontend and therefore make you an important stakeholder. However in terms of resourcing, this seems like it would mainly involve CDN and site configuration changes which CPT, SRE and Perf could handle I think. Are there changes required within MobileFrontend to make this change possible? If this is indeed not a priority for Readers Web currently, it'd be good to know roughly what work is expected to be needed in MobileFrontend.

Have been somewhat expecting this to be fixed for the better part of 7+ years now. Hopefully this can be implemented soon!

The swap of Traffic for Traffic-Icebox in this ticket's set of tags was based on a bulk action for all tickets that aren't are neither part of our current planned work nor clearly a recent, higher-priority emergent issue. This is simply one step in a larger task cleanup effort. Further triage of these tickets (and especially, organizing future potential project ideas from them into a new medium) will occur afterwards! For more detail, have a look at the extended explanation on the main page of Traffic-Icebox . Thank you!