Re: When If headers with tagged lists fail

Lisa Dusseault wrote:
> 
> 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).

"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.

> 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"?

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

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Thursday, 8 July 2004 02:03:59 UTC