John's Blog: iOS Video Playback

November 10, 2016

Varios versions of iOS have a bug that prevents them from displaying video files on password protected Web sites. Here's what is going on...

The Quick Fix
There's a full explanation below, but if you just want to make videos work, open the Web Settings window in Rumpus, flip to the Options tab, and enable the "Allow QuickTime Anon. Downloads" option. This option, available in Rumpus 8.0.21 and 8.1 and later, works around the iOS Safari bug described below, at least for the most part.
Security Warning!
The problem is due to a failure of QuickTime to send authentication information when requesting files it is accessing for display. To work around the problem, Rumpus must deliver files that should normally be password protected in cases where the request does not include the username and password. If you run a server in an environment with high security standards, Maxum does not recommend enabling this option.
With that said, when the option is enabled, Rumpus still performs aggressive checks to try to ensure that files are served anonymously only when necessary and only during authenticated sessions. Because of these security checks, it is unlikely that data could be compromised in real-world use. But again, please only enable this option if the benefits of allowing iOS devices to view videos outweighs the potential for files to be viewed by unauthorized users, however slim that possibility may be.
The Bug
Apple has had this bug at least twice in the past, and we have reported it through the developer bug reporter again.
When you surf to a video in Safari, Safari does not download and display the video. Instead, when Safari recognizes a download as QuickTime-displayable content, it terminates the download and passes off the URL to QuickTime. QuickTime then requests the file and displays it. The problem in this case is that the QuickTime request does not include the session information or authentication that is sent in usual Safari requests. So, without session and authentication information in the request, Rumpus denies access to the file.
The correct solution to this problem is for QuickTime to send the same session and authentication information that Safari does when it requests a file. Apple has made this correction at least twice in the past, but how quickly the fix comes isn't always predictable, so we have implemented this work-around in Rumpus. The work-around, as described above, involves Rumpus attempting to match QuickTime requests to an active user session, making sure that Safari has recently attempted to access the same file, and then delivering the file using the credentials of the matched session.
Hopefully, Apple will correct this problem soon and iOS devices will once again be able to display password-protected video files, with or without the "Allow QuickTime Anon. Downloads" feature enabled. Until then, the option is available for those who need it. I hope you find it useful!

© Copyright 2017, Maxum Development Corp.