Topic on Extension talk:Popups

mw.user.sessionId() on page load detrimental to HTTP caching

8
TaylanKammer (talkcontribs)

This extension seems to call mw.user.sessionId() unconditionally whenever someone visits a page of the wiki, regardless of whether they're logged in or not.

The effect of this is setting the cookie mwuser-sessionId (usually prefixed with the wiki's database name), which means that the wiki visitor in question will not be served any cached HTTP content for any further pages they visit!

Wikipedia seems to have a workaround against this as far as I can tell by X-Cache HTTP headers I receive from it, though I couldn't find any documentation as to how it achieves this. A fairly typical Varnish or Nginx caching mechanism will not be accommodating against this, and thus suffer greatly. (In fact, it could be making the HTTP cache nearly useless, though I haven't made measurements; it might still be useful with SEO bots or such at least.)

Even the Varnish configuration recommended on Manual:Varnish caching is suspect to this issue, as the regex used to match session tokens will match mwuser-sessionId. (EDIT: This may be wrong after all; I had not thought about the equals sign at the end of the regex. Maybe that's the key.)

I wonder if this extension could be modified not to call mw.user.sessionId() for users that aren't logged in? FYI, the two places in the code that call this are src/actions.js:83 and src/instrumentation/statsv.js:23.

Thiemo Kreuz (WMDE) (talkcontribs)

This sounds like an issue that should be reported on Phabricator. Can you do this?

VPoundstone-WMF (talkcontribs)
Thiemo Kreuz (WMDE) (talkcontribs)
VPoundstone-WMF (talkcontribs)

@TaylanKammer since the phab form is restricted, I will post the template here. Please write the ticket and tag Data Products. Thank you!


===Description

====Steps to reproduce (step by step instructions, with links, commands and necessary data to reproduce the error)**

  • ...

====Observed behavior

  • ...

====Expected behaviour/Acceptance criteria (returned value, expected error, performance expectations, etc.)

  • ...

====Test environment info

  • ...

====Console logs

  • ...

====Screenshots

  • ...

===Completion checklist <To be filled in by assignee>

[] Regression tests covering this bug? [] Documentation updated and conforms to [|the accessiblity guide]? [] ...

TaylanKammer (talkcontribs)

@VPoundstone-WMF Sorry for not getting back to this sooner. Here's the details. Please tell if more needed.

===Description

Enabling the Popups extension causes a session token to be assigned via JS, after any page is loaded, even for anonymous visitors.

This potentially degrades caching, since HTTP response headers for wiki pages tend to include Vary: Accept-Encoding, Cookie.

====Steps to reproduce (step by step instructions, with links, commands and necessary data to reproduce the error)**

  • Disable the Popups extension in your LocalSettings.php file.
  • Open a private/incognito browser window or tab, and visit your wiki in it.
  • Use your browser's developer tools to confirm no cookies are stored yet.
  • Enable the Popups extension in your LocalSettings.php file.
  • Reload the visited wiki page in the browser window or tab from before.
  • Notice that a session cookie has now been stored by your browser.

====Observed behavior

  • Anonymous visitors get a session cookie as soon as they visit any wiki page; apparently through JS code, since the HTTP responses don't include any Set-Cookie headers.

====Expected behaviour/Acceptance criteria (returned value, expected error, performance expectations, etc.)

  • Anonymous visitors should not get a session cookie until they've performed some action that would actually require this, such as making an edit.

====Test environment info

====Console logs

  • None

====Screenshots

  • None
Prod (talkcontribs)
TaylanKammer (talkcontribs)

An update on this from my side: After taking a closer look at the recommended Varnish setup, it looks like the cookie mwuser-sessionId should not affect front-end caching, and I've been able to achieve something near identical with Nginx. The was indeed to only consider cookies matching the regexp ([sS]ession|Token)= with the equals sign at the end.

So, this issue with mwuser-sessionId being set would only affect a very naive front-end cache that's not fine-tuned for MediaWiki and looks at all cookies.