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

Hi,

I just noticed that in

<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0001.html>

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 
URL.

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

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 GMT

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