W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2007

Re: Guidance for dealing with both kinds of resources created by LOCK (was Re: IETF Last Call review: changes suggested)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 27 Jan 2007 12:35:42 +0100
Message-ID: <45BB390E.9020305@gmx.de>
To: Lisa Dusseault <lisa@osafoundation.org>
CC: WebDAV WG <w3c-dist-auth@w3.org>

Lisa Dusseault schrieb:
> I'm not quite sure we've dealt with the high-order question yet of 
> whether to attempt to add guidance for clients dealing with servers that 
> might support Lock-null resources (LNR) or locked, empty resources. 

I don't think we did.

> It's my impression that some servers have already moved away from LNRs 
> to do the new locked, empty resources; other servers never implemented 
> LNRs fully or never did locking.  Clients have probably already figured 
> out how to work with both kinds of servers by now.  Julian, your opinion 
> seems rather lukewarm or indifferent.  Did anybody else have an opinion?

I'm not aware of clients that have been confused by the differences 
between LNRs (lock-null resources) and ELRs (empty locked resources).

> Perhaps if we run into difficulties agreeing on what guidance to provide 
> we can abandon the effort.
> More inline, relevant if we do try to provide guidance...
> On Jan 17, 2007, at 5:18 AM, Julian Reschke wrote:
>>>> It would help if there was descriptions of how clients should 
>>>> perform actions portably given that MAY.  For example:
>>>> - if a client locks an unmapped URL and then decides to COPY or MOVE
>>>>   another resource to that name, it needs to include an "Overwrite: T"
>>>>   header in the COPY/MOVE
>> It needs that with the new approach, and it seems to me it was 
>> undefined with LNRs. Do we have any evidence of interoperability 
>> issues here?
> I don't have evidence of interoperability, but I agree the Overwrite 
> header is clearly needed with the new approach, and I can't think it 
> would hurt with a LNR server.  So I can't think of a drawback to 
> including this as part of the guidance.

So yes, if we add guidance on this, suggesting to add "Overwrite: T" in 
this case will be harmless.

>>>> - similarly, if it changes its mind and decided to not create the
>>>>   resource, it needs to use DELETE instead of UNLOCK
>> No, it doesn't.
> In a later mail you mentioned also being able to do UNLOCK then DELETE.  
> That won't result in a success with a LNR -- the DELETE will fail.  

But it will fail with 404, which I would assume is harmless.

> OTOH, I'm not clear whether a DELETE will be allowed to succeed on an 
> LNR -- it may fail and only an UNLOCK will make the LNR go away.  So 
> perhaps the guidance should be:
>     - attempt first to UNLOCK, expect success on either kind of server
>     - then send a DELETE and ignore 404 Not Found responses
> OR attempt first to DELETE, and if that fails try UNLOCK...?  This is 
> the optimistic approach, particularly assuming most servers will 
> eventually support the new model.

Both will work; I don't really think it matters because this is a case 
of recovery from an exceptional state that in practice shouldn't occur 

>>>> - if a client wants to creat a new, empty collection and lock it, the
>>>>   client should not pipeline a MKCOL and LOCK but rather do the 
>>>> MKCOL and
>>>>   only send a LOCK if it succeeds.  Pipelining them can result in the
>>>>   client locking a collection that someone else created or even the
>>>>   locking of something other than a collection.  (Or maybe I'm
>>>>   overlooking something here...)
>> I'd say that by not pipelining them the client actually increases the 
>> chance of locking a collection created by somebody else. But - 
>> thinking of it - why is that a problem anyway? It really doesn't 
>> matter who created the collection, as long as it's there and locked 
>> after the two requests, right? It's not as if *two* clients can 
>> succeed in locking them.
> We could add the guidance that if the client pipelines MKCOL and LOCK 
> together and sees that the MKCOL failed but the LOCK succeeded, it needs 
> to realize that it may have created a locked, empty resource or it may 
> have locked some other client's collection -- and thus the client 
> probably needs to UNLOCK or figure out what kind of resource it has 
> locked before proceeding.

The risk of two clients simultaneously trying to create a resource with 
the same name, but of trying to create a collection, the other one 
trying to create a non-collection seems to be pretty low to me. I'm not 
convinced that we really need to talk about this case.

Best regards, Julian
Received on Saturday, 27 January 2007 11:35:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:36 UTC