In addition to this we could probably merge the alpha and beta cookies.

The mf_useformat and stopMobileRedirect cookies are functionally different things.

• mf_useformat is used to set mobile vs desktop mode for a setup that has no separate mobile domain
• stopMobileRedirect will prevent automatic redirection of a detected 'mobile' device to the mobile view (this could be a separate mobile domain, or on a setup that relies on mf_useformat cookies for preserving mobile vs desktop mode)

We don't need both; we could conceivably use one cookie to manage these things. We could even have one cookie for storing all mobile-specific settings.

Marking resolved invalid as there's no actionable bug or problem here. if the request for investigation was motivated by some specific issue, let's file a bug for that.

I think the action here is to merge the cookies to minimise cookie usage and improve performance.

As i understood the bug was that by having more than 1 cookie we were introducing performance issues.

[1:55pm] jdlrobson: judging on your analysis in answer to "I received a request to investigate whether we need both stopMobileRedirect and mf_useformat cookies." we don't need both..
[1:55pm] awjr: oh, the action as i understood it was to investigate whether or not they were needed

Let's merge them since from your report we can.

What benefit would we get from merging them? I don't think merging them is a good idea, though it is possible.

We need to know what problem needs to be solved before we try to solve it, and it is totally unclear from this bug.

After chatting with MaxSem in e-person I gathered that the concern was that if a user has the stopMobileRedirect cookie present, but visits a mobile domain, their requests will always bypass cache (even if they have no other cookies present). If that was the original impetus for this bug, then the appropriate thing to do would be to strip the stopMobileRedirect cookie from the headers in Varnish. However, vcl_recv() in mobile-frontend.inc.vcl.erb makes it looks to me like this should already be happening:

55 set req.http.X-Orig-Cookie = req.http.Cookie;
56 if( req.http.Cookie ~ "disable" ||
57 req.http.Cookie ~ "optin" ||
58 req.http.Cookie ~ "session" ||
59 req.http.Cookie ~ "forceHTTPS" ) {
60 /* Do nothing; these are the cookies we pass.
61 * this is a hack in the absence of X-V-O support
62 */
63 } else {
64 unset req.http.Cookie;
65 }

Anyway, I think a new bug should be opened by someone with information about the actual problem and we should act on that rather than trying to guess.

OK. Max can you poke the original requestor if this is still needed?