- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 8 Jul 2020 10:28:05 +0200
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 08.07.2020 08:46, Mark Nottingham wrote: > >> On 30 Jun 2020, at 7:22 pm, Julian Reschke <julian.reschke@gmx.de> 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... > ... 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
Received on Wednesday, 8 July 2020 08:28:23 UTC