On election pages, such as Software Recommendations' ongoing election, if you're viewing the page over HTTPS, the candidate cards use HTTPS links.

Fine, that's pretty standard behaviour. The problem here is the "meta posts" link:

enter image description here

Meta HTTPS is broken (no wildcards in the middle of SSL certs) - so this link goes to a big red security warning page.

  • Related: Broken links to per-site metas
    – animuson StaffMod
    Commented Nov 30, 2015 at 22:02
  • Could you please change the embedded image to use HTTPS? Thanks.
    – Ry-
    Commented Nov 30, 2015 at 22:44
  • @RyanO'Hara Can't actually tell if you're being sarcastic or not, but if not: I recommend having a browser extension that converts to HTTPS where possible. Then people who want HTTP can have it, and you can have HTTPS.
    – ArtOfCode
    Commented Nov 30, 2015 at 22:58
  • 1
    It’s not sarcasm, and extensions that convert to HTTPS where possible – at least the ones I use – don’t automatically rewrite mixed embedded content. The browser just blocks it. (So I don’t see an image when looking at your post, regardless of HTTPS Everywhere, because security.mixed_content.block_display_content is trueas it should be.) I would recommend a protocol-relative URI, but that breaks the mobile app, or at least it did at one point.
    – Ry-
    Commented Dec 1, 2015 at 1:29
  • The HTML contains absolute link to the http:// version. If you're running extension that change links to https:// that's not SE problem and not a bug. Commented Dec 1, 2015 at 7:39

1 Answer 1


The only way to fix that (short of rearranging how meta site URLs are set up, which is planned, but keeps getting pushed back by more pressing things) is to force the link to go to HTTP only... which isn't great.

We do not officially support HTTPS on our sites, even though most of the time it will work. Browsing through HTTPS is a choice at this point, so quietly forcing you back to plain HTTP feels worse than forcing you to make the informed "do I want to continue or do I want to bail?" decision. So if you're running that way anyway, clicking past that warning is probably gonna just have to be the price you pay for the time being.

Hold on a sec, I took a closer look at the code, and it looks like we're already linking to the plain HTTP version (gonna need to fix that one up once we go to full SSL support for sure). Are you running HTTPS Everywhere or a similar addon that forces all connections to go over HTTPS? Everything I said above still stands in the general case for the links that are already protocol-relative, but now that I've looked at the code, I don't see how we're creating what you're seeing.

  • 2
    You can't actually "click past the warning" because CloudFlare doesn't allow its connection and will just return a 403 Forbidden error if you add a security exception for your browser. But I agree forcing a http-only link is a bad idea.
    – animuson StaffMod
    Commented Nov 30, 2015 at 23:05
  • @animuson Woof. That is even worse. However, I can't repro these particular links being HTTPS, so this may be moot anyway. Not a fan of leaving them HTTP-only given my own argument against that, but fixing that would actually mean breaking what should currently at least sort of work and I'm not into that either. :/ No graceful way out of this one short of proper HTTPS support... fingers crossed for 2016?
    – Adam Lear StaffMod
    Commented Dec 1, 2015 at 5:53
  • So, this looks like status-already-done. Commented Dec 1, 2015 at 7:40
  • If the OP was using SOUP, that could've also caused this issue. I just pushed a fix for this as part of SOUP v1.42. Of course, the real problem is still that per-site metas are broken over HTTPS. Commented Dec 2, 2015 at 13:43

You must log in to answer this question.

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