- From: Guoye Zhang <guoye_zhang@apple.com>
- Date: Fri, 05 Aug 2022 19:53:51 -0700
- To: Austin William Wright <aaa@bzfx.net>
- Cc: ietf-http-wg@w3.org
> On Aug 5, 2022, at 19:17, Austin William Wright <aaa@bzfx.net> wrote: > > > >> On Aug 5, 2022, at 17:12, Guoye Zhang <guoye_zhang@apple.com> 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. > >
Received on Saturday, 6 August 2022 02:54:16 UTC