tus-resumable-upload-protocol

eally client-server oriented, which is what this protocol is trying to solve. Rsync has many the same disadvantages as FTP listed above. As for a single TCP connection with no traffic shaping, tus support splitting up a file into multiple parts and uploading them in parallel (as regular tus uploads, so profiting from checksums, retries, and resumability) and stitching them together on the server-side by issuing a 'concat'. This means you can have as many connections as you like, and the individual chunks can complete in any order as well. Traffic shaping is not part of the protocol. By default tus should saturate available connections. That said we're writing down some recommendations in a separate 'developer guide' document that offers best practices for implementing and deploying tus, traffic shaping could be part of it. Feel free to weigh in here https://github.com/tus/tus-resumable-upload-protocol/pull/68

ven't specified GET requests yet, but a server could stream an upload in this case until all bytes have been received. The reason I brought up a GET request is because "the metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request." (section 9.4 of RFC2616) If you haven't got all 100 bytes yet, your GET request can't return a Content-Length of 100, thus your HEAD request shouldn't be returning 100 either. I would have thought you would return whatever content you had available (hence the 70 bytes), but if you want to support parallel transfers, then a 416 error response indicating the available ranges might make more sense.

stead. Good point, I'll investigate on that: https://github.com/tus/tus-resumable-upload-protocol/issues/... > And the Content-Length should surely be 70, since that's how much content would be returned if this was a GET request. It's 100. We haven't specified GET requests yet, but a server could stream an upload in this case until all bytes have been received. Anyway, this is awesome feedback - thank you so much!

Nginx (when the upload works correctly) it won't send anything to the backend until it has the complete data, is this the same if the connection cut half way through? NGINX is somewhat unsuitable as a proxy for file uploads due to the buffering you mentioned. Ideally people will implement the tus protocol as an NGINX Addon like this one: http://www.grid.net.ru/nginx/resumable_uploads.en.html Meanwhile clients are free to choose a small chunk size for individual PUT requests (e.g. 1 MB), which will allow them to still have resumability (in 1 MB intervals) without changing their architecture. Last but not least, we'll implement the tus protocol for our commercial uploading service, transloadit.com. So I'm reasonably optimistic that NGINX won't be a major hurdle for the adoption of the protocol.