[12:49:53] Krinkle: if you have time, would you be able to fact-check my explanation at https://gerrit.wikimedia.org/r/c/operations/puppet/+/1092323 ? My understanding of VCL logic is very superficial. [13:17:46] * Krinkle looking [14:17:39] tgr|away: Hm.. I'm not sure I understand how these can be cachable in the first place. Are they actually? [14:18:14] Or do you mean, you want to make sure Varnish can treat these as `hit-for-pass` to avoid congestion, i.e. guruantee a fast miss/pass so that concurrent requests don't wait for each subsequent uncacheable response. [14:18:57] If yes, as long as there is a previous CC:private response or session cookie of sorts already, that might already happen. [14:27:40] tgr|away: What is handling these correctly today? [14:27:49] (without the split) [15:06:10] Krinkle: the autologin steps which are potentially anonymous are cacheable. That's Special:CentralAutoLogin/start (locally) and Special:CentralAutoLogin/checkLoggedIn (on the central wiki/domain). [15:06:37] They both call OutputPage::setCdnMaxage(). [15:06:57] Ah I see. When we make the background ajax fetch on page views to loginwiki, if there are no cookies there (or at least, not attached by the browsers) we can respond from the CDN immediately as a no-op. [15:07:33] I was thinking of the redirect chain during/after login, not the background fetch that we expect not to work without third party cookies in the long term. [15:07:52] Yes. It's important due to volume - this is done once per device per day, more or less, and with the very short browsing sessions we have, that's the same scale as total pageviews. [15:07:57] Right, with that moving to the shared domain, the path for that is changing. [15:08:05] Does its no-op response also vary between sul3 and non-sul3? [15:08:36] For /checkLoggedIn it's not really an issue. But /start has to redirect to a different domain depending on whether the user is in the SUL3 cohort. [15:09:18] (/start is the local part that sends the user to the central domain. /checkLoggedIn is the central domain part, so that will be split naturally.) [15:09:36] Hm.. and that decision is made server-side? [15:10:22] Right to start the token internally, the JS can't go to the central directly [15:10:37] and we can safely assume the sul3 cookie will work there since it's on the local domain [15:11:13] we have (or had?) a number of cookies in mobilefrontend and elsewhere over the years that we vary response by [15:11:25] afaik that code was never put near the session|token cookie logic, though. [15:11:50] Traditionally we had two workflows: central login where JS sends you to the central domain directly (but then with SUL3 we'd have to figure out what is the central domain, which means mirroring the opt-in logic in JS) and edge login, which first sends you to /start on the edge wiki and it does the jumping between the edge wiki and the central domain from there. [15:12:20] For SUL3, we are adding a /start step to autologin as well, that way we only have to solve one problem. [15:12:51] sorry, the first worflow is normal autologin, not central login [15:13:29] (central login does not involve cacheable requests) [15:15:36] wrt VCL code organization, I guess the other option would be to set something like Vary: X-SUL3 and then set X-SUL3 from the opt-in cookie. Then it wouldn't have to be intertwined with the session cookie logic. [15:15:49] Though they are both about authentication so not sure if that's a bad thing. [15:26:31] Such vary can be accomplished with the varnish hash_data() function I think. [15:26:41] I commented on your Varnish patch with past examples. [15:26:51] Looks like those MF features have all been discontinued since [15:28:27] I do wonder if the request could include this cookie in its query parameter since we issues it from the pageview context, seems like that might work, depending on how the request is formulated. Whether `fetch(cookies.sul3 ? urlA : urlB)` where both are provided by a RL package file, or fetch(url + ?sul3 = cookies.sul3)`. [15:28:31] That might simplify it. [15:29:37] to an extent we are doing that (/start adds usesul3=1 to the redirect URL, and then everything else passes that flag along) [15:29:50] but initiating that in JS would be tricky [15:30:10] fine as long as a dedicated cookie is the only opt-in mechanism [15:30:40] but at one point we might want something like a per-user flag [15:30:54] check UserName cookie, check global preferences for the user [15:31:01] that wouldn't work on the JS side [15:31:22] maybe I'm overthinking and we don't really need that for the rollout, not sure [15:32:52] the idea was being able to opt existing users in (by tagging them manually via global preference, or by central user ID buckets), and that should happen everywhere at the same time for that user as much as possible, and normal opt-in cookies aren't really useful for that [15:38:24] mw.user.options is synchrounously available in all JS contexts, embedded in before any module code runs [15:38:50] assuming that a per-user flag is a user pref (either hidden/api or beta/visible) [15:39:05] including any global prefs resolved [15:39:54] however I think the context in whcih this request is made is before the user is logged-in right? I'm not sure how that is meant to work. [15:40:08] That would imply you don't have the cookie either [15:40:48] ( https://gerrit.wikimedia.org/r/c/operations/puppet/+/359417 https://gerrit.wikimedia.org/r/c/operations/puppet/+/381050 https://gerrit.wikimedia.org/r/c/operations/puppet/+/525268 is where the mobile stuff got removed FWIW, it's only doing hit-for-pass for some mobile cookies now) [16:18:17] Amir1: congrats on being "here" 3 years! :D https://docs.google.com/presentation/d/1RaA-KlHC2w20yESyHGPkzFSFZM8dmbkLuhWKVuSkn08/edit#slide=id.g1d878106c5a_0_129 [16:20:51] xD thanks [16:21:37] I wrote a document of issues of databases when I joined. Still doing it. Halfway done 😁 [16:35:48] Krinkle: yeah the idea was to look up the user by the UserName cookie (which is set for 30 days / 1 year depending on the remember me option, but not unset on logout), which would work at least for wikis already used by that person. That can't be replicated on the JS side. [16:36:14] Of yourse those are the same wikis where that person is probably already logged in, so maybe not that useful. [16:37:43] so not sure about it, but in the end the puppet change doesn't seem too complicated and it's nice not to have a split JS/PHP feature flag mechanism that we'd have to keep in sync [17:07:38] ...now that I have written it down it doesn't really make sense. There is probably no way to make that work with Varnish. [17:10:06] It could still be useful to decide which login page to show to the user, as there's no caching involved in that, but not for autologin. Maybe we should just ensure the old and new central domain is in sync, and not switch over the autologin target until the wiki is fully switched over?