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.

Compatriot

This may or may not help... Our authentication service returned a cookie that we then use to keep users signed in. We need to use the same cookie for multiple domains, so when we get the initial response, we duplicate the cookie, change the domain on the duplicate, and add that to the shared cookie storage. Seems as though you might do a similar thing to prevent the initial redirect if you can detect the new host, find the existing cookie, and then duplicate the data just changing the domain? – Berger

Matt, thanks for quick response however I tried the same already before posting this question. But the duplicate cookie I created for different domain somehow was not picked up by AVPlayer while requesting chunks from that different domain URL that results in 302. Also the main question here is the AVPlayer is getting redirected to the domain for which cookie already exists but why AVPlayer doesn't send it after redirect. The original cookie has domain .myhost.com and after redirection, the host being requested is .myhost.com only with different subdomain but the cookie is not sent out. – Compatriot

Have you filed a bug report with Apple? It sure sounds like they're forgetting to check the cookie jar during a redirect. – Aleece

vipw, not yet. I want to be pretty sure first if there is a workaround/hack using which this can be fixed in client. Otherwise last resort is filing a bug report with Apple. – Compatriot

indiantroy, the only workaround I can think of would be to use a local http proxy that would cache the client cookies and re-insert them after the redirect. It's a lot of effort to workaround a fairly small bug. – Aleece

If you'd like, I could write up the repairing proxy idea as an answer. At least it's a sort of solution to the problem, without really being a fix. – Aleece

vipw, thanks for the offer to help. I looked into that solution already before posting the question. Since I am looking for a permanent solution without a proxy, I am not excited about that solution sadly. I have filed a bug report with Apple too. – Compatriot

I might be having a similar issue. Does it only happen on the device, not the simulator? – Cairo

@CarlVeazey, this happens on iOS 7 Simulator even without different domains. It used to happen on iOS 5 Simulator too but then they fixed on iOS 6 Simulator. – Compatriot

@Compatriot Ah, OK. My issue is exclusive to the device, and doesn't involve redirects or different domains, so I guess maybe they aren't too closely related, at least. Hope you find a resolution! – Cairo

@Compatriot any update on this? Did you find any solution or get any feedback from apple? – Craunch

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.

Ontogeny