Contrast to HTTP transfer chunked encoding


#1

I work on an application that uses flow.js. I am shopping around for alternatives so that we can implement in a Java client or use an existing library.

This article (https://gist.github.com/CMCDragonkai/6bfade6431e9ffb7fe88) mentions “transfer-encoding: chunked” requests and I was wondering whether you agree with the articles assessment or if there were other reasons why you initiated TUS?


#2

As the article correctly says, chunked transfer encoding brings streaming content to the HTTP protocol which it previously did not easily support. However, the tus protocol was initiated in order to provide a very different feature and that is resumable file uploads. With resumability we mean that an upload can be interrupted at any given time, either willingly by pausing the upload or unintentional by a connection drop, and the client will be able to continue the upload afterwards at the point were it previously stopped.

This is a feature that HTTP, even with chunked transfer encoding, does not provide on its own and every server would have to implement this on its own. If the connection is interrupted during a HTTP request, you have to resend the original HTTP request including the entire request body, which can be expensive if you are talking about big files, such as videos.

Finally, it may be interesting to know that many tus client libraries leverage chunked transfer encoding as it brings many benefits to the HTTP protocol, so it’s possible to use both.

I hope this helps you understand the difference between tus and chunked transfer encoding.