Interesting issue Jonathan Snook ran into when switching a site over to HTTPS. Even though images from HTTP resources should still get loaded by the browser (as they are Passive Mixed Content, and thus tolerated), they weren’t:
After some digging, I noticed that the images that werenβt loading were those defined using the <picture> element. Surely thatβs not expected behaviour, is it? Turns out, it is.
As Jonathan found out the hard way, the Mixed Content Spec does actively block images, but only when they are defined in an imageset β which is the case for <picture>.
Of course it is recommended to migrate all resources to HTTPS and not to run with Passive Mixed Content because browsers, today, will not give your site the green checkmark and, one day, will most likely block Passive Mixed Content too.
If an HTTPS page includes content retrieved through regular, cleartext HTTP, then the connection is only partially encrypted. […] When a webpage exhibits this behavior, it is called a mixed content page. (src)
As modern browsers block most Mixed Content from being downloaded this may leave your HTTPS-enabled website broken.
To check this I wrote a little PHP CLI app to scan an HTTPS website for Mixed Content. The script starts crawling at a given URL, and processes the page:
All contained img[src], iframe[src], script[src], and link[href][rel="stylesheet"] elements are checked for being Mixed Content or not.
All contained a[href] elements linking to the same or a deeper level are successively crawled and scanned for Mixed Content.
The script itself will start scanning and give feedback whilst running. When Mixed Content is found, the URLs will be shown on screen: