Re: draft-ietf-httpbis-resumable-upload-01

Hi Lucas,

I had a brief read through the digest draft today while thinking how this
could be applied to resumable uploads. The new integrity fields with its
separation between content and representation should fit perfectly to the
approach of resumable uploads. I thought I would name a few concrete
examples to see if my understanding of the digest draft is correct:

1) Assume that the client knows the digest of the entire file that it wants
to upload. It can then set Repr-Digest in the Upload Creation Procedure and
upload the data. If the transfer is interrupted it is just resumed as
normal with HEAD and PATCH. Once the upload is complete, the server can
verify the integrity of the uploaded data by comparing it to the
Repr-Digest from the Upload Creation Procedure. If they don't match, the
server can reject the upload and return an error to the client or similar.

2) If the client does not know the digest of the entire upload at the
beginning (because it is streamed from another resource), it can compute
the digest while the upload is running and then include Repr-Digest as a
trailer on the final Upload Creation Procedure or Upload Appending
Procedure. The server can then verify as in 1).

3) If the client does not compute the digest, but wants to query the
server's digest, it can include the Want-Repr-Digest in the Upload Creation
Procedure. On the final response, the server should then include the
Repr-Digest whose value corresponds to the entire upload that it has
received. The client then may verify the digest or provide it to the
client's users.

4) If the clients sets Content-Digest on an Upload Creation Procedure or
Upload Appending Procedure, it only applies to the specific request body.
So if the request transmission gets interrupted, the server is not able to
verify the integrity and must reject the entire request without appending
its content to the upload. This makes the request effectively
transactional, where either the entire body or nothing is appended to the
upload. This is a bit contrary to the intention of uploads that can be
resumed from the point where they failed, but if you split an upload into
multiple requests, this might still be interesting for some applications.

Do these examples align with the intentions behind the digest draft or did
I get something wrong? All in all, this appears like a great fit!

Best regards
Marius

On Thu, Jul 27, 2023 at 10:21 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

>
>
> On Thu, 27 Jul 2023, 12:09 Rob Sayre, <sayrer@gmail.com> wrote:
>
>> On Thu, Jul 27, 2023 at 10:10 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
>> wrote:
>>
>>>
>>> Resumable uploads should probably minimally mention something about
>>> integrity of HTTP message content (parts) and the integrity of the whole
>>> object.
>>>
>>
>> Hi, that's all I meant to suggest. The problems I've seen are not
>> external security threats, but bugs in reassembling the parts on the
>> server, after TLS termination.
>>
>
> Yep this is totally in scope of problems that digest is intended to help
> mitigate. Thanks for the confirmation, I'll prepare some text in a PR for
> the uploads draft.
>
> Cheers
> Lucas
>
>>
>> thanks,
>> Rob
>>
>>
>