Re: Byte range PATCH

Hi Austin,

replies inline.

Il giorno mar 9 ago 2022 alle ore 07:31 Austin William Wright
<aaa@bzfx.net> ha scritto:
> 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.
> The Digest header does not describe usage in requests, but there’s only a few ways that it could be useful.

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

> 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?

> 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 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/

Have a nice day,
R.

Received on Tuesday, 9 August 2022 08:16:59 UTC