AVPlayer fails to send a cookie for the same domain after 302 redirect

Question

I am using iOS AVPlayer to play a HLS stream. In the beginning of the HLS session, when I receive index.m3u8 URL in response to create AVPlayerItem, the response also sets a cookie which is required for session based auth. Say this cookie name is myCookie and it is created for domain ".myhost.com ". Now everything works fine and the player sends myCookie to download ts chunks from xxx.myhost.com/stream. As the playback goes on, the playlist is getting updated eventually and the player downloads updated playlist. Sometimes the updated playlist contains a ts chunk to download from URL with another host. Hence while trying to play the chunk with the different host, the player requests xxx.someotherhost.com to download the chunk. This results in response 302 redirect with location:xxx-abc.myhost.com/ads. Apparently AVPlayer doesn't send myCookie while requesting a chunk from someotherhost.com since it doesn't match myCookie's domain. But the problem is after redirection to xxx-abc.myhost.com/ads, AVPlayer doesn't send myCookie even though the domain for the redirection URL is myhost.com too that matches with cookie's domain.

Please note that the redirection URL domain is same as original stream domain and also same as myCookie's domain too. Since AVPlayer doesn't send the cookie to download chunks after redirection, the ts chunk requests fail with 403 Forbidden (No Token)

Am I doing something wrong here or this just looks like a bug in iOS AVPlayer?

Is there a way to fix this problem? Please share your thoughts.

Answer 1

Make a sample that demonstrates the issue, file a bug report. Then create a DTS incident mentioning the Radar and that you are looking for a workaround for what you believe to be a bug.

This opens up two possibilities:

• an engineer can confirm the bug - if it's unknown they'll fix it, if it is a duplicate you can request status info on the original
• DTS is knowledgeable enough and has the ability to inquire on the actual AV engineers what to do as a workaround

This way you spend less time looking where you probably will not get any other answer than this.