Re: Byte range PATCH

[Austin William Wright <[e-mail]>]

> On Aug 5, 2022, at 17:12, Guoye Zhang <[e-mail]> wrote:
> 
> Hi Austin,
> 
> Thanks for sharing the well-written draft. I’m glad this is being worked on. Two comments:
> 
> (1) As you have already noted, Content-Range forces us to declare an end offset, so it’s unfortunate that a continuous stream with undetermined length has to be sent using multipart encoding.

Yeah. I think the best case is Content-Range is updated to support an indefinite length form.

But a new header could also be defined, like Content-Offset.

> 
> (2) For a general purpose byte range patching mechanism, would you also want to define ways to insert or delete byte ranges?
> 
> A possible approach is to have this be a “replace byte range with” operation instead:
> 
> Replace 0-0 with 100 bytes: insert 100 bytes at the front
> Replace 0-100 with 0 bytes: remove first 100 bytes
> Replace 100-100 with 100 bytes: insert 100 bytes at offset 100


This makes sense!

The server would have to have some way to recognize that the bytes after it are shifting around (e.g. When prepending 100 bytes, byte 0 becomes byte 100), and reject if that’s too much work, or if the filesystem doesn’t support such an operation. Maybe in this situation, the Content-Length header would be required, and then the server could immediately determine if this is a simple overwrite, or if it's actually changing the file size.

Thanks,

Austin.