Re: Digest: use in requests

[Julian Reschke <[e-mail]>]

Am 29.12.2020 um 13:17 schrieb Lucas Pardue:
> ...
> This is indeed the most likely use case. A very quick survey indicates
> that there seem to be some examples of PUT requests with Content-Range
> in the wild. I have no experience with these, nor knowledge of how
 > ...

Note:

"An origin server that allows PUT on a given target resource MUST send a
400 (Bad Request) response to a PUT request that contains a
Content-Range header field (Section 4.2 of [RFC7233]), since the payload
is likely to be partial content that has been mistakenly PUT as a full
representation. ..." --
<https://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.4.3.4.p.11>

> ...
> "This document specifies a new media type intended for use in PATCH
>     payloads that allows a resource to be uploaded in several segments,
>     instead of a single large request."
>
> Example:
> PATCH /uploads/foo HTTP/1.1
>     Content-Type: message/byterange
>     Content-Length: 283
>     If-Match: "xyzzy"
>     If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
>
>     Content-Range: bytes 100-299/600
>     Content-Type: text/plain
>     Content-Length: 200
> ...

FWIW, use of Content-Range in PATCH is unspecified.

> Finally, Dropbox [5] does things a little differently and uses the
> Dropbox-API-Arg JSON header field to communicate a cursor containing an
> offset of the bytes uploaded so far (which I guess means that parallel
> transfers aren't supported).
>
> Example:
> curl -X POST
> https://content.dropboxapi.com/2/files/upload_session/append_v2
> <https://content.dropboxapi.com/2/files/upload_session/append_v2> \
>      --header "Authorization: Bearer"
>      --header "Dropbox-API-Arg: {\"cursor\": {\"session_id\":
> \"1234faaf0678bcde\",\"offset\": 0},\"close\": false}"
>      --header "Content-Type: application/octet-stream"
>      --data-binary @local_file.txt
>
> To conclude, I'm not exactly sure how these examples influence the
> discussion. It seems that there are actually concrete cases of "partial
> requests" but it's unclear to me if these break HTTP semantic rules
> and/or if it should be documented for formally. The examples I've seen
 > ...

The only concept that HTTP itself for "partial" is defined in RFC 7233.
This is for responses. It *could* be extended to requests, but the spec
is very very clear that it can not be used for PUT.

If there's interest in changing the above requirement, now would be the
time to raise this.

> are for APIs that also have their own custom means for integrity checks,
> or still use Content-MD5. It would be nice if something like Digest
> covered all avenues and we could get folks to switch to it, but I've not
> seen any signals that such APIs are interested in Digest. Therefore, I'm
> wary of Digest taking on too much work to describe something without any
> implementer interest. In the interest of progress, if partial requests
> for uploads is something people think needs standardising, I think that
> could be done as an independent follow-on work item e.g. a document that
> updates Digest.
> ...

Yes.

In any case, the protocol needs to state what a recipient ought to do
when a message has a "Digest" field on it. We can't just say "it depends".

Best regards, Julian