Wikimedia blog

News from the Wikimedia Foundation and about the Wikimedia movement

Protocol-relative URLs enabled on all Wikimedia Foundation wikis

In July we enabled protocol-relative URLs on testwiki, and asked for bug reports. We did this in preparation for native HTTPS support for the sites. We received and fixed a number of protocol-relative related bugs, and then tested on a few of the larger wikis. We are now at a point where protocol-relative URL support is stable enough to enable it on all wikis, so today we’ve enabled it.

For information about what protocol-relative URLs are, why they are needed, and how it’ll affect you, see the post written in July. In brief: this changes most links we output in our content from looking like to // . The change shouldn’t affect you.

If you find any bugs related to protocol-relative URLs, please submit a bug report. Known issues are linked from the tracking bug.

Ryan Lane
Operations Engineer

EDIT Sep 28 14:29 UTC: Because of reported breakage in iOS clients, the API’s action=parse interface has been hacked not to return protocol-relative URLs. This is a temporary hack that you should not rely on; fix your clients instead. For details, see

10 Responses to “Protocol-relative URLs enabled on all Wikimedia Foundation wikis”

  1. Waldir says:

    “it’ll instead redirect to the proper URLs” — nice, I always hated when someone sent me a link to the favicon looked different in the browser tab, I had to login again, the url scheme was different… looking forward for more details in your next https-related post :)

  2. senthil says:


  3. Waldir says:

    What does this mean for

    • Ryan Lane says:

      Protocol-relative URLs don’t affect secure. Native HTTPS support will affect secure, though. won’t go away, it’ll instead redirect to the proper URLs. I have an announcement post coming about HTTPS real soon like.