26

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.

Improve this question
7
  • 2
    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 StaffMod
    Mar 1, 2014 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, 2014 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, 2014 at 2:24
  • Still reproducible.
    – Claudia
    Feb 8, 2015 at 4:32
  • 2
    That makes two years.
    – Damian Yerrick
    Mar 7, 2016 at 15:58
  • 1
    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 StaffMod
    May 8, 2016 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, 2016 at 11:06

2 Answers 2

Reset to default
2

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

Improve this answer
4

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).

Improve this answer
2
  • 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 StaffMod
    Feb 19, 2015 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, 2015 at 0:11

You must log in to answer this question.

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