- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 9 Jul 2020 08:01:28 +0200
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 09.07.2020 07:27, Mark Nottingham wrote: > >> On 8 Jul 2020, at 6:28 pm, Julian Reschke <julian.reschke@gmx.de> wrote: >> >> ...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?). > > 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. 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 another customer parser if Structured Fields were used. Defining a generic conditional header field using SH syntax would certainly be interesting, yes. Best regards, Julian
Received on Thursday, 9 July 2020 06:01:46 UTC