Mixed content warnings are always bad. It’s possible to add cookies via http that are used with the next https connection. So forum software should never initiate http connections.
Especially in a forum that talks about “My certificate is wrong” or “I have content warnings” (certificate is correct, but there is mixed content - first certificate with that domain, links must be updated).
I know. But it’s possible that a man in the middle uses such a browser initiated http connection to add a cookie vie http. Later, the cookie is sent from the browser via https - and the man in the middle knows the session cookie.
That works. The http status (404, 301, 410, 500) isn’t relevant.
That’s
not a problem. The favicon isn’t a user initiated link, the user adds only the http link to the site without https.
Simple solution: No preview if the destination is http. Then it’s not required to load the favicon.
That’s not the problem. That would be a browser bug.
A man in the middle can add a cookie in the http://alohadentalgroup.com connection with the domain alohadentalgroup.com, with the known name of a session cookie (if exist, didn’t checked that) of that domain (not from the forum domain).
If a user - later - uses the login of https://alohadentalgroup.com to manage that domain, that cookie (created via http) is sent back via https.
This is one critical (and often unknown) cookie feature.
That’s one reason Prefix cookies are created. Cookies starting with __Secure- or __Host-, https is required. Then this isn’t longer possible. Same with Preload (but most sites don’t use HSTS and aren’t preloaded).
See (2017)
or other links.
PS: My “check your website” (see my profile) has a page with some samples. And a small demo. A cookie created via http and sent back via https. Via http it’s not possible (with a modern browser) to create the __Host- cookie. But Prefix-Cookies are rare.