I thought that RFC2518 was clear that if the If header includes a
tagged list with the wrong URL then the request should be failed with
412. I went looking for the explanation in the section on tagged
lists, and it wasn't terribly clear. It just tacitly "inherits" the
definition from the untagged If header behavior.
So, what if I added a sentence to the description of tagged list
production in the If header, as follows:
Text already there:
The tagged-list production scopes a list production. That is, it
specifies that the lists following the resource specification only
apply to the specified resource. The scope of the resource
production begins with the list production immediately following the
resource production and ends with the next resource production, if
any. All clauses must be evaluated.
Text to add immediately after:
If the state of the resource named in the tag does not
match any of the associated state lists then the request MUST fail
with a 412 (Precondition Failed).
Does this clear up the confusion? Is it OK/clear to have this
information in a different section of the spec from where it says "a
lock token is submitted if it appears anywhere in the If header"?
Lisa
On Dec 30, 2003, at 2:43 AM, Julian Reschke wrote:
>
> Geoffrey M Clemm wrote:
>
>> There are a couple of ways to go here:
>> (1) consider a lock token to be submitted if it is submitted with a
>> URL that is directly or indirectly locked by that lock token
>> (2) consider a lock token to be submitted if it appears anywhere in
>> the If header, even if it only appears on a URL that is not in
>> fact locked by that lock.
>>
>> Lisa's initial statement sounded like she was advocating the
>> second approach, but her last statement sounds more like the
>> first approach. On the other hand, the last comment ("Otherwise
>> you'd get a 412 Precondition Failed") is incorrect, since only
>> one of the state lists need to match.
>>
>> Either way is OK with me (although I'd probably have gone with
>> the first approach myself), but I just wanted to verify what
>> folks had in mind here.
>
> I think the current spec
> (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis
> -05.txt>)
> assumes (2):
>
> Quoting section 7.6:
>
> In order to prevent these collisions a lock token MUST be submitted
> by an authorized principal for all locked resources that a method
> may change or the method MUST fail. A lock token is submitted when
> it appears in an If header. 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.
>
> I can live with that, but I'm not sure why this is better than
> requiring
> the token to appear with the right URL (when in a tagged list). Is this
> just a statement about current client behaviour, or a change compared
> to
> RFC2518?
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
> <winmail.dat>