Safari 302 redirects in kh21.7 causing CORS errors due to missing access-control-allow-origin header

[jasons42]

Have an issue with a client site that I believe is related to this change.

Unfortunately I am troubleshooting from the client side so I cannot confirm any details of the streaming provider's configuration or infrastructure.

When I make a request using a Safari user-agent I receive a 302 but without any access-control-allow-origin header which is causing CORS errors:

curl -I 'https://cbfc.streamguys1.com/cbdaily.mp3' \
  -H 'User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 14_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Mobile/15E148 Safari/604.1' \
  -H 'Origin: https://www.clevelandbrowns.com' \
  -H 'Sec-Fetch-Mode: cors'
HTTP/1.1 302 Found
Connection: Close
Date: Fri, 28 Jun 2024 20:28:26 GMT
Content-Type: text/html
Location: https://cbfc.streamguys1.com/cbdaily.mp3?_ic2=1719606506350
Content-Length: 0

If I prepend Chrome/ to the user-agent header then I get a working response:

curl -I 'https://cbfc.streamguys1.com/cbdaily.mp3' \
  -H 'User-Agent: Chrome/ Mozilla/5.0 (iPhone; CPU iPhone OS 14_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Mobile/15E148 Safari/604.1' \
  -H 'Origin: https://www.clevelandbrowns.com' \
  -H 'Sec-Fetch-Mode: cors'
HTTP/1.1 200 OK
Server: Icecast
Connection: Close
Pragma: no-cache
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, private
Vary: Origin
Access-Control-Allow-Origin: https://www.clevelandbrowns.com
Access-Control-Allow-Credentials: True
Access-Control-Allow-Headers: Origin, Icy-MetaData, Range
Access-Control-Expose-Headers: Icy-Br, Icy-Description, Icy-Genre, Icy-MetaInt, Icy-Name, Icy-Pub, Icy-Url
Access-Control-Allow-Methods: GET, OPTIONS, SOURCE, PUT, HEAD, STATS
Date: Fri, 28 Jun 2024 20:28:51 GMT
Content-Type: audio/mpeg
icy-br: 64
ice-audio-info: channels=2;samplerate=44100;bitrate=64
icy-description: CB Daily Live Replay
icy-name: cbdaily.mp3
icy-pub: 1

Is it possible for the server to return a valid access-control-allow-origin header along with the 302?

[jssoderberg]

Hello Jason,

We're approaching this as 2 different questions to answer from the CDN side.

1. why is server response status returning a 302 when the session request combination is the Safari browser on the MAC OS with Icecast kh 22

and

2. why is the access-control-allow-origin absent in the header response for this same session request combination

For 1) we believe this is related to changes in how Safari is handling requests. We still get the 302 but have no playback issues after resolving 2). For 2) we explicitly defined the Access-Control-Allow-Origin as https://www.clevelandbrowns.com in the Icecast kh22 config using

<http-headers>
            <header name="Access-Control-Allow-Origin" name="httsp://clevelandbrowns.com" />
            <header name="Access-Control-Allow-Methods" type="static" value="GET, OPTIONS, HEAD" />
            <header name="Access-Control-Allow-Headers" type="static" value="Origin, X-Requested-With, Content-Type, Accept" />
      </http-headers>

and while we still see the 302 in a curl that proxies a Safari request we also see the Headers coming through and get playback at https://www.clevelandbrowns.com/audio/radio

curl -I 'https://cbfc.streamguys1.com/cbdaily.mp3' \
  -H 'User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 14_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Mobile/15E148 Safari/604.1' \
  -H 'Origin: https://www.clevelandbrowns.com' \
  -H 'Sec-Fetch-Mode: cors'
HTTP/1.1 302 Found
Connection: Close
Access-Control-Allow-Origin: https://www.clevelandbrowns.com
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept
Access-Control-Allow-Methods: GET, OPTIONS, HEAD
Date: Mon, 01 Jul 2024 22:34:48 GMT
Content-Type: text/html
Location: https://cbfc.streamguys1.com/cbdaily.mp3?_ic2=1719873288879
Content-Length: 0

[jasons42]

Hey @jssoderberg I meant this issue to be directed at the maintainers of icecast-kh, but thank you anyway for your reply, it looks like your fix is effective.

I am going to leave this issue open as I suspect it could be a problem for other deployments of icecast-kh where streams are being embedded cross-origin.