We're currently discussing how to interpret RFC 2616 (http 1.1) for this here: https://github.com/tus/tus-resumable-upload-protocol/issues/...
If you have a better suggestions than using the Range header that will still allow clients to send multiple file chunks in parallel, I'd be very interested in it!
> Do you really need this info in the response anyway? The sender knows what they sent, and either it was entirely successful (a 2xx response) or it wasn't.
We don't need it for the PUT request, but we do need it for HEAD. Adding it to PUT is redundant, but simplifies the logic for clients who choose to upload multiple chunks in parallel.
> Also, if you're going to return a zero-length 200 response, you might as well use 204 No Content instead.
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!