issue on Safari macOs Sierra

al404 commented 7 years ago

I'm jPlayer to stream a shoutcast stream but after upgrading to macOS Sierra it doesn't work any more on Safari

I'm using circle player, but i tried with package examples on first load it seems to work as soon that i apply changes even reloading original version is not working anymore

I get this error

Blocked script execution in 'http://192.168.1.2/0.TEST/jPlayer-2.9.2/examples/blue.monday/demo-08.html' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.

leoandrews commented 7 years ago

This is a problem we are seeing too. Would be good if the devs could take a look at this.

al404 commented 7 years ago

did you have any chance to make some test? because since i posted here ( and on other platform ) I didn't get any answer.

leoandrews commented 7 years ago

I don't know if the developers are active on this project any more. Last commit was 2 years ago.

al404 commented 7 years ago

i just got a step furore since in 10.12.1 the error message is changed now it says:

Sandboxing 'http://my.steam.com:5555/;stream/1' because it is using HTTP/0.9.

i checked the HTTP response and it says GET /;stream/1 HTTP/0.9

not sure if is possible to avoid sandboxing with HTTP/0.9

leoandrews commented 7 years ago

This is what needs to be ascertained.

A question - are you using a Shoutcast 1 or Shoutcast 2 server?

al404 commented 7 years ago

SHOUTcast Server Version 1.9.8/Linux

leoandrews commented 7 years ago

So the hunch is that it's a problem with old versions of Shoutcast. In fact if you look on Shoutcast.com you can see they are deprecating Shoutcast v1. Try running a Shoutcast 2 server and share with us how you get on

lukasz-zaroda commented 7 years ago

@al404 Do any streams on http://shoutcast.com/ work for you on Sierra?

al404 commented 7 years ago

i tried some of them but they don't work i always get the same error messaggero about HTTP 0.9 after that the page is like blocked and i need to open in an other window to try again

lukasz-zaroda commented 7 years ago

I'm also trying to solve this problem. I think this killed Shoutcast, and possibly some other streaming servers. From what I researched, the shoutcast's stream doesn't have proper HTTP headers, rather something like this:

ICY 200 OK
icy-notice1:<BR>This stream requires <a href="http://www.winamp.com/">Winamp</a><BR>
icy-notice2:SHOUTcast Distributed Network Audio Server/Linux v1.9.8<BR>
icy-name:My Stream Name
icy-genre:Alternative
icy-url:http://MYURL
content-type:audio/mpeg
icy-pub:0
icy-br:160

Which is being interpreted as HTTP/0.9 for some reason, and the mentioned change started to block it. I don't have solution for this yet.

al404 commented 7 years ago

i did some test with chrome ( on mac ) and this extension https://chrome.google.com/webstore/detail/live-http-headers/iaiioopjkcekapmldfgbebdclcnpgnlo

loading my stream ( mystream.net:5555 is a placeholder for real domain ) http://radio.mystream.net:5555/;stream/1

and i get a HTTP 0.9

sometimes you have to try multiple times or wait before getting the response but in my case is

GET /;stream/1 HTTP/0.9 Host: radio.mystream.net:5555 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8 Accept-Encoding: gzip, deflate, sdch Accept-Language: it-IT,it;q=0.8,en-US;q=0.6,en;q=0.4 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36

HTTP/0.9 200 OK

lukasz-zaroda commented 7 years ago

I think this is a browser's interpretation of headers. I did wget on the stream and raw data shows what I wrote. Browser is simply interpreting it as HTTP/0.9 .

al404 commented 7 years ago

witch address are you getting with wget? i slide mine with /;stream/1 ?

I just tried from an Ubuntu virtual machine from shell $ wget -v http://radio.mystream.net:5555/;stream/1

( i translate to english ) Request HTTP send, waiting for reply... 200 No header, i presume HTTP/0.9

lukasz-zaroda commented 7 years ago

Yep, everything is as expected. "No header, i presume HTTP/0.9" so HTTP/0.9 is presumed when there are no headers (or if headers cannot be understood). I guess that's the convention. What are you looking for?

lukasz-zaroda commented 7 years ago

If you want to see the same headers I gave example of, just run wget, close it shortly, and edit the file it downloaded.

Those are not technically HTTP headers, that's why they are a part of the content.

al404 commented 7 years ago

i guess the only solution would be a fix on safari but i doubt or on shoutcast server

lukasz-zaroda commented 7 years ago

I reported it to the Webkit team, and reportedly Apple is aware of the problem, and is looking into it, so there is a hope we will get this sorted out :) . See: https://bugs.webkit.org/show_bug.cgi?id=164329

al404 commented 7 years ago

thanks hope they will fix it

al404 commented 7 years ago

now it seems that similar issue is showing with chrome 55 mine is ( 55.0.2883.95 (64-bit) ) but other people find the issue even on PC

lukasz-zaroda commented 7 years ago

I don't think it will be fixed soon enough, with Chrome damage is already too great. We moved to Shoutcast 2. The workaround to this currently would be to have streams only on port 80, with different IP per stream, but I would advice you to upgrade to Shoutcast 2 instead.

leoandrews commented 7 years ago

This is what I'm recommending to those who ask me too. It's a workaround for sure, but actually Shoutcast 1 is 18 years old so it's an ancient technology and people probably should be upgrading as a matter of course.

al404 commented 7 years ago

Thanks, we have 3 website that use jPlayer and have the same issue because they are all hosted for streaming on the same provider that is on Shoutcast 1 If there is no other way i will tell them to ask for fix or evaluate a new provider

jplayer / jPlayer

issue on Safari macOs Sierra #380