Here's something I noticed while testing a client-side fix for this issue.

If you follow a permalink / shortcut URL with an https: protocol, like:

you'll get redirected to:

even though, in fact, the https: version of the target URL would work just fine. This rather frustrates any attempts to fix such links in post text to use HTTPS.

The same happens with other similar shortcuts too. For example:

redirects to:

However, other non-permalink redirects do retain the correct protocol. For example:

correctly redirects to:

It seems this is because those redirects are actually using relative URLs in the Location: header, which, while not strictly speaking allowed by the HTTP/1.1 spec, does seem to work in most modern browsers. Presumably, the permalink redirects could be changed to work the same way.

  • 1
    That's because the slug-redirects don't use a full-URL absolute path: Location:/questions/223725/all-internal-links-on-stack-exchange-sites-should-be-protocol-relative – animuson Mar 1 '14 at 14:33
  • @animuson: Ah, they do indeed. I guess using relative redirects for the permalink URLs too should be OK too then, even if a strict reading of HTTP/1.1 does forbid it. – Ilmari Karonen Mar 1 '14 at 14:39
  • Related bug report on meta.tor.SE about the permalink URLs in the share pop-up always having the "http:" protocol prefix. – Ilmari Karonen Mar 23 '14 at 2:24
  • Still reproducible. – Isiah Meadows Feb 8 '15 at 4:32
  • 2
    That makes two years. – Damian Yerrick Mar 7 '16 at 15:58
  • I will note that this unlikely to get fixed before full HTTPS support is implemented, as this would break HTTPS short URLs on per-site Metas, which currently do not function at all over secure connections. We similarly do not link to the site's Meta in the top-bar over HTTPS for the same reason. – animuson May 8 '16 at 23:28
  • @animuson: HTTPS short URLs on per-site metas are already broken and return "403 Forbidden" errors, just like all other HTTPS URLs on per-site metas currently. So fixing this bug would not break them any worse than they already are. – Ilmari Karonen May 9 '16 at 11:06

This now works appropriately as part of the great HTTPS migration. All sites and links should point at HTTPS now.


IMHO, this is a little dangerous in the area of privacy. The fact it is still reproducible, almost a year after being filed, is a major problem. Please address this.

I do feel the default should be HTTPS for the permalink, as I know of no browser with 0.01%< market share that doesn't support HTTPS in any capacity. Also, Matter of fact, HTTP+TLS has been standardized in RFC 2818 for almost 15 years. Every modern browser supports TLS, so there's not really much excuse now to not have that support by default (and the few browsers that don't support it almost always fall back to standard HTTP, anyways).

  • 2
    We don't fully support HTTPS across the board yet, so going to "all links are https" isn't a good idea. HTTPS support is on our list. Nick Craver blogged about some of the challenges. It's a bit awkward to link to now since the post is almost two years old at this point, but the part of it about certs is still something we have to deal with. – Adam Lear Feb 19 '15 at 16:12
  • 1
    @AnnaLear Is the following behavior impractical to implement? When visiting a permalink through HTTP, redirect to HTTP. When visiting through HTTPS, redirect to HTTPS. – Damian Yerrick Jul 13 '15 at 0:11

You must log in to answer this question.

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