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

Re: RFC-2518 LOCK-TOKEN: header

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Tue, 25 Jan 2000 13:10:24 -0500
Message-Id: <10001251810.AA28231@tantalum>
To: w3c-dist-auth@w3.org
   From: jamsden@us.ibm.com

   If the lock token isn't returned in the header, there's no way for you to
   get the lock token of the lock you just created.

Section 6.3 of RFC-2518 states that you can get the lock token
through the lock discovery property:

"A lock token is a type of state token, represented as a URI, which
identifies a particular lock.  A lock token ... can also be found
through lock discovery on a resource."

   That's because the active
   lock element of the lock discovery property does not contain the
   authentication id of the principal owning the lock.

I can find no authentication id defined or required by RFC-2518.

In fact, RFC-2518  explicitly states that an authentication id is not
part of the WebDAV protocol:

"Locks MUST be enforced based upon whatever authentication mechanism
is used by the server, not based on the secrecy of the token values."


"User agent authentication has previously occurred via a mechanism
outside the scope of the HTTP protocol, in an underlying transport

   The lock tokens are in
   the lock discovery, but you can't figure out which ones you own.

This information is provided by the DAV:owner element in the
lockdiscovery property.

   I continue to believe this is an open issue that requires clients to
   persist their lock  tokens outside the WebDAV repository. Lock tokens are a
   pain enough for the rare case where they are actually useful.

How else do you handle the situation where the same principal has
several clients acting against the same resource?  I believe this will
be a common scenario.

Received on Tuesday, 25 January 2000 13:10:30 UTC

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