> Is it possible that the data that is already there could be corrupt? TCP error correction should take care of this for most parts, but we're actively discuss

> Is it possible that the data that is already there could be corrupt? TCP error correction should take care of this for most parts, but we're actively discussing adding support for stronger guarantees: https://github.com/tus/tus-resumable-upload-protocol/issues/7 https://github.com/tus/tus-resumable-upload-protocol/issues/... > I'm also wondering how things like proxies deal with this. A lot of mobile networks have nasty transparent caching proxies in their network. That's a good question. A http proxy could always cause issues, but most proxies should leave POST/PUT/HEAD requests untouched. That being said, we won't freeze the protocol until we had a chance to try it against a variety of mobile networks, which is why we're already starting to implement an initial iOS client over here: https://github.com/tus/tus-ios-client https://github.com/tus/tus-ios-client (not ready yet, but keep an eye on it). > Also when uploading a file through 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 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.