Last modified: 2013-08-22 14:55:40 UTC
wikidata.org comes up without CSS in europe. According to Roan, it works from the US, so it's probably somethign bad stuck in european web caches. Setting useskin=monobook works, using useskin=vector doesn't help.
Probably caused by trying to fix and then reverting the fix to bug 41847. Bug 44087 may be related.
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.
(In reply to comment #2) > In fact, the URL in > this > comment is the only one I was able to find that satisfies all of the > following: > ...and it was also the only one that 301ed to a broken URL. Sorry for omitting that.
Seems to be fixed. If anyone still sees this problem after a forced reload (ctrl+shift+r or whatever), please reopen this bug report.
Closed older resolved bugs as verified.
