Subject: Re: draft-ietf-httpbis-digest-headers: Digests and Conditional Requests

From: Roberto Polli <[email-masked]>
Date: Sun, 5 Jul 2020 21:57:17 +0200

Hi Julian,

I was not able to find any evidence of using parameters for digest
algorithms in the wild.

Do you agree to follow up the discussion here
https://github.com/httpwg/http-extensions/issues/850#issuecomment-653931895
?

Thanks for all your support,
R:

Il giorno mar 30 giu 2020 alle ore 18:31 Julian Reschke
<[email-masked]> ha scritto:
>
> On 30.06.2020 18:03, Roberto Polli wrote:
> > Hi Julian,
> >
> > thanks for this feedback!
> > I am reading RFC 6920 but I don't find many details on representation
> > metadata and partial representation
> > (only `ct` - content-type is defined).
> >
> > It would be interesting to understand how to tie "ni:///$HASH" with
> > the other digest-algorithms in a way that it is respectful of RFC3230,
> > eg. see https://github.com/httpwg/http-extensions/pull/1213
> >
> > When  I finish reading rfc 6920 I'll provide more feedback.
> >
> > Thanks again,
> > R.
> > ...
>
> Do we have any evidence of use of parameters for digest algorithms?
>
> Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 8 Jul 2020 16:46:20 +1000

> On 30 Jun 2020, at 7:22 pm, Julian Reschke <[email-masked]> wrote:
> 
> Hi there,
> 
> I just noticed that RFC 4918 (WebDAV) and RFC 6920 (Naming Things with
> Hashes) give us the machinery to make request conditional on hashes.
> 
> Example (based on
> <https://greenbytes.de/tech/webdav/draft-ietf-httpbis-digest-headers-02.html#server-returns-full-representation-data>)
> 
>  PUT /x HTTP/1.1
>  Host: foo
>  If: <ni:///sha-256;X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=>
>  Content-Type: application/json
> 
>  {"hello": "world2"}
> 
> All that would be needed is s statement that servers that support both
> the Digest field and the If header field SHOULD consider the ni: URIs
> built from the hashes as "state tokens" as defined in RFC 4918, Section 3.

As I read it, that means you'll get a 412 when the hash matches. The opposite would be more useful (i.e., an analogy to If-None-Match with hashes) would be more useful for many cases...

Having said that, I think a more specific header field would be more likely to get traction -- e.g., If-Not-Hash: ... That might enable several interesting use cases. 

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 8 Jul 2020 10:28:05 +0200

> As I read it, that means you'll get a 412 when the hash matches. The opposite would be more useful (i.e., an analogy to If-None-Match with hashes) would be more useful for many cases...

Good point.

So make it:

   If: Not <ni:///sha-256;X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=>

> Having said that, I think a more specific header field would be more likely to get traction -- e.g., If-Not-Hash: ... That might enable several interesting use cases.

...already covered by "If". I would prefer using something that is
already defined, instead of having to mint two more header fields (we'd
need both "If-Hash" and "If-Not-Hash", right?).

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 9 Jul 2020 15:27:55 +1000

> On 8 Jul 2020, at 6:28 pm, Julian Reschke <[email-masked]> wrote:
> 

The problem is that it's not obvious what parts of If will need to be implemented to interoperate for a particular use case; will they need to support entity-tags too? What about Resource-Tags? The ability to put lists of conditions with varying aspects? Different URI schemes? It's actually a quite complex mechanism.

To me, it's much more straightforward to define a new header (or headers) to meet the use case in hand, with some modest affordance for extensibility. It would also remove the need to mint yet another customer parser if Structured Fields were used.

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Thu, 9 Jul 2020 08:01:28 +0200

> The problem is that it's not obvious what parts of If will need to be implemented to interoperate for a particular use case; will they need to support entity-tags too? What about Resource-Tags? The…

The answer to all of these is "yes", except for URI schemes. It's up to
the server to decide which URI schemes to support for state tokens. "ni"
is special here because there would need to be an out-of-band signal
that the server does these. (For WebDAV, that could be in OPTIONS).

It is more complex, but then having multiple conditional header fields
is complex, too.

> To me, it's much more straightforward to define a new header (or headers) to meet the use case in hand, with some modest affordance for extensibility. It would also remove the need to mint yet anot…

Defining a generic conditional header field using SH syntax would
certainly be interesting, yes.

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 8 Jul 2020 23:24:48 -0700

> On Jul 8, 2020, at 11:01 PM, Julian Reschke <[email-masked]> wrote:
> 

Oh, really ...

  https://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-01#Logic-Bags <https://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-01#Logic-Bags>

....Roy