tus
Byte-range support for iOS compatibility
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:
- https://github.com/tus/tus-resumable-upload-protocol/issues/2: "Range" vs. "Content-Range"
- https://github.com/tus/tus-resumable-upload-protocol/issues/116: Upload-Offset vs Range?
- https://github.com/tus/tusd/issues/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.
I can understand that this is an inconvenience for you but tusd is not intended to serve content. Just as the tus protocol itself, tusd was built for handling file uploads and not file downloads. This decision helps us keep tusd maintainable and focused on one specific thing (which are file uploads in our case). For handling file downloads there are already other tools which take care of this job a lot better than we could. If you save files on disk, we recommend using nginx or some other proxy. If you use the S3Store or GCSStore, you can download the content from the bucket directly. In all of those cases, the byte ranges should be supported.
You can also support byte-ranges in your GET endpoint, which tus does not document and you are thus free to implement your required functionality. IOS players need not even be aware of the POST / PATCH / etc endpoints tus creates.
Yes, you are correct, @RubenGarcia. The tus protocol does not prevent the support of byte range requests. However, supporting this feature is not in line with the goals that we have/had for tusd. We want tusd to focus on uploads and not on downloads, which it is not optimized for.
That's what I'm saying. I meant beevelop can support byte-ranges in non-tus mandated endpoints. I did not mean for the tus protocol to be modified. You (Acconut) can add something like this to the documentation: "The definition of download endpoints is outside of the scope of the tus protocol", if it is not written explicitly there yet.
Thanks for the clarification, @RubenGarcia. In that case, I misunderstood your comment :)