What makes an iframe load http content even though src is https?

0
votes

my vue component is loading external content in an iframe 

<iframe src="https://external-site" />

works fine locally, but once I deploy to my https site

Mixed Content: The page at 'https://my-site' was loaded over HTTPS, but requested an insecure frame 'http://external-site'. This request has been blocked; the content must be served over HTTPS.

network tab shows 2 requests, both have status (cancelled), and both have request url is HTTPS..

1
vue.jshttpsmixed-content
Perhaps https://external-site issues a redirect to http://external-site? Is one of those requests in your console a 301/302 status code? - ceejayoz
I think you're gonna have to link us to an example of it. - ceejayoz
Browsers follow redirects automatically. The Network tab’s not gonna show you a 301 - sideshowbarker
https://tithe.ly/give?c=1401851 (notice the missing trailing slash) redirects to http://tithe.ly/give/?c=1401851 (notice the http, no-https). That’s where the browser stops and emits that error. But http://tithe.ly/give/?c=1401851 redirects to https://tithe.ly/give/?c=1401851 (notice the trailing slash). So the bottom line is, it will work if you change the request URL in your source to https://tithe.ly/give/?c=1401851 (that is, with the trailing slash included). - sideshowbarker
That server has a general misconfiguration problem in that if a https URL like that lacks a trailing slash and gets redirected to a URL with the trailing slash added, the server should not be redirecting it to an http (non-https) URL but instead to an https URL. - sideshowbarker

1 Answers

5
votes

For general cases like redirecting URLs without trailing slashes to corresponding URLs with trailing slash added, some servers have broken configurations with http: hardcoded in the initial redirect — even if the server has other configuration that subsequently redirects all http URLs to https.

For example, the case in the question had a URL https://tithe.ly/give?c=1401851 (notice the missing trailing slash) that was redirecting to http://tithe.ly/give/?c=1401851 (notice the http, no-https). So that’s where the browser stopped and reported a mixed-content error.

That http://tithe.ly/give/?c=1401851 redirected to https://tithe.ly/give/?c=1401851 (https) in this case. So the fix for the problem in the question would be to change the request URL in the source to https://tithe.ly/give/?c=1401851 (with trailing slash included).

Worth noting: if you were to open https://tithe.ly/give?c=1401851 (no trailing slash) directly in your browser, the chain of redirects described in this answer just happens transparently and so it looks superficially like the original URL is OK. That can leave you baffled about why it doesn’t work.

Also worth noting: when you check the Network pane in browser devtools, it’s not going to readily show you the redirect chain, because as noted above, browsers follow redirects transparently — except when the chain has a non-https URL, causing the browser to stop, breaking the chain.

So the general troubleshooting/debugging tip for this kind of problem is: Check the request URL using a command-line HTTP client like curl, and step through each of the redirects it reports, looking carefully at the Location response-header values; like this:

$ curl -i https://tithe.ly/give?c=1401851
…
location: http://tithe.ly/give/?c=1401851
…
$ curl -i http://tithe.ly/give/?c=1401851
…
Location: https://tithe.ly/give/?c=1401851