I think some of your responses aren't quite right. For example, in response to the first PUT, you have:
HTTP/1.1 200 Ok
Range: bytes=0-99
Content-Length: 0
But the Range header surely can't be used here, since it's a request header and this is a response. A Content-Range header wouldn't be any more appropriate, since you're not actually returning any content (of any amount). 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.
Also, if you're going to return a zero-length 200 response, you might as well use 204 No Content instead.
Then, when resuming an upload, you send a HEAD that returns the following:
Again, you can't use the Range request header in a response. And the Content-Length should surely be 70, since that's how much content would be returned if this was a GET request. You could possibly include a Content-Range of 0-69/100 if the server wanted to communicate the expected file size, but I'm not convinced that's necessary and seems something of an abuse of that header.
Finally, the response to the resumed PUT has the same problems as the first PUT response. It should probably just be a 204 No Content response - no Content-Length or Range headers required.
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.
> 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!
I don't see a way to support parallel transfers using only existing HTTP headers (without violating the HTTP spec). I would suggest maybe proposing a new header in the HTTPbis WG. For example, something like Available-Ranges that returns a ranges-specifier indicating the set of ranges that are avaiable.
This could possibly be returned as part of a 416 response when attempting to GET a file that isn't entirely available yet. A HEAD request would thus return the same thing.
> 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.
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.
Also, if you're going to return a zero-length 200 response, you might as well use 204 No Content instead.
Then, when resuming an upload, you send a HEAD that returns the following:
Again, you can't use the Range request header in a response. And the Content-Length should surely be 70, since that's how much content would be returned if this was a GET request. You could possibly include a Content-Range of 0-69/100 if the server wanted to communicate the expected file size, but I'm not convinced that's necessary and seems something of an abuse of that header.Finally, the response to the resumed PUT has the same problems as the first PUT response. It should probably just be a 204 No Content response - no Content-Length or Range headers required.