Youtube API in IE9 and lower

Question

I'm using the Youtube API (https://developers.google.com/youtube/v3/?hl=en ), in particular: playlists, playlistItems and channels to load.

This works great in all browsers,e xpect IE9 and lower. Here I always get a "No Transport" error.

This is a simple sample code:

<!Doctype html>
<html>
<head>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>Youtube API Test</title>
</head>    
<body>
    <code>    
    </code>    
    <script src="Scripts/jquery-2.1.4.js"></script>  
    <script>
        $.ajax({
            cache: false,
            type: 'GET',
            crossDomain: true,
            url: 'https://www.googleapis.com/youtube/v3/playlistItems',
            contentType: 'application/json; charset=utf-8',
            dataType: 'json',
            success: function (data) {
                $('code').text(JSON.stringify(data, null, 4));
            },
            error: function (err) {
                $('code').text(JSON.stringify(err, null, 4));
            }
        });
    </script>
</body>
</html>

(Note I remove the parameters, in Chrome and FF this returns a youtube error, in IE a "No Transport" error).

I tried using the xdomain plugin (https://github.com/jpillora/xdomain)

and the XDomainRequest plugin (https://github.com/MoonScript/jQuery-ajaxTransport-XDomainRequest#instructions)

as suggest here, with no success. Anything I am missing, does this work for anybody else?

score 0 · Accepted Answer · edited May 23 '17 at 11:44

The problem is, that you can't make ajax call from an http Site to an https Service!! Esle all examples I found fail:

Requests must be targeted to the same scheme as the hosting page

This restriction means that if your AJAX page is at http://example.com, then your target URL must also begin with HTTP. Similarly, if your AJAX page is at https://example.com, then your target URL must also begin with HTTPS.

It was definitely our intent to prevent HTTPS pages from making XDomainRequests for HTTP-based resources, as that scenario presents a Mixed Content Security Threat which many developers and most users do not understand.

However, this restriction is overly broad, because it prevents HTTP pages from issuing XDomainRequests targeted to HTTPS pages. While it’s true that the HTTP page itself may have been compromised, there’s no reason that it should be forbidden from receiving public resources securely.

Worst of all, the Same Scheme restriction means that web developers testing their pages locally using the file:// scheme will find that all of the XDomainRequests are blocked because file:// doesn’t match either http:// or https://, which are the only valid target schemes (point #1). To workaround this issue, web developers must host their pages on a local web server (e.g. IIS, the Visual Studio hosting server, etc).

Source: http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx

HTTPS with Visual Studio's built-in ASP.NET Development Server: HTTPS with Visual Studio's built-in ASP.NET Development Server

Related on SO: JavaScript cross-domain call: call from HTTP to HTTPS