Hi @redfoc,
The preview page has a small bit of logic in it; if the demo URL from the author is plain HTTP, the preview page is served over plain HTTP. If the visitor accesses the page via HTTPS, they are redirected to the plain HTTP version. The same is true of demo URLs using HTTPS; the preview page is served over HTTPS and visitors using plain HTTP are redirected to the HTTPS version. This ensures that there are no mixed-content-warnings from the browser, and that the iframe target is actually loaded.
The issue you’re seeing is because your site is performing some strange redirects. When accessed as originally mentioned, over HTTPS but without a trailing slash, your site redirects to plain HTTP (!) with the trailing slash:
$ curl -I https://cdn.redfoc.com/demo/onet
HTTP/2 301
location: http://cdn.redfoc.com/demo/onet/
That’s unexpected, and what’s causing the problem here. Our site sees the HTTPS in the demo URL and serves the page over HTTPS, but then the redirect causes your site to be served over plain HTTP, and the browser’s security model refuses to load it (error message: “The page at … was loaded over HTTPS, but requested an insecure frame ‘http://cdn.redfoc.com/demo/onet/’. This request has been blocked; the content must be served over HTTPS.”)
Following that redirect takes us back to HTTPS, this time with a trailing slash:
$ curl -I http://cdn.redfoc.com/demo/onet/
HTTP/1.1 301 Moved Permanently
location: https://cdn.redfoc.com/demo/onet/
If we follow that redirect, we finally get a successful response from your server:
$ curl -I https://cdn.redfoc.com/demo/onet/
HTTP/2 200
Whatever is performing that first redirect should be updated to use HTTPS, not plain HTTP. Using an HTTPS link with the trailing slash (as @baevox suggested) also works.
