Blog

Yes, oddly enough, this seems to be the case! A while ago, we noticed something really interesting on tus.io, our open protocol for resumable uploads: a comment from Jaroslaw Wasilewski mentioned that tus was being used to support firefighting rescue operations. Now that is exciting news!

While we did set out to make the world a slightly better place by making uploading more reliable for everyone, this is certainly not what we had in mind. We were very interested to learn more about this, so we invited Jaroslaw to sit down with us for a virtual cup of coffee and asked him to tell us a little more about the system they have developed – and how they are using tus for it.

With their Simple Storage System (S3), Amazon Web Services has built one of the major providers of cloud storage for applications ranging from small side projects to enterprise systems. Since the introduction of flexible storage back-ends for the official tusd server, an integration with S3 has been a much desired feature by our users. We are happy to announce that we are now able to deliver on this request. During the time it took to create this, we had to deal with various peculiarities of Amazon’s service and were able to gain a lot of experience. In this post, we want to focus on the downsides of building a tus server on top of S3 and share some of our recently acquired knowledge with you.

As time progresses, we share ever larger media files from our phones and desktops. More than often, however, complications arise during this process. Whether it is through servers misbehaving or mobile users switching to a WiFi connection, the outcome is the same: ‘upload interrupted’.

Here’s a quick update on the status of the project.

More than a year ago the last release, 0.2.2 was published. Now the final 1.0 release is just around the corner introducing breaking changes and a lot of new features.

This is a minor protocol release:

This is a minor protocol release:

After releasing our first draft a few weeks ago, we received an incredible amount of feedback and suggestions. Based on this feedback as well as discussing the problems with the IETF HTTPbis Working Group, we identified a few key issues with v0.1 of the protocol:

• PUT requests are not appropiate for transfering partial resources
• The Content-Range and Range headers are not meant for resuming an interrupted resource transfer.

After lots of careful thinking, we came up with a new approach that uses:

tl;dr: We are happy to announce version 0.1 of the tus resumable upload protocol and are interested in your feedback!

With mobile devices becoming the dominant source of user generated media files, reliable file uploading through unreliable mobile networks has become an important issue for anybody interested in content acquisition.

Reliability here means the ability to detect network errors, and resuming an upload without having to start from the beginning. In many scenarios this can mean the difference between a file reaching your application, or the user giving up in frustration.

Hey everybody, we’re starting a new blog here to discuss file uploading, and the protocol we are working on. So keep an eye on this space!