Byte-range support for iOS compatibility

[beevelop]

There were already a few discussions about supporting Byte-range (content-range / partial-range) a few years ago. For now, tus and tusd don't implement support for it, which is understandable in the respective context:

• "Range" vs. "Content-Range" #2: "Range" vs. "Content-Range"
• Upload-Offset vs Range? #116: Upload-Offset vs Range?
• Upload to tusd behind HTTPS reverse proxy disconnects with EOF tusd#296: Upload to tusd behind HTTPS reverse proxy disconnects with EOF

The decision to not support Byte-range leads to another nasty side-effect on our "favourite" mobile operating system iOS: Media files (audio / video) stored on tus can not be played on iOS!

HTTP servers hosting media files for iOS must support byte-range requests, which iOS uses to perform random access in media playback. (Byte-range support is also known as content-range or partial-range support.) Most, but not all, HTTP 1.1 servers already support byte-range requests.

This renders tus unusable for e.g. storing video / audio notes through a mobile app and enabling the user to play the respective files without downloading them in advance.

[smatsson]

Hi,

This seems unrelated to this repository as tus is a protocol for file uploads and you are asking for are headers related to downloading files which is out of scope for the protocol.

I think your chances are better at getting a response if asked in the specific server implementation being used (e.g. https://github.com/tus/tusd).

[beevelop]

Thank you @smatsson for the heads-up. I close this one in reference to tus/tusd#432 👍