In preparation for the eventual deployment of full HTTPS support on Stack Exchange, and also to make the currently available "alpha" HTTPS support more usable, all links from Stack Exchange sites to other Stack Exchange sites should be protocol-relative.

Currently, at least the following places still feature links with explicit http: protocol prefixes:

and, of course,

  • lots and lots of user-supplied links in post and comment content.

I've posted this feature request with the intent to provide a single central place for tracking these issues, rather than having them scattered across multiple meta threads. If you find more places on SE where protocol-relative links should be used, please report them below.

I fully expect this request, in its full sense, to be treated as for the time being; however, these issues do need to be fixed at some point before our HTTPS support is ready for "prime time".

Ps. Yes, the next release of SOUP (v1.10) is going to include a general client-side fix for most of these issues. In the mean time, the HTTPS Everywhere plugin effectively provides the same functionality, and much more besides.


5 Answers 5


So I'm going to this, but for good reason: we're making everything HTTPS this month. You can read more about it here: Network-wide HTTPS: It's time

  • So instead of allowing user choice, it's now being overridden in the other direction? Sigh. Commented Feb 12, 2018 at 20:30
  • 1
    @TobySpeight what user choice? We redirect all traffic to https://, and Chrome will be flagging all http:// sites as insecure later this year. Why would you want to opt into insecure legacy protocols we've all moved past? Commented Feb 12, 2018 at 20:32
  • The choice for users for whom the overhead of HTTPS is unacceptable, or for whom the protocol is inaccessible (e.g. by site firewall policy - note that I don't impose such restrictions!). If you've chosen the HTTP version of the site, why would you want the links all to go to the HTTP/S version? (BTW, I personally use HTTPS Everywhere, so don't get to see it in plain HTTP; just sticking up for others) Commented Feb 12, 2018 at 20:35
  • 2
    @TobySpeight The overhead of HTTPS is now minimal (in fact with HTTP/2 it's faster than HTTP). And we're redirected to https:// for nearly a year now, so I have to ask: where is this coming from? I'll be very honest here: this really feels like complaining for the sake of doing so without an actual reason or use case. Commented Feb 12, 2018 at 20:37
  • Well, as it's not a problem for me, I'll not pursue it further. SE works for me (and is much better than most of what's out there - a forced security upgrade is much better than a forced downgrade), so I'll just thank you for looking after it, and keep quiet for a bit. Commented Feb 12, 2018 at 20:46

Site switcher on https://stackexchange.com is not protocol-relative

Links to other Stack Exchange sites in Site Switcher is protocol-relative when we are on a particular SE site or on MSE. But when we are specifically on https://stackexchange.com/ the site switcher links to the http version of all the sites. The links over there should also be protocol relative.

Site switcher on stackexchange.com is not protocol-relative


As planned, version 1.10 of the Stack Overflow Unofficial Patch now contains a client-side implementation of this feature.

Specifically, it works by finding all links on the page that use the http: protocol and point to a Stack Exchange site, and rewriting them to use https: instead.

Some notes about the implementation:

  • This feature is only enabled if you're already looking at the page over HTTPS. It will not force you to use HTTPS if you don't want to. (Also, if you accidentally switch to plain HTTP, SOUP will not alert you or redirect you to HTTPS. If you want that, use HTTPS Everywhere.)

  • Links to chat, Area 51 and the SE blog are currently excluded, since those sites still load much of their JS and CSS over HTTP, and thus work very poorly, if at all, over HTTPS.

  • SOUP does not run on non-SE sites, and thus cannot rewrite links to SE from other sites. Also, if you're, say, using SE chat over plain HTTP, any links there will not get rewritten.

  • Obviously, the rewrite also does not apply to things that are not ordinary links, such as form actions or JavaScript pseudo-links. Fortunately, most of those seem to be using relative URLs already.

  • To work around a known bug with permalink URLs, any such URLs are rewritten to a slightly longer form (/q/ and /a/ become /questions/, and /u/ becomes /users/). This fix is currently only applied to permalink URLs that use the http: protocol; any permalink URLs already using the https: protocol (or no protocol at all) will not be fixed, and so will redirect you to an HTTP URL if followed.

  • For the curious, the code of the user script includes the following line:

    //css:  "a.soup-https-fixed:not(#specificity-hack) { color: green !important }", // uncomment to highlight affected links

    Uncommenting it (by removing the // in front of css:) causes all rewritten links to be colored green. You can also achieve the same effect by installing the CSS rule shown on the line as a user style.

In general, this feature of SOUP should not be considered an adequate replacement for HTTPS Everywhere; even with the URL rewrites, it's still all too easy to accidentally switch from HTTPS to plain insecure HTTP. Still, if you just want to occasionally try using Stack Exchange over HTTPS (e.g. to see how well / badly it works), this fix does make it a lot easier to stay in HTTPS mode.

Note (December 2015): As of SOUP v1.42, this fix is no longer applied to links to per-site metas (meta.*.stackechange.com), since, alas, those don't currently work over HTTPS. Hopefully, we'll eventually get proper support for HTTPS on meta sites again, but until then, this part of the fix was doing more harm than good.

  • Why does this require users to install a script? Why can't the site do this when generating HTML? (so that everybody benefits) And why does it replace explicit HTTP with explicit HTTPS? Wouldn't it be kinder to leave the protocol unspecified? (And yes, I happily use HTTPS Everywhere, but I'd like SE to be the best for *all users). Commented Mar 11, 2016 at 11:14
  • @TobySpeight Yes, it would be far better to do this on the server. I'm not a Stack Exchange employee, though, and don't have access to the SE servers or the code they run, so this unofficial user script is the best I can do. Commented Mar 11, 2016 at 11:39
  • @TobySpeight (And yes, if done on the server, using protocol-relative URLs would be best. For the script it makes no difference, since it only applies the replacement when the page is loaded over HTTPS anyway.) Commented Mar 11, 2016 at 11:44
  • This is currently having an unintended effect, I hope short-lived. Meta.SE is now using HTTPS, as is I think MSO, so if you're there & you use the supercollider to navigate to another site, you get HTTPS. That's fine so far -- main sites work with HTTPS -- but as soon as you go from there to a per-site meta, you get the certificate warning because HTTPS doesn't yet work on per-site metas. I don't know if you want to make any changes now or if we should just suck it up; I'm just reporting. Looks like you'll be able to remove that code soon. See meta.stackexchange.com/q/292058/162102. Commented Mar 9, 2017 at 3:21
  • 1
    @MonicaCellio: Thanks for the heads-up. I guess I could exclude meta.*.stackechange.com links from the fix again, like I did back when CloudFlare broke HTTPS for them. Once the meta sites are moved to *.meta.stackexchange.com (and presumably start having valid certs), the exclusion should just become a no-op. Commented Mar 9, 2017 at 10:39
  • @MonicaCellio: This should be fixed in the SOUP development branch now. I'll try to push an update to the stable branch later tonight, after I've done a little more testing (and finished upgrading Ubuntu on my laptop). Commented Mar 9, 2017 at 18:43
  • @MonicaCellio: Actually, now it should be fixed in the devel branch... looks like I forgot to actually push the changes to GitHub. Oops. :) Commented Mar 9, 2017 at 19:08
  • It's ok; I'm not monitoring your devel branch -- I installed it from your StackApps post however long ago and get updates automagically that way. If it's coming soon to "standard edition" I'll just wait for the push. Commented Mar 9, 2017 at 19:12

Hot Network Questions is still explicitly HTTP

Extract from the end of "Related" and start of "Hot Network Qs":

<div class="spacer js-gps-track">
<a href="https://meta.stackexchange.com/q/270074?rq=1" title="Vote score (upvotes - downvotes)">
    <div class="answer-votes default">6
</a><a href="https://meta.stackexchange.com/questions/270074/broken-links-to-per-site-metas?rq=1" class="question-hyperlink">Broken links to per-site metas</a>


<div id="hot-network-questions" class="module">
        <a href="//stackexchange.com/questions?tab=hot" class="js-gps-track" data-gps-track="posts_hot_network.click({ item_type:1, location:11 })">
            Hot Network Questions
                <div class="favicon favicon-rpg" title="Role-playing Games Stack Exchange"></div><a href="http://rpg.stackexchange.com/questions/76958/what-is-the-probability-of-surviving-my-death-saves" class="js-gps-track" data-gps-track="site.switch({ item_type:11, target_site:122 }); posts_hot_network.click({ item_type:2, location:11 })">
                    What is the probability of surviving my death saves?


Only the "Hot Network Questions" link itself (in the H4) is protocol-relative. The actual question links are explicitly HTTP.

Interestingly, the related-question links seem to be explicitly HTTPS!

  • This is not a bug list. If you have a problem, please ask a new question. Commented Mar 11, 2016 at 11:27
  • 1
    @PatrickHofman I did ask people to post here if they find any new places with explicit http: links, so this is technically a valid answer. (Whether SE staff would prefer to have such reports collected here, or individually posted as separate bug reports / feature reqs, is something I have no specific knowledge of.) Commented Mar 11, 2016 at 11:49

I just noticed that trying to go from https://emacs.stackexchange.com/questions to Help > Meta (which gives this URL: https://emacs.meta.stackexchange.com/), I get this (using Google Chrome). This did not happen before. (Dunno how much this is related to the question here - hope it is.)

enter image description here

  • I'm pretty sure that warning has always appeared if you try to access a per-site meta over HTTPS (except for a while when you just got a 403 error instead), due to limitations of SSL wildcard certificates. The meta link in the Help menu appears to have been protocol-relative since last year. Commented Oct 9, 2016 at 10:13
  • Anyway, as long as you check that the cert is valid for *.stackexchange.com and that there's nothing else wrong with it, you can in fact safely click the "unsafe" link to bypass the warning. Even though your browser is being extra cautious and doesn't allow the wildcard * in the cert to match multiple hostname parts (like meta.emacs), we do in fact know that all hostnames under the stackexchange.com domain are owned and controlled by the same entity. Commented Oct 9, 2016 at 10:19
  • @IlmariKaronen: Sorry, but I'm not going to fiddle with that. Users should not have to "check that the cert is valid for *.stackexchange.com and there's nothing else wrong with it". This is what certification is for, presumably, so that users do not need, themselves, to somehow determine whether there's anything wrong.
    – Drew
    Commented Oct 9, 2016 at 14:47
  • 1
    @IlmariKaronen: I've always used that menu item (Help > Meta) from emacs.stackexchange.com to get to that site's meta page, and I've never had this problem before. It's possible that it worked only when I used http instead of https (which I am not obliged to use now, since the last Chrome update) - dunno. Seems like it's time now for Stack to make https work seamlessy everywhere.
    – Drew
    Commented Oct 9, 2016 at 14:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .