Subject: When If headers with tagged lists fail

From: Lisa Dusseault <[email-masked]>
Date: Wed, 7 Jul 2004 16:14:18 -0700

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>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 08 Jul 2004 08:03:18 +0200

>    with a 412 (Precondition Failed).

"If the state of the resource identified by the URI specified in the tag 
does not match any of the associated state lists then the request MUST 
fail with a 412 (Precondition Failed)."

Plus: define a precondition code.

> lock token is submitted if it appears anywhere in the If header"?

I agree that something like this is what RFC2518 should have said in the 
first place. However, today we should take into account what exactly is 
implemented in the popular servers before making a change (so we need to 
  run tests first).

Julian