Why are HTTP images not appearing in HTTPS application?

Question

I have secured (HTTPS) ASP.Net MVC 4 application that uses unsecured (HTTP) ArcGIS map services. These services are called using JavaScript to get relevant map images.

If I use HTTP for my app, everything works as expected. But if I use HTTPS, IE10 and Chrome do not display the requested map images (IE prompts to display unsecured content) but Safari shows the image, no questions asked.

As an example, say my application is https://app.mydomain.com and my map services are at http://gis.mydomain.com

I run fiddler and see the response as something like (removed some parameters to simplify): http://gis.mydomain.com/arcgis/rest/services/Energy/BaseService/MapServer/export?....&f=image but the image is not shown. If I enter this URL directly into my address bar, the expected image is shown.

There are no errors reported anywhere, including IIS 7.5 logs. I realize that mixed content is not ideal but I have no option at the moment. I have found lots of references to SilverLight with regard to this type of problem, but I am only using javascript and ASP.Net. I also compared the page source for both https and http - there is no difference.

Answer 1

While browsing a secure site, the browser will not load "nonsecure items" unless you (the visitor) authorize it.

The only way to solve this from server-side is by making the "nonsecure" content secure, by placing it under a https domain aswell.

Update:

By the way, if you don't specify the protocol in the content URLs, for exemple //gis.mydomain.com without specifying if it is http:// or https://, the browser will automatically assume the same protocol that was used to access the website to load this content too.

So if you access with http:// it will load the dependencies using http:// as well, and if you use https:// it will do the same.

Answer 2

Another way of getting around this is to proxy the insecure content via your (https) host. ESRI have some slightly out-of-date docco on this process (including an example ASP.Net proxy page) here, but most/all of it should still hold in the latest versions of the API. From memory, they recently (3.5?) made the proxy configurable on a per-service basis, which is very handy.

You can ignore the token-based authentication stuff in your case, all you're really looking for is to have the insecure content come through a secure host.