You're right that it's archaic. We have recently removed support for this mode from CentralAuth: T348852: Remove CentralAuth support for mixed-protocol HTTP/HTTPS wikis. But that was easier than doing it in MediaWiki, since we didn't need to worry about users other than Wikimedia wikis.

There is quite a bit of code for supporting wikis hosted on both HTTP and HTTPS protocols, especially in the auth components, including several config options and public interfaces that will need to be deprecated first.

Code to review (not necessarily all of this should be deleted): https://codesearch.wmcloud.org/core/?q=SecureLogin|ForceHTTPS|CookieSecure|prefershttps|stickHTTPS|requiresHTTPS&files=php&excludeFiles=&repos=&i=fosho

From the original task description:

See also: https://www.jefftk.com/p/history-of-https-usage

...which links to Let's Encrypt stats which has this nice chart based on Firefox telemetry:

(I feel like we already had a task about this but couldn't find it.)

Some issues that this would resolve or obsolete:

• T55197: OATH should use $wgSecureLogin
• {T219350}
• T180886: AuthManager special pages should honor $wgSecureLogin
• T149977: After login, user not logged in when "prefershttps" set to false and "wgSecureLogin" set to true
• T270596: SpecialPage::checkLoginSecurityLevel unconditionally uses PROTO_HTTPS
• T41676: Links in MediaWiki emails should respect the user's https preference

and some issues would become simpler to solve:

• T160387: Support Strict Secure Cookies
• T54253: Protocol-relative URLs are poorly supported or unsupported by a number of HTTP clients
• T111135: LocalSettings.php lacks wgSecureLogin, wgCookieHttpOnly and wgCookieSecure

Also related: T118413: Wikimedia wikis should use https:// in $wgServer

One of the reasons why we might need to support HTTP mode is the TLS overhead (performance cost) but I don't think it justifies the additional complexity we need to maintain. I wonder if we have any use cases or requirements to support mixed mode? Only thing that comes to my mind is dev environments - but those are just HTTP mode (without SSL).

Individual cases may vary, but the delay and overhead of TLS is generally believed to be outweighed by the performance benefits of HTTP/2 and QUIC, which in practice only work over TLS.

From my experience, the only reason to operate a site over HTTP exclusively is sysadmin simplicity. I believe this is an important and worthy reason to support HTTP for. However this task is not about dropping HTTP support. It is about supporting specific sites to simultaneously decide to provide TLS and yet not want to make it an enforced default.

That would imho only make sense if there are significant server or client costs, where there no longer appear to be, with the exception of the costs associated with providing it at all, which as said are sound but not what the task is about.