- From: Clemm, Geoff <gclemm@rational.com>
- Date: Fri, 24 Aug 2001 13:15:24 -0400
- To: WebDAV <w3c-dist-auth@w3.org>
The problem with not saying where the lock is, is that the lock token doesn't need to be a URL (i.e. it might not be something you can send a HTTP request to). So you need to send the UNLOCK request to a resource that is guaranteed to understand it, which for sure is the locked URL, and almost for sure is any child of the locked URL (since all those children are affected by the Depth:infinity lock). Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Friday, August 24, 2001 10:16 AM To: Clemm, Geoff Cc: WebDAV Subject: RE: Infinite depth locks and unlocking << If this were added, it would be reasonable to require a client to issue the UNLOCK against the locked URL. The alternative is to allow the UNLOCK to be applied to any URL that identifies a resource that is affected by the lock. I could live with that, if the working group prefers it, but I prefer the "must unlock the locked URL" approach. >> I'd even be comfortable with the approach that you don't even have to say where the lock is. The lock is supposed to be globally unique. And if the client wants to verify that it understands where the lock is, it could use an IF header. (Actually right now the IF header is used for UNLOCK, but changing that is on the issues list.) Of course if we feel the *server* *always* needs to verify the client's knowledge of the lock location, I can live with that too. J.
Received on Friday, 24 August 2001 13:05:54 UTC