The change that likely triggers it has been made in 89629154496932504bebbcb06d85e94cb64b0a0d by @tstarling

To fix T183302: Secure login notice on new vagrant install we added code in puppet/modules/mediawiki/templates/multiwiki/CommonSettings.php.erb that does this:

// T183302: Mutate $wgServer *after* local settings changes
if ( PHP_SAPI !== 'cli' ) {
    // T68399: set wgServer from inbound request
    $wgServer = WebRequest::detectServer();
    if ( isset( $mwvSupportsHttps ) && $mwvSupportsHttps ) {
        // Create protocol-relative URL when the HTTPS role is active
        $wgServer = preg_replace( '#^https?:#', '', $wgServer );
    }
}

That block of code needs tweaks/additions to make wfExpandUrl() happy. The trick is figuring out what hacks will let us have a custom http port and a custom https port at the same time.

I think protocol-relative URLs should be deprecated. If you really need a wiki to be accessible via both HTTP and HTTPS, you can always have a dynamic $wgServer, but all the hacks that help to switch between HTTP and HTTPS and the support for cache sharing between the two should just be removed. HTTPS should be used for public websites, and HTTP for localhost. There's not really a situation in which switching between the two is advisable.

I don't disagree with @tstarling's assessment in T201965#5481567. This then moves the question to the validity of role::https for MediaWiki-Vagrant. We could:

1. Drop the role and make folks who want to test HTTPS things figure out how to do so manually
2. Figure out how to change the role so that when you flip it on the MediaWiki-Vagrant managed wikis become HTTPS only
3. Figure out how to make HTTPS the default and only behavior for MediaWiki-Vagrant

Any other options I'm not thinking of?

The least amount of work for me/MediaWiki-Vagrant maintainers would be dropping the role. We don't have any statistics on role usage, but this role has been buggy for at least a year if not longer and there are not a lot of tickets about that, so I feel pretty comfortable saying that a relatively small percentage of deployments and probably a smaller percentage of developers/users. The only other role that includes role::https is role::wikimediaproduction which I believe is similarly little used.

Making the role a more complete takeover of the wiki farm would take some thinking about Puppet and ordering and how we generate the LocalSettings collection for each wiki. One way or another it would be possible (maybe not pretty, but possible), but it would take an unknown amount of effort from someone who cared and was willing to put in the time.

Going HTTPS only would be nice, but similar to the complete takeover option has a pile of unknowns to consider. One thing I do know it would necessitate is changes in Cloud VPS to allow a web proxy to terminate at a HTTPS backend. It would also need to either use of Let's Encrypt to get properly signed certificates, or adding a lot of instructions to tell everyone how to allow/trust self-signed certificates. Again, not impossible, but not trivial and it would need someone who cares a lot to carry the work through to a proper finish.

In T201965#5481650, @bd808 wrote:

2. Figure out how to change the role so that when you flip it on the MediaWiki-Vagrant managed wikis become HTTPS only

Would this be as easy as removing the if ( isset( $mwvSupportsHttps ) && $mwvSupportsHttps ) { block from puppet/modules/mediawiki/templates/multiwiki/CommonSettings.php.erb?

Hey all,

Just wanted to add that a few of us over in fundraising-tech do use the https role for testing with payment gateways that require returnURLs to be TLS/SSL endpoints. Removing the https role would cause us some disruption.

I've also run into the issue reported in the ticket description and toggling the https role on/off has been my solution to-date.

In T201965#5481567, @tstarling wrote:

If you really need a wiki to be accessible via both HTTP and HTTPS, you can always have a dynamic $wgServer, but all the hacks that help to switch between HTTP and HTTPS and the support for cache sharing between the two should just be removed.

I think most of the hacks are related to making sure that login is always on HTTPS, which would still be needed with a dynamic $wgServer (except we'd also need a new variable to tell MediaWiki that it is in fact dynamic).

HTTPS should be used for public websites, and HTTP for localhost. There's not really a situation in which switching between the two is advisable.

AIUI the main use case is not preventing access for clients that do not support HTTPS (or the version of it the site is using).

For MW-Vagrant, I agree we should just make the role HTTPS-only. That would involve:

• making $wgServer non-protocol-relative (trivial, as @bd808 said)
• replace the crappy self-signed cert thing with Let's Encrypt (I tried this, need to clean it up and add renewals but did not seem hard)
• making sure that internal requests (API calls and such) don't break. As long as we use Let's Encrypt this should work out of the box (no need to suppress cert validation), alternatively we could just make sure everything uses HTTP (but then thought needs to be given to avoid HTTP -> HTTPS redirection, which we do want for external requests).
• make sure Cloud-Vagrant does not break. I think this would also work out of the box, we just need to make sure the call from the Labs proxy is treated as internal.