I've updated my bridges to support HTTPS and I've proposed a patch for squeezelite.
This change in RP allows direct HTTPS streaming when player supports it. It probably requires more scrutiny, so I'm submitting it for your review.
Particularly, I don't understand why you chose to use the $url parameter in parseDirectHeaders instead of $song->streamUrl (I had to make that change b/c $url points to radioparadise:// when direct streaming happens).
The overloaded "new" method is not invoked when the canDirectStream returns an url, which only happens if the player has the 'canHTTPS' attribute (because RP subclasses Slim::Protocol::Player::HTTPS), but I'm also wondering if I'm not missing something here. Is all what 'new' does necessary, except for setting the $sock's url to a valid HTTP target (which is done by canDirectStream if player supports HTTPS). It seems to me that bitrate & contentType are set by parseDirectHeaders anyway, so isn't that redundant?
I've updated my bridges to support HTTPS and I've proposed a patch for squeezelite.
This change in RP allows direct HTTPS streaming when player supports it. It probably requires more scrutiny, so I'm submitting it for your review.
Particularly, I don't understand why you chose to use the $url parameter in parseDirectHeaders instead of $song->streamUrl (I had to make that change b/c $url points to radioparadise:// when direct streaming happens). The overloaded "new" method is not invoked when the canDirectStream returns an url, which only happens if the player has the 'canHTTPS' attribute (because RP subclasses Slim::Protocol::Player::HTTPS), but I'm also wondering if I'm not missing something here. Is all what 'new' does necessary, except for setting the $sock's url to a valid HTTP target (which is done by canDirectStream if player supports HTTPS). It seems to me that bitrate & contentType are set by parseDirectHeaders anyway, so isn't that redundant?