Currently most Wikimedia wikis use protocol-relative URLs in $wgServer, which means that wfExpandUrl with PROTO_RELATIVE will expand to a protocol-relative URL. That does not make sense since we don't actually support HTTP anymore. For HTML snippets generated by some API with PROTO_RELATIVE (which is arguably the most correct choice for an API) and displayed on another site over an insecure connection, this will mean a performance hit (because of the extra redirect) and expose users to MITM.
|Open||None||T178357 Don't use protocol relative links to Commons in MultimediaViewer|
|Open||None||T54253 Protocol-relative URLs are poorly supported or unsupported by a number of HTTP clients|
|Open||None||T118413 Wikimedia wikis should use https:// in $wgServer|
- Mentioned In
- T256095: Stop sending the forceHTTPS cookie, make the HTTPS redirect unconditional
T228851: Source wiki editing and deletion always fails
T233090: Should EditURI be calculated using the site's canonical protocol?
T178357: Don't use protocol relative links to Commons in MultimediaViewer
T156320: $wgServer with initial https:// does not force HTTPS (wgSecureLogin)
T138142: Media Viewer embed code breaks links to Wikipedias
T117082: Cached REST endpoint for extracts requests
- Mentioned Here
- T207073: Test wg(Canonical)Server
T54253: Protocol-relative URLs are poorly supported or unsupported by a number of HTTP clients
This task description says that "we don't actually support HTTP anymore" and @Bawolff said the same on IRC this evening. This statement feels misleading since we do support HTTP and will continue to do so indefinitely. Keeping the HTTP --> HTTPS redirects working means supporting HTTP, as far as I'm concerned.
To be pedantic, I mean we no longer support serving mediawiki traffic as HTTP, so we would not want to generate any urls using anything other than https, which is what $wgServer is controlling.
When the task was written, we still allowed HTTP POST to the API (since redirects don't work there) and that could cause problems with relative URLs. Now that HTTP is completely disallowed (not from the user's POV but in the sense that our MediaWiki servers will never receive one) relative URLs are less problematic, but they still require some work to turn into absolute URLs so replacing the relative URLs in the configuration would be a performance (micro)optimization, at least.
I suppor this change. Note however, that a great many user scripts and gadgets rely on the fact that mw.config.get('wgServer') is protocol-relative. Using constructs such as location.protocol + wgServer to form URLs.
Before we can fliip the switch, we'll need to survey the land (using mwgrep or https://global-search.toolforge.org/), identify the common patterns, figure out how they can be done instead in a way that works both today and after the change, then document this migration guide, and announce it through Tech News.
What would be the sane way to support gadgets without them having to know whether wgServer is protocol-relative? Having something like wgOrigin? Or just expect them to do a manual check?
If we could do this over again, I would've made wgServer always expanded and just not support client-side awareness protocol-relativity, at least not within core. The base module could have contained an expression like location.protocol === 'http:' ? 'http:' : 'https:' in front of the mw.config assignment if the server-side is configured in a protocol-relative manner. Note that before protocol-relative support was added wgServer in JS was already always expanded and its this change that first broke lots of JS code that was not expecting that. A decade later, the opposite compat issue has emerged.