Re: If header evaluation on MOVE request with both source and destination resources locked

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 Tuesday, 9 June 2026 08:39:15 UTC