W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2004

Re: LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY vs RFC2518bis-05

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 2 Jun 2004 08:16:22 -0700
Message-Id: <CED18C76-B4A7-11D8-AF1F-000A95B2BB72@osafoundation.org>
Cc: Webdav WG <w3c-dist-auth@w3c.org>, Jason Crawford <ccjason@us.ibm.com>
To: Julian Reschke <julian.reschke@gmx.de>


On Jun 2, 2004, at 8:06 AM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>
>> We have been conservative about changes in RFC2518bis, generally only 
>> changing things where interoperability testing shows that there is a 
>> problem.  In this case, confusion over where to put the lock token in 
>> refresh requests came up in actual implementations and early 
>> interoperability testing.  In addition, it was unclear what to do if 
>> multiple lock tokens appeared in the If header (the Lock-Token header 
>> allows only one).  IOW, the present protocol didn't quite do what it 
>> was supposed to do.
>
> I agree that it is confusing. However, popular clients and servers 
> seems to agree on how it works, so why don't we just write that down?

One problem is that popular clients and servers only do exclusive 
locks, so current practice is not sufficient to answer the unanswered 
questions in RFC2518.  We could cut shared locks from WebDAV, require 
that only one resource's lock may be updated by a LOCK refresh request, 
and that would codify existing practice.  I believe that works even for 
collection locks since a collection lock may not overlap another 
exclusive lock.  So the new requirements would be something like:

  - The LOCK refresh request MUST address the resource that was locked 
(the root of the lock)
  - The If header on the LOCK refresh request MUST contain one (and only 
one) lock token, the token for the lock that is to be refreshed
  - The server MUST reject the request if the request-URI and token do 
not match

Lisa
Received on Wednesday, 2 June 2004 11:16:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:06 GMT