Re: Byte range PATCH

> On Aug 8, 2022, at 07:31, Roberto Polli <robipolli@gmail.com> wrote:
> 
> Hi Austin,
> 
> 
> Il giorno mer 3 ago 2022 alle ore 01:15 Austin William Wright
> <aaa@bzfx.net> ha scritto:
>> I wrote and published draft-wright-http-patch-byterange-00 for your consideration. Please let me know your thoughts.
> 
> Thanks for the interesting draft: I think we need something like this.
> About Digest, it won't help in requests because  PATCH request content
> conveys
> the checksum of the enclosed representation.

My understanding of the Digest header (RFC 3230) is that, it is the digest of the entire representation, and not necessarily the body of the message.

This is in contrast to Content-MD5 (I’m not aware of a Content-Digest field though maybe there should be one) which does describe only the message body.

In any event, my remark about Digest was nothing more than a cute idea, but maybe we should think about it more. The Digest header does not describe usage in requests, but there’s only a few ways that it could be useful.

> To convey the checksum of the complete representation data (e.g. the
> complete file, and not the byte ranges)
> you need to use:
> 
> - either PUT and extend content-range for requests;
> - either a new specific method;
> - either a new specific field associated with a specific method (e.g. PATCH).
> 
> There was some discussion on that, and while I think that PUT it would
> be the cleaner and most intuitive solution, some interoperability
> issues with existing implementations that do not understand
> Content-Range might arise (e.g. you'd need to ensure that the server
> support content-range in requests to avoid replacing an existing
> resource with the "partial" representation conveyed in PUT). In
> general RFC9110 is now more flexible on PUT + partial representations
> than in the past.

The purpose of using the media type is because Content-Range is not reliable in requests.

> 
> About sending multiple ranges in a single request, is it possible to
> use some mechanism such as Expect or similar to allow the client to
> send separate ranges?

Can you give an example? “Expect" is not reliably implemented in servers, though I’m not sure why it would be necessary here even if it was.

> In general, it is even possible for resumable uploads that there's no
> significant advantage in designing a way to convey multiple
> content-ranges in the same request and it is simpler to just issue
> multiple requests so that each can have its own representation
> metadata managed directly via HTTP.

I don’t believe multipart/byteranges would be useful for resumable uploads. Resumable uploads is just one use that I foresee, among other uses.

For example, "multipart/byteranges" might be used to append data to the end of a WAV audio file, or an MP4 video file, then updating the index at the start of it. In this case, there’s several regions that need to be updated at the same time.

> 
> Great to hear from you all,
> R.

Cheers,

Austin.