Probably impossible to get around this with old threads, and for new threads, to get the green SSL icon, you would have to insist on https:// links only.
Enabling SSL will result in many threads being marked on the browsers as insecure. To get the proper green SSL icon in your address bar, everything on the page has to be SSL. If there are links to non-ssl images, the page does not get the green SSL icon, and if you left click on the greyed icon, it will say "This connection is not protected".
If you look into the details, it will say something like "This site has unprotected content".
If there is a link to an image on a remote site, the address bar SSL icon will be green as long as the remote image address is also SSL.
Probably impossible to get around this with old threads, and for new threads, to get the green SSL icon, you would have to insist on https:// links only.
Edit: many users have uploaded images, and then posted the image address into their post to get the full sized image. All of these addresses start with "http://www.eevblog.com/....", so they will force to SSL icon to grey. It may be possible to write a script to find these links, along with links to other posts, and turn them into relative addresses to make them SSL compatible.
Enabling SSL will result in many threads being marked on the browsers as insecure. To get the proper green SSL icon in your address bar, everything on the page has to be SSL. If there are links to non-ssl images, the page does not get the green SSL icon, and if you left click on the greyed icon, it will say "This connection is not protected".
If you look into the details, it will say something like "This site has unprotected content".
If there is a link to an image on a remote site, the address bar SSL icon will be green as long as the remote image address is also SSL.
Probably impossible to get around this with old threads, and for new threads, to get the green SSL icon, you would have to insist on https:// links only.
Edit: many users have uploaded images, and then posted the image address into their post to get the full sized image. All of these addresses start with "http://www.eevblog.com/....", so they will force to SSL icon to grey. It may be possible to write a script to find these links, along with links to other posts, and turn them into relative addresses to make them SSL compatible.
This is not entirely correct, links to other sites do not have to be https, only embedded content, such as links to youtube, which is handled by the forum dynamically so this is no issue. ...
Again, serving the header 'Upgrade-Insecure-Requests' will make your browser redirect an insecure URL to https. We can also server side redirect traffic to https for when this occurs and the client's browser doesn't support the upgrade header (which all do these days)
Again, serving the header 'Upgrade-Insecure-Requests' will make your browser redirect an insecure URL to https. We can also server side redirect traffic to https for when this occurs and the client's browser doesn't support the upgrade header (which all do these days)That assumes that you can replace "http://" with "https://" in a URL and get the same content.
On the server where I have installed SSL (with a letsencrypt certifiace) http and https yield completely different sites (in fact http:// is internal only and blocked at the firewall so it won't get you anything).
On the server I use to host my embedded images for forum posts that I have made I only have http configured so https will not get you anything.
I am sure that there will be a lot of other embedded image links where just switching to https will not work - I know that it will mean browser warnings but I would leave embedded URLs as they are.
Please note Google Translate does *NOT* work on https pages. Forcing https, other than as a per-user preference will seriously disadvantage any users who use it due to poor comprehension of English.
http is now redirecting me to https and the Chrome info box shows
URLs only get upgraded if the host the url is served from specifies the "Content-Security-Policy: upgrade-insecure-requests" header, which I assume you are not.
URLs only get upgraded if the host the url is served from specifies the "Content-Security-Policy: upgrade-insecure-requests" header, which I assume you are not.Surely putting upgrade-insecure-requests on eevblog pages would make the browser try to fetch any embedded link over https, not http - nothing to do with my server.
I need to read the documentation; I only had a glance but it seems to contradict itself on whether 3rd party links are affected.
Megacorp, Inc. isn’t quite ready to deliver Strict Transport Security headers [RFC6797], but does want to keep users on secure pages when possible. Happily, this comes for free with upgrade-insecure-requests. That is, they’re already delivering pages with the following header:
Content-Security-Policy: upgrade-insecure-requests
This allows user agents to treat the following HTML code:
<a href="http://example.com/">Home</a>
as though it had been delivered as:
<a href="https://example.com/">Home</a>
Links to third-party sites will not be upgraded. That is, the following HTML code:
<a href="http://not-example.com/">Home</a>
won’t be upgraded.
Please see: https://www.w3.org/TR/upgrade-insecure-requests/#example-navigation
This automatically upgrades all insecure resource requests from their pages to secure variants, allowing a user agent to treat the following HTML code:
<img src="http://example.com/image.png">
<img src="http://not-example.com/image.png">
as though it had been delivered as:
<img src="https://example.com/image.png">
<img src="https://not-example.com/image.png">
Please see: https://www.w3.org/TR/upgrade-insecure-requests/#example-navigation
Yes, but I'm struggling to see any difference between example 2 (which you quote) and example 1 which saysQuoteThis automatically upgrades all insecure resource requests from their pages to secure variants, allowing a user agent to treat the following HTML code:
<img src="http://example.com/image.png">
<img src="http://not-example.com/image.png">
as though it had been delivered as:
<img src="https://example.com/image.png">
<img src="https://not-example.com/image.png">
PS: "Insert quote" is broken.
The difference is links vs embedded resources, I had missed this and will need to be addressed.
User agents will upgrade requests, as described in §1.2.1 Non-navigational Upgrades, rewriting the URL as https://cdn.example.com/image.png. As the server doesn’t respond to secure requests, this results in a network error.
There is no fallback in this scenario: the user agent acts just as though the request had been intentionally made, and the request fails.