https://bugzilla.wikimedia.org/show_bug.cgi?id=44094
Roan Kattouw <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from Roan Kattouw <[email protected]> --- Root cause seems to be the switch from www.wikidata.org and wikidata.org and back. After manually pointing bits to Europe in my /etc/hosts, I observed the following on a wikidata page with a broken skin: http://bits.wikimedia.org/www.wikidata.org/load.php?debug=false&lang=en&modules=ext.wikihiero%7Cmediawiki.legacy.commonPrint%2Cshared%7Cmw.PopUpMediaTransform%7Cskins.vector&only=styles&skin=vector&* is the URL that is supposed to serve the skin CSS. Instead, it is a 301 to http://wikidata.org/w/load.php?debug=false&lang=en&modules=ext.wikihiero%257Cmediawiki.legacy.commonPrint%252Cshared%257Cmw.PopUpMediaTransform%257Cskins.vector&only=styles&skin=vector&* The redirect target URL above goes to wikidata.org rather than bits (and therefore to Squid rather than Varnish), but what makes it fail is that it's double-encoded: %7C in the original URL has turned into %257C. This causes RL not to recognize the separators in the &modules= parameter, so the whole thing is interpreted as one long module name. In the specific context of this request, the correct output for an unrecognized module is the empty string, so load.php serves an empty response. So it looks like this is a combination of now-obsolete 301s being aggressively cached by Varnish, and the good old Apache double-encoding bug. Note: on the page I tried, some load.php URLs were broken 301s and some were correctly functioning 200s. I suspect that, because the switch away from www. was reverted relatively quickly, load.php URLs with short cache times (5 mins) were affected while most load.php URLs with long cache times (30 days) were not. However, even URLs that have a stale 301 cached will still work as long as they don't contain %nn escape sequences, which is why the startup module (and, for that reason, all JS on wikidata) is still working. In fact, the URL in this comment is the only one I was able to find that satisfies all of the following: 1) is normally cached for 5 minutes rather than 30 days 2) requests multiple modules 3) is likely to have been hit frequently while wikidata was briefly(?) www-less #3 explains why WMDE people are reporting that non-Vector skins aren't broken. I just ran 'purge-varnish wikidata' on fenari to purge all URLs containing the substring 'wikidata' from Varnish, and that seems to have fixed it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
