> An origin server that allows PUT on a given target resource MUST send
> a 400 (Bad Request) response to a PUT request that contains a
> Content-Range header field (Section 4.2 of [RFC7233]),
Responding with 400 Bad Request is actually something that was added after some servers allowed Content-Range on PUT and others didn't.
It was never standard, but the end-result was that some clients assumed PUT + Content-Range would work, which meant that some servers would apply the change while others would ignore the header and overwrite the entire resource with the chunk.
There's no sane way to add support for this header and make older servers behave correctly, so now we have better facilities for this.
The standard way is to use PATCH + a mimetype that describes the update + perhaps using Accept-Patch to find out what formats are available. It's extremely doubtful that Content-Range for PUT will ever be standard. If there's going to be a future standard, it's likely PATCH based.
It could be possible with PUT and a new 'Expect' header, but not sure if that gives any advantages now over PATCH.
> There's no sane way to add support for this header and make older servers behave correctly, so now we have better facilities for this
KISS. Endow the "400 Bad Request" server response with a special header that acts like a cookie or nonce, with the semantics "this server does support Content-Range uploads and won't corrupt your resource". If the client resends the PUT + Content-Range request with the correct cookie/nonce added to it, it has acknowledged this semantics in turn, and the upload can now go through. This adds a roundtrip, but it's still trivial compared to what's being proposed here, and keeps the semantics of PATCH open for more complicated cases.
Or do a HEAD on the resource you want to resume uploading (this is recommended to find out how many bytes have actually went through) and if the response contains a "Accept-Range: true" header then the client can resume the upload.
You are right about those things, and some of the proposed solutions (that one and others).
It look to me PATCH is actually better; perhaps one of the patch formats can be a partial patch, for example if the Content-Type of the PATCH request is application/partial-content-patch then the first line of the body is the contents of the Content-Range header. In my opinion, this look better to me than the other replies to the message that this message is in reply to (although I admit anything I write may be mistaken; I am not perfect).