In a discussion titled “Outgoing partial links → https (on the fly)? - NOT http.”, users debate whether Discourse should automatically convert partial URLs (e.g., example.com) into HTTPS links by default to avoid broken HTTP links. mitchd proposes a backend solution that checks if a target supports HTTPS before redirecting, citing a Python snippet as inspiration. pfaffman supports making HTTPS the default, referencing Chrome’s move toward HTTPS-by-default, while Jagster objects, noting many sites still operate over HTTP and warning against forcing HTTPS where it’s unnecessary or unsupported — especially in edge cases like reverse proxies. Arkshine adds that modern browsers and HSTS headers often handle HTTPS redirection automatically. Jagster clarifies that while HTTPS should be preferred, Discourse shouldn’t enforce it, and any solution must remain editable. mitchd revisits the idea of protocol detection via HEAD requests to intelligently choose HTTP or HTTPS, suggesting implementation in Ruby. The thread highlights tension between security best practices and real-world compatibility, with no consensus yet on whether Discourse should intervene or leave it to browsers.
As it seems that they are made into http:// links, which leads to all sorts of mess when http://example.com outgoing requests fail for many users clicking-on from the post.
( Or, check the generated target address and amend to the correct protocol to get there? )
Thanks, first question, sorry if repeat but I can’t see anything succinctly this.
mitch
Please no. Out there is a lot of sites that are using http, because they just don’t need SSL.
Would this be another casual job for search&replace? Or am I misunderstanding everything again?
irrational panic attack
Plus I’m worrying kind of edge situation where Discourse is using its own VPS and front of it is another VPS where is reverse proxy. Those will talk to each other without SSL quite often.
But that is totally different situation, right? But I start to be a bit jumpy everytime there is something default that can change for me familiar abbreviations…
I don’t think I am wrong when we are talking about reality.
Need for securing connections between servers using SSL when data is not including anything that need to secure is worth of another topic. But is totally off topic here, though.
But saying to users that sorry, you can’t link because 3rd party isn’t using port 443 is just bad idea. It is not admin’s or not even discourse’s job to say what someone should or must do.
Yes if it is there. And some household routers/modems are configured to use only https and that is actually really annoying. Because not every site follows Google’s want to use SSL everywhere and partly hecause so many platform serves old links using http and those stubid boxes can’t rewrite url.
So before any feature discussion there should be another meta topic first: is it responsibility of forum platform force to use SSL for outbound links.
After that technical solution is reasonable easy, I reckon — but again, I’m not a dev.
But back to topic.
So search&replace isn’t acute solution? But I don’t follow now… again… is the real issue how Discourse automatically forms links if just plain url is given? Is so, then I backup a little and yes, automatically there should be https — but it must be editable.
So with that (translated to Ruby if I recall), Discourse back-end could find out if the target of a partial link given in a post is https or http, then (with a preference for https) open the correct target link for the user?