> The Range header doesn't work the way you suggest, it is for requesting a range for the response, not giving a range for the data in the request rfc9110 actu

> The Range header doesn't work the way you suggest, it is for requesting a range for the response, not giving a range for the data in the request rfc9110 actually does permit servers to implement range on PUT, with partial update semantics, but warns that user agents can only safely do this if they know the origin server supports this, as if not the server could fallback to replacing the whole resource with just the uploaded range! (To my knowledge such support is not very common. Also due to risks of being misinterpreted by caches and other intermediaries, using the dedicated PATCH verb is probably better.) But this (ranged with PUT) is only semantically appropriate for updating an existing valid resource. For example, if you have database like file format, you can upload only the changed ranges which could be much much smaller than the whole file. Or for something like a log file, one could append new content to the end. For most files, breaking them into many parts for initial upload and range putting each part would be semantic inappropriate, since the resource is likely to only actually be valid once the last part is uploaded.