Page MenuHomePhabricator

Wikimedia wikis should use https:// in $wgServer
Open, MediumPublic

Description

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.

Event Timeline

Tgr created this task.Nov 11 2015, 7:22 PM
Tgr raised the priority of this task from to Needs Triage.
Tgr updated the task description. (Show Details)
Tgr added a project: Wikimedia-Site-requests.
Tgr added subscribers: Tgr, BBlack, ori.
Restricted Application added subscribers: StudiesWorld, Matanya, Aklapper. · View Herald TranscriptNov 11 2015, 7:22 PM

Change 253053 had a related patch set uploaded (by Gergő Tisza):
Improve the documentation of wfExpandUrl

https://gerrit.wikimedia.org/r/253053

Luke081515 triaged this task as Medium priority.Dec 9 2015, 8:43 AM
Luke081515 assigned this task to Tgr.Sep 3 2016, 12:41 PM
Restricted Application added a subscriber: JEumerus. · View Herald TranscriptSep 3 2016, 12:41 PM
Ltrlg added a subscriber: Ltrlg.Dec 26 2017, 9:03 PM

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.

See also T54253.

Right, T54253 is the task where Tim lays out why protocol-relative URLs aren't really that great. Adding explicit protocols and folding this task into T54253 seems reasonable to me.

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.

Tgr added a comment.Oct 18 2018, 3:26 PM

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.

Just wondering if it's better to continue with T207073: Test wg(Canonical)Server as defined currently (it is based on current standard) or block it on this task?

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.

Tgr added a comment.May 11 2020, 11:01 AM

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.

Good catch!

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?

Nirmos added a subscriber: Nirmos.Jun 23 2020, 8:56 AM
Aklapper removed a subscriber: Anomie.Oct 16 2020, 5:02 PM
Tgr removed Tgr as the assignee of this task.Wed, Oct 28, 12:33 AM
Tgr added a project: User-Tgr.

Moving from assignee to user tag to indicate that I'd like to fix this but have no timeline whatsoever.