- From: Ken Murchison <murch@fastmail.com>
- Date: Wed, 10 Jun 2026 08:57:57 -0400
- To: ietf-http-wg@w3.org
Julian, Thanks for the clarification. So, an implementation that evaluates the If header in one pass MUST NOT short-circuit even if the final result of the and/or logic can be determined early, so as to not miss any submitted state tokens. On 6/9/26 4:39 AM, Julian Reschke wrote: > Am 28.05.2026 um 16:03 schrieb Ken Murchison: >> All, >> >> I am reviewing the If header field processing in the Cyrus *DAV >> server component. >> >> I'm confused by the text in RFC 4918 with respect to a MOVE request >> where both the source and destination resources are locked. >> >> The last sentence of Section 7.5 >> <https://datatracker.ietf.org/doc/html/ rfc4918#section-7.5> states: >> >> For example, if a resource is to be moved >> and both the source and destination are locked, then two lock tokens >> must be submitted in the If header, one for the source and the other >> for the destination. >> >> This leads me to believe that the MOVE request would have to contain >> two Tagged-List components and look something like: >> >> MOVE /file1.txt HTTP/1.1 >> Destination: /file2.txt >> Overwrite: T >> If: </file1.txt> (file1-lock-token) >> </file2.txt> (file2-lock-token) >> >> Logic would tell me that BOTH of the submitted lock tokens would have >> to match their respective resources in order to successfully process >> the MOVE. >> >> However, the last paragraph in Section 10.4.3 <https:// >> datatracker.ietf.org/doc/html/rfc4918#section-10.4.3> states: >> >> Finally, the whole If header evaluates to true if and only if at >> least one of the No-tag-list or Tagged-list productions evaluates to >> true. >> >> I read this as saying that ONLY ONE of the submitted lock tokens need >> to match, NOT both. Am I reading the text incorrectly or is the text >> itself incorrect? >> ... > > The explanation > (<https://www.greenbytes.de/tech/specs/rfc4918.html#if.header.purpose>): > >> The If header has two distinct purposes: >> >> The first purpose is to make a request conditional by supplying a >> series of state lists with conditions that match tokens and ETags to >> a specific resource. If this header is evaluated and all state lists >> fail, then the request MUST fail with a 412 (Precondition Failed) >> status. On the other hand, the request can succeed only if one of the >> described state lists succeeds. The success criteria for state lists >> and matching functions are defined in Sections 10.4.3 and 10.4.4. >> Additionally, the mere fact that a state token appears in an If >> header means that it has been "submitted" with the request. In >> general, this is used to indicate that the client has knowledge of >> that state token. The semantics for submitting a state token depend >> on its type (for lock tokens, please refer to Section 6). >> >> Note that these two purposes need to be treated distinctly: a state >> token counts as being submitted independently of whether the server >> actually has evaluated the state list it appears in, and also >> independently of whether or not the condition it expressed was found >> to be true. > > So only one of the condition needs to be true, but all state (lock) > tokens *are* submitted is sufficient for the lock checks > (<https://www.greenbytes.de/tech/specs/rfc4918.html#write.locks.and.the.if.request.header>): > > "A lock token is submitted when it appears in an If header." > > And yes, it's long ago. > > Best regards, Julian > > > > >
Received on Wednesday, 10 June 2026 12:58:02 UTC