Re: RFC-2518 LOCK-TOKEN: header

Geoff,
Some corrections and comments below in <jra> tags, but in summary, the
owner element is not sufficient to identify the owner of a lock, and is not
used by the server in any way. It is purely a mechanism for clients to
provide some more meaningful indication of the owner of a lock.

The authentication mechanisms are not specified by HTTP (although WebDAV
does specify Digest and Basic for secured connections), but the
authentication header is used by WebDAV to identify the user agent making
the request, and it is this header that is used to determine if the
requestor is the owner of the lock. The lock discovery element does not
contain this information.




"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>@w3.org on 01/25/2000
01:10:24 PM

Sent by:  w3c-dist-auth-request@w3.org


To:   w3c-dist-auth@w3.org
cc:

Subject:  Re: RFC-2518 LOCK-TOKEN: header


   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."
<jra>
Yes, but you can't figure out which ones are yours.
</jra>

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

and:

"User agent authentication has previously occurred via a mechanism
outside the scope of the HTTP protocol, in an underlying transport
layer."
<jra>
Its this user agent, identified by the authentication header, that is used
to actually enforce locks. As far as the server is concerned, the lock
token just goes on for the ride. It has to be specified, and the user agent
has to own the lock, but otherwise the lock token isn't used.
</jra>

   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.
<jra>
This is not the owner information used by the server to identify the owner
of the lock. Rather it is client information used to provide a more
meaningful indication of the owner of the lock for contact information. Use
of this element for identifing lock ownership would create an
interoperability problem because the actual contents are not specified in
the WebDAV spec.
</jra>

   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.
<jra>
Yes, and lock tokens will be marginally useful for this situation. The only
thing that can be done is a client can know if it got the lock from a LOCK
request, or by some other means (IPC, reading from a file, from the
DAV:lockdiscovery element, etc.). A client obtaining the lock from some
other means can only assume that there might be other clients operating
concurrently under the same principal, and can offer a warning before
overwriting the resource.
</jra>

Cheers,
Geoff

Received on Wednesday, 26 January 2000 18:01:13 UTC