Page MenuHomePhabricator

HTTP URL to desktop website sometimes gives mobile website for stopMobileRedirect=true if you have enwikiforceHTTPS=true
Closed, DeclinedPublic

Description

Use a mobile web browser. I used "User-Agent: Opera/9.80 (Android; Opera Mini/7.5.33361/30.3793; U; sv) Presto/2.8.119 Version/11.10".

Steps to reproduce:

1: Delete all cookies.
2: Log in to Wikipedia. You should now see the mobile site as you are using a mobile web browser.
3: At the bottom of the page, click on the link to the desktop version.
4: Elsewhere on the Internet, find a link which points to Wikipedia's desktop HTTP edition, and click on the link. Alternatively, type in a URL yourself.

Actual result: The browser shows the mobile HTTPS edition of Wikipedia.
Expected result: The browser shows the desktop HTTPS edition of Wikipedia.

IMPORTANT: You must perform steps 2 and 3 in the order indicated above! If you perform them in the opposite order, then the result is different (due to bug 43771).

Explanation

Steps 2-3 should give you two cookies:

Set-Cookie: enwikiforceHTTPS=true; expires=Mon, 30-Sep-2013 23:24:04 GMT; path=/; httponly
Set-Cookie: stopMobileRedirect=true; expires=Mon, 30-Sep-2013 23:15:06 GMT; path=/; domain=.wikipedia.org; secure

When you request the Wikipedia article (say, http://en.wikipedia.org/wiki/A), the following happens:

  1. Browser sends "GET /wiki/A HTTP/1.1" to en.wikipedia.org. As the connection is insecure, the stopMobileRedirect=true cookie isn't sent, but enwikiforceHTTPS=true is sent:

Cookie: enwikiforceHTTPS=1

  1. Server detects a mobile user agent, so you are redirected (302 Moved Temporarily) to http://en.m.wikipedia.org/wiki/A (still no HTTPS).
  1. Browser sends "GET /wiki/A HTTP/1.1" en.m.wikipedia.org. As it is still insecure, stopMobileRedirect=true isn't sent:

Cookie: enwikiforceHTTPS=true; enwikiforceHTTPS=1

  1. Server detects enwikiforceHTTPS=true and enwikiforceHTTPS=1 (no idea why the browser has two cookies with the same name) and you are redirected (302 Found) to https://en.m.wikipedia.org/wiki/A.
  1. Browser switches on SSL and sends "GET /wiki/A HTTP/1.1". Now all cookies are sent, including stopMobileRedirect=true (private information removed):

Cookie: enwikiSession=REMOVED; centralauth_User=Stefan2; centralauth_Token=REMOVED; centralauth_Session=REMOVED; enwikiUserID=808814; enwikiUserName=Stefan2; enwikiforceHTTPS=true; enwikiforceHTTPS=1; stopMobileRedirect=true

  1. You see the mobile website.

Problem: As the redirect to HTTPS happens after the redirect to the mobile site, the stopMobileRedirect=true cookie is sent too late and the server won't know that you wish to stay on the desktop website.


Version: unspecified
Severity: minor

Details

Reference
bz53667

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 2:12 AM
bzimport set Reference to bz53667.
bzimport added a subscriber: Unknown Object (MLST).

It sounds like the cookie to force desktop mode is being set on https and not on http. Thus going to http will still redirect you to mobile and not desktop.

Arthur any thoughts on this?

Without much digging, I suspect that Stefan2 is correct. If that's the case, we'll need to involve operations to implement a solution. We should prioritize this bug during standup on Monday. Jon, I've updated the card in Mingle so we can deal with it then.

I've not really been able to reproduce this bug. I thought I had reproduced it by selecting an enwiki link from Google (for step 4 of the OP) - however it appears that Google is doing some kind of device detection and is turning the href for wikipedia links into en.m.wikipedia.org. By design, you can still hit the .m version of the site even if you have the stopMobileRedirect cookie - but only if you hit it explicitly. The stopMobileRedirect cookie only prevents automatic redirection.

I tried again by just typing in "en.wikipedia.org" into my URL bar for step 4 - I got the expected results (https, desktop site).

Stefan2, were the links you were clicking from 'elsewhere on the internet' exclusively from Google search results? Can you try again and double check the href of the links to make sure they are not pointing directly to the .m?

mgrover wrote:

I've tried several different ways as well and can't get it to happen either.

I'm marking this resolved as 'worksforme'. We are currently discussing the possibility of reaching out to Google about how they are linking search results for mobile devices.