Users discuss making auto-linked URLs use HTTPS by default in Discourse. renem wants to avoid mixed content errors from HTTP links, noting that while force_https is enabled, inline text links default to HTTP. pfaffman confirms the setting is enabled by default, but Arkshine points out it’s false by default in the code. Firepup650 and renem observe that links on new lines become HTTPS due to oneboxing and redirects. Stephen clarifies that HTTP links don’t trigger mixed content warnings, which are caused by insecure assets. Bas argues that changing the default to HTTPS isn’t necessary since most HTTPS sites redirect HTTP requests. renem explains the issue affects internal links embedded on the main site. pfaffman suggests using watched words to replace bare hostnames with HTTPS links, which renem plans to try. JammyDodger warns that this may conflict with markdown linkify TLDs.
I tried googling or searching but couldn’t find it. When I type a domain name such as discourse.org in a sentence, this becomes a link. This is a HTTP link:
Is there any way to make this HTTPS by default? I’m trying to get rid of mixed content errors without manually turning these into HTTP links.
There is a force_https site setting. It’s enabled by default on a standard install.
Is it not enabled here then? Even the direct link to meta.discourse.org is an HTTP link here. I will verify if this is true on other forums.
From what I see in the code, force_https is false by default.
The force_https site setting is missing here. From what I read here:
This happens because HTTPS is enabled. I use Let’s encrypt.
It seems that by default, text links are HTTP and you can’t change this. If you add it on a new line, it becomes a HTTPS link. For example:
Just confirmed, links posted like this use http, even when force-https is on.
I could be wrong, but I assume that’d be because the oneboxer follows all redirects when placed like that, where it doesn’t for on-line links.
So, the big question is…can we change this behavior? HTTPS is pretty much the default nowadays:
The discourse.org or meta.discourse.org are watched words replaced automatically by links. Maybe it doesn’t use https links there. 
I don’t believe that is true, the same behavior is exhibited on, say, google.com and apple.com for a few quick examples.
To me, it seems like inline links without a protocol just default back to http. (so https://google.com works for example)
Oh, you’re right.
Exactly. It would make sense to change this behavior to HTTPS instead of HTTP right?
Unless something has changed recently a link to an insecure site won’t trigger a mixed content error.
Mixed content errors refer to the assets which make up the page. If your site is https but loads assets from an insecure source then you would be serving mixed content.
Force_https refers to your discourse site and internal links within it.
A link on a new line oneboxes, rather than just being a link. To do that the link has to be ”loaded” and the default document at the destination is inspected. If the site uses https over http that redirect would take place.
I don’t think you would want this.
While it’s certainly high, which is good, I don’t think that 85% is enough to change the default behaviour of your forum.
As far as I know, pretty much any (I’d bet on 99+%) https site will redirect all http requests to the https one.
The reverse does not hold true.
Meaning that linking to http://example.com is almost never a problem, since you end up on https://example.com anyway.
Like @Stephen , I think you might be focussing on the wrong part. As far as I know, having a <a href="http... link will not trigger the mixed content warnings.
This error should only be triggered by embedding non-https content into your https site. So loading external images could be a culprit, or embedding a third party script, something in a theme maybe?
Probably good to dive deeper into the browser console and see what triggers the error 
Let me explain. We have many users who type in our domain name in forum replies. We also embed forum replies on the main site so now I have some HTTP internal links instead of HTTPS. It’s not a big issue, but if I could make these HTTPS as well, that would be nice.
This is correct, it doesn’t trigger a mixed content warning
Is there anything I can do? Besides monitoring replies and perhaps writing a script to update URLS
I think you can use watched words to replace the bare hostname with the url
I didn’t realize this was possible but it sounds like a good idea. I’ll give it a try. In case anyone else is looking for this:
…/admin/customize/watched_words/action/replace
I think these two features may not be compatible. If I remember right, the markdown linkify tlds seems to take precedence and won’t allow the link to be swopped out by the watched words replace.
