We use an NSURLProtocol subclass to handle the requests made by the iOS media player for HLS playlists (m3u8 files). The actual m3u8 files lie on a remote server, so are fetched by our custom protocol handler and then fed back to the player. However handling HTTP error codes such as 404 has always been tricky, since the player typically won't take well anything other than 200 OK for a response. For instance upon getting a 404 error, the player would be expected to skip the missing playlist and just continue playing with the other variants, which is exactly what it does when NOT using a custom protocol but simply plain HTTP. However when the player receives the same error responses via NSURLProtocol, typically playback will fail soon after, in one way or another.
We already had this issue 2 years ago and posted on this thread :
https://devforums.apple.com/thread/183160
From iOS 6.0 to iOS 8.x we managed to find some workarounds to get this to work as expected. Mainly we found out that sending an HTTP 200 OK together with a 1 char response body through the NSURLProtocol subclass was equivalent to (or shall we say, had the same effect as) sending a 404 error via HTTP.
However, on the iOS9 betas not even this trick works anymore. Whether the NSURLProtocol subclass sends back an actual error response or an invalid playlist with status code 200, it doesn't make a difference. The player will abort playback right away in both cases. Still, when using plain HTTP, it works just as expected.
Same behaviour happens when using AVAssetResourceLoaderDelegate.
Filed a radar for this issue (21961566), but yet no reply.
Any help you could provide would be greatly appreciated.