Re: Byte range PATCH

[Guoye Zhang <[e-mail]>]

> On Aug 5, 2022, at 19:17, Austin William Wright <[e-mail]> wrote:
> 
> 
> 
>> 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.

Thinking about this more, there is a problem with using Content-Range for this as well. End offset is inclusive, so in order to insert / append, we need to decrease it by one.

Suppose we have a 100 byte file:

	PATCH /file
	Content-Range: bytes 99-99/100
	Content-Length: 42
This means replacing the last byte with 42 bytes.

	PATCH /file
	Content-Range: bytes 100-99/100
	Content-Length: 42
This means appending 42 bytes in the end.

Having end position being smaller than the start position is already hazardous, where it breaks down is inserting at the beginning:

	PATCH /file
	Content-Range: bytes 0--1/100
	Content-Length: 42
End offset is now -1 and this will definitely trip over existing parsers.

Well, it’s a nice thought. It won’t work unless Content-Range is changed, either.

Guoye
> 
> Thanks,
> 
> Austin.
> 
>