I'm confused on what information the HEAD request gives after a chunk has failed. Suppose a client concurrently uploads chunks 1, 2, 3, 4 and 5; chunks 2 and 4 fail, and the rest work. What information does the HEAD give to tell the client that it needs to re-send the data that was in chunks 2 and 4? Wouldn't it make more sense for the client to store the success of each of its chunk uploads?
I'm also not seeing how the client indicates that the upload is complete. It could be done server-side, by just detecting when a file has no more holes in it, but that seems hacky. Holes can also be useful; suppose I make a 32GB .vmdk file (non-sparse) and put 2GB of data on it. If the server can support holes, then I can upload (and the server only has to store) about 2GB of data; if the server can't support holes, then I'll have to upload a bit more data (assuming compression), and the server will have to store a lot more data. If there were some final message the client could submit to the resource saying "I'm done, commit it!", I think the protocol would be a bit more complete.
Lets say the whole file is 1000 bytes and each of the five chunks is 200 bytes. If 2 and 4 have failed, then the HEAD would return with a Range header like this:
Range: bytes=0-199,400-599,800-999
The client would then know it had to resend bytes 200-399 and 600-799 (namely parts 2 and 4). If the chunks only partially failed (say 100 bytes of each chunk was received), the HEAD might even return something like this:
Range: bytes=0-299,400-699,800-999
So now the client knows it only has to resend bytes 300-399 and 700-799 (only the last 100 bytes of chunks 2 and 4).
Technically the Range header isn't valid in an HTTP response (something they are aware of), but conceptually I think the idea works fairly well.
Disclaimer: I'm a friend of the main author and have been peripherally involved (mostly watching from the sidelines) in this project.
Valid points, IMO. Those sound like use cases that might not have been contemplated originally (the idea for the spec grew out of the author's work here: https://transloadit.com).
That said, the spec, and the code around it are both still very much evolving, and are welcoming of input. You can join us on GitHub or in #tusio on Freenode.
I'm also not seeing how the client indicates that the upload is complete. It could be done server-side, by just detecting when a file has no more holes in it, but that seems hacky. Holes can also be useful; suppose I make a 32GB .vmdk file (non-sparse) and put 2GB of data on it. If the server can support holes, then I can upload (and the server only has to store) about 2GB of data; if the server can't support holes, then I'll have to upload a bit more data (assuming compression), and the server will have to store a lot more data. If there were some final message the client could submit to the resource saying "I'm done, commit it!", I think the protocol would be a bit more complete.