Re: Digest: use in requests

Am 29.12.2020 um 10:56 schrieb Roberto Polli:
> Hi @Julian Reschke,
>
> replies in-line.
>
> TL;DR: if http forbids partial representations in requests, this discussion
> will be solved without changing the spec.
>
> Il lun 28 dic 2020, 19:33 Julian Reschke <julian.reschke@gmx.de> ha scritto:
>>
>> Am 28.12.2020 um 18:57 schrieb Roberto Polli:
>>
>>> The point is related to whether Digest on requests containing
>>> partial representations should be computed on the payload-data
>>> or on the representation data. The actual Digest formulation derives
>>   > ...
>>
>> And this is where the problem starts.
>>
>> Could you please *define* what a request "containing a partial
>> representation" is,
>
> This is the first question: can a request payload-data convey a
> partial representation?
> My understanding of semantic-latest ยง6.4 is: yes, but if we think it
> is not appropriate
> we could clarify that. See:
>
> - https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#rfc.section.6.4.p.1
> - https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#rfc.section.6.4.2.p.1
>
>> and how a component can detect that case?
>
> As Digest is an end-to-end integrity mechanism, the intended components
> are not supposed to be agnostic intermediaries. Instead, they are expected
> to have some knowledge about the purpose of the payload (eg. in case
> of id-* algorithms they
> need to content-decode the payload to validate it, or in case of Range
> Requests).

Hm, that seems like an odd choice for a protocol spec. If the spec
doesn't say what the Digest means for any request, it's not really
defining a protocol.

I would *hope* that we can define things so that Digests can
automatically produced and checked by user agents (browsers) and servers
(such as a servlet container).

> Reading https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#rfc.section.6.4.1.p.1
> ```The purpose of a payload in a request is defined by the method semantics```
> iiuc the receiver, aware of the request semantic, knows its purpose
> and how to process it, including whether it conveys a partial
> representation or not.

But "partial repesentation" is a term defined by HTTP; there is (or
should be) an algorithm that - when inspecting *any* HTTP message -
tells you whether it's "partial" or not. In HTTP, this is defined by the
appearance of "Content-Range" for some specific response status codes.

>> Furthermore, a real-world example would be useful.
>
> I cannot mention existing standards conveying partial representations
> in requests,
> but I think this is not a reason for changing the representation-data-digest
> mechanism defined in continuity with RFC3230 and specifying here a behavior

I'm not convinced that continuity with RFC 3230 is important, but could
you be a bit more specific here?

> (no partial representations in request) that is in the domain of
> httpbis-semantics.
>
> Besides coherence with RFC3230, imho if a future method/header allows
> to convey a partial representation
> in a request, it should be possible to use Digest to convey the
> checksum of the complete representation.
> ...

It *really* would be good to discuss something *concrete* here.

Let's consider an upload protocol that sends multiple chunks, and then
lets the server combine these into the final resource.

In that protocol, Digest on each chunk would be use to check the
integrity of each chunk.

For the final step of creating the final full resource, the client could
send the expectec digest of the final resource in a *custom* field
defined for the upload protocol (it would use the same algorithms etc,
but use a different way to convey it to the server).

With that, generic libraries could at least verify Digests on each of
the chunks.

Best regards, Julian

Received on Tuesday, 29 December 2020 10:24:31 UTC