Re: Byte range PATCH

> On Aug 9, 2022, at 01:16, Roberto Polli <robipolli@gmail.com> wrote:
> 
> Please, see this I-D which explains in detail how Digest (better, the
> new Repr-Digest)
> works https://httpwg.org/http-extensions/draft-ietf-httpbis-digest-headers.html#section-3.1-5

Oh, I didn’t realize this was in the process of being updated. I’ll take a look.

> 
>> In any event, my remark about Digest was nothing more than a cute idea, but maybe we should think about it more.
> I really think that a mechanism to update specific parts of a
> representation requires a Digest-like mechanism.
> PATCH does not specify the representation metadata of the resource you
> are updating, but only the metadata of the patch document.
> Of course, we could define the behavior of Digest when used in a
> message/byterange, provided that the Content-Type
> is the one of the selected representation data.
> 
> ```
> PATCH /uploads/foo HTTP/1.1
> Content-Type: message/byterange
> Content-Length: 283
> Accept: video/mp4
> If-None-Match: *
> 
> Content-Type: video/mp4
> Repr-Digest: sha256=:LCa0a2j/xo/5m0U8HTBBNBNCLXBkg7+g+YpeiGJm564=:
> Content-Range: bytes 200-399/600
> Content-Length: 200
> 
> [...]
> ```
> 
> https://httpwg.org/http-extensions/draft-ietf-httpbis-digest-headers.html#appendix-B.9
> 
> 
>> The purpose of using the media type is because Content-Range is not reliable in requests.
> 
> This is a discussion that periodically comes up: for "is not reliable"
> you mean that it's not standard, right?

Even if Content-Range was supported in PUT from the start, or if HTTP had defined it in requests, it might still be unreliable if too many servers forget to check it.

By putting the Content-Range in a media type, in a method, it’s inside two extension points that the server cannot ignore.

> 
>> 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.
> 
> I am just handwaving, but it could be something like that. Replace
> 100-continue with whatever similar mechanism.
> 
> 
> PATCH /file
> Expect-Ranges: ranges=3, status=100
> 
> Content-Range: bytes 0-199/600
> Content-Type: text/plain
> Content-Length: 200
> 
> [..]
> 
> HTTP/1.1 100 Continue
> 
> Content-Range: bytes 200-399/600
> Content-Type: text/plain
> Content-Length: 200
> 
> [..]
> 
> HTTP/1.1 100 Continue
> 
> Content-Range: bytes 400-599/600
> Content-Type: text/plain
> Content-Length: 200
> 
> [..]
> 
> HTTP/1.1 200 OK

I see, what would a client use a 100 Continue response for? Normally it tells the client that it can begin uploading, but it appears the client isn’t waiting.

If all you need to do is bundle multiple parts together, is what "multipart/*" accomplishes. Your example appears to be similar, except using Content-Length instead of a boundary:
https://www.rfc-editor.org/rfc/rfc2046#section-5.1 <https://www.rfc-editor.org/rfc/rfc2046#section-5.1>

And if the client needs to know that each part was valid before uploading the next part, it can just fire off multiple PATCH requests.

>> 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, [..]
>> there’s several regions that need to be updated at the same time.
> Ok. Have you already read the TUS spec? There's an ongoing discussion in httpapi
> https://datatracker.ietf.org/doc/draft-tus-httpbis-resumable-uploads-protocol/

Yes, I’ve been providing some feedback.

To be clear, "message/byterange" would be better for resumable uploads. You could use "multipart/byteranges” but it's slower to parse if the client doesn’t send Content-Length in a part.

Thanks,

Austin.