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:53:45 -0700
Message-Id: <0790B052-B4AD-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>

Well, the bigger issue then is whether to toss out shared locks.  If 
they're not interoperably implemented, and if we're indeed trying to go 
to draft standard, then they need to go.

lisa

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

> Lisa Dusseault wrote:
>
>> 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)
>
> Yes.
>
>>  - 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
>
> I'd say it's harmless if it contains more lock tokens. The server can 
> figure out which one actually identifies a lock on the request 
> resource.
>
>>  - The server MUST reject the request if the request-URI and token do 
>> not match
>
> Yes.
>
> Seems that we agree except for the minor point above; in practice I 
> don't think that clients *will* submit multiple lock tokens in a 
> refresh request, so this shouldn't be an issue.
>
> Best regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 2 June 2004 11:54:12 GMT

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