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

GULP 5.6 vs issue UNLOCK_WHAT_URL (65)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 31 May 2004 15:13:33 +0200
Message-ID: <40BB2F7D.3060606@gmx.de>
To: w3c-dist-auth@w3.org


I just noticed that in


we write...:

   "An UNLOCK request deletes the lock with the specified lock token.
   The request-URL of the request MUST identify the resource that
   is directly locked by that lock.  After a lock is deleted,
   no resource is locked by that lock."

This was a change to the previous GULP version. However, the discussion 
attached to issue entry UNLOCK_WHAT_URL 
(<http://www.webdav.org/wg/rfcdev/issues.htm>) seems to indicate that we 
agreed upon allowing any URL protected by the lock to be used as request 

1) We should agree on one of the two; and fix the other document 

2) RFC2518 seems to allow both interpretations:

    "The UNLOCK method removes the lock identified by the lock token
    in the Lock-Token request header from the Request-URI, and all
    other resources included in the lock."

3) Back when I tested this, both Apache/moddav and Xythos were 
implementing this, and so are we (I think). Microsoft IIS doesn't 
support deep locks, so it's not relevant here.

Therefore it seems that we should undo that particular change from GULP 
5.5 for the sake of interoperability with older clients that may rely on 
it (this seems to be harmless).

Best regards, Julian

<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Monday, 31 May 2004 09:14:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:31 UTC