{{SERVERNAME}} is supposed to return just the host name. (As opposed to {{SERVER}} which is supposed to output the protocol and host)
Expected output on wikipedia:
{{SERVERNAME}} = en.wikipedia.org
Actual output (with protocol relative urls):
{{SERVERNAME}} = //en.wikipedia.org
(Someone else reported this on irc I believe)
Version: 1.18.x
Severity: normal
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T21270 Relative URIs in interwiki links table break interwiki transclusion | |||
| Resolved | None | T20664 Relative URIs in interwiki links table causes failed redirects | |||
| Resolved | None | T22342 Support for protocol-relative URLs | |||
| Resolved | None | T33176 {{SERVERNAME}} variable does not strip // for protocol relative urls |
Looks like parse_url sees the whole lot as just a path '//foobar', so the fallback behavior returns $wgServer as a whole.
Switching from parse_url() to wfParseUrl() should fix this, as it has workarounds specifically for those urls.
Just did a check. This would be a bug in parse_url, it doesn't understand protocol-relative urls, however wfParseUrl does understand protocol relatives. So the fix would be to use wfParseUrl instead of parse_url.
I have a fix, committing and deploying. It's long known to me that parse_url() is a piece of garbage and does not understand protocol-relative URLs.
Fixed in r98193, deploying. Needs a parser test or something, too, but it's past 1am so I'm not doing that now.
Thanks Roan. The buggy version is now live on Wikimedia servers. I hope your fix will get through as fast as possible.
(In reply to comment #6)
Thanks Roan. The buggy version is now live on Wikimedia servers. I hope your
fix will get through as fast as possible.
I helps if I run svn up before scapping :D
So I accidentally did not deploy this last night, but I did just now. {{SERVERNAME}} now really works correctly on WMF wikis and the phishing site messages are gone.