cdn-profiles.tunein.com uri over https

[bla-ckbox]

Hello

I use mopidy-iris over https.
Station image is not loaded, error:

Mixed Content: The page at 'https://*****.b-la.fr/iris/service-worker.js' was loaded over HTTPS, but requested an insecure resource 'http://cdn-profiles.tunein.com/s112350/images/logoq.jpg'. This request has been blocked; the content must be served over HTTPS.

Is it possible to provide the tunein station thumbail url in https to ensure compatibility?

Exemple:
Must be: https://cdn-profiles.tunein.com/s112350/images/logoq.jpg

Another exemple with mopidy-youtube, thumbail works, logo url is something like;
https://i.ytimg.com/vi/-zZbkPnBtS8/hqdefault.jpg

Thanks

[kingosticks]

Correct me if I'm wrong but there are browser CSP mechanisms to have this done automatically, aren't there?

[kingosticks]

The problem I have is that the Tunein does not provide any public documentation for this API and I don't know where we can explicitly request or find https versions of these resources. So while I can blindly replace http with https for these URIs, I've no idea if there will always be something available at that new URI. If I was to do this I guess I'd have to put it behind a config option that defaults to false. Unless we can find some info about the Tunein CDN provider which states they'll always have a https version.

[bla-ckbox]

I agree with you that the subject is poorly documented.
From a purely network point of view https only encrypts the http stream, and except for exception (ssl loadbalancing on different host) a virtual host with ssl support delivered exactly the same resource as via http.

I said to myself that a well designed API should return resources in https if we query it in https but it does not seem to be the case of https://opml.radiotime.com/

Finaly i made your sugested change at home:

def station_to_image(station):
    if station is not None and "image" in station:
        return Image(uri=station["image"].replace('http:', 'https:', 1))

it works for all the stations i listen to

[foxfabi]

I always use HTTPS because an HTTP page has no reason to complain if you decide to load some parts of it over HTTPS. Another possibility would be the use of protocol-relative URL (PRURL), but this technique is an anti-pattern.

[kingosticks]

These uris are not just used by web browsers so omitting the scheme, or using other browser specific tricks to workaround what is already a browser specific issue, is not an option.

[djmattyg007]

From a purely network point of view https only encrypts the http stream, and except for exception (ssl loadbalancing on different host) a virtual host with ssl support delivered exactly the same resource as via http.

While I completely agree that it would be ideal if TuneIn just returned HTTPS-only URLs, what you've stated here is simply not accurate. While it might appear to be the case for the majority of websites, there is absolutely nothing stopping someone from providing totally different responses on HTTP vs HTTPS, or even completely different URL paths or entire domains for HTTP vs HTTPS. It's simply not a trivial matter of rewriting URL protocols.