RE: Change to Lock-Token

Yaron Goland wrote:
>I was never arguing that lock tokens should be entity tags. What I was
>arguing for was that the format of a lock token should be the same as an
>entity tag. This would have, I thought, given us the benefit of being
>able to use lock tokens in if-match headers and thus be able to say
>things like "Don't execute this message unless my lock still exists."

OK, to my mind it is settled that entity tags should not be used as lock
tokens because they are not unique enough (due to the case of multiple
advisory locks against the same resource), and because they cannot be
reused in if-match headers.

However, just how unique lock tokens must be has not yet been settled.
Based on the argumentation in my previous post, it seems that lock tokens
might need to be globally and temporally unique.  That is, if my DAV server
generates a lock token, it is guaranteed to be unique across all other DAV
servers, and for all time.  Or does a lock token just need to be unique for
a few weeks (i.e., should a client be required to expire a lock token if it
has held onto it for too long?)

I have re-copied my rationale for this to the end of this message:

>>1) Uniqueness. According to my reading of the HTTP 1.1 specification, an
>>entity tag (strong or weak) need only be unique for a given resource.  DAV
>>has the extra requirement that lock tokens must be unique across an HTTP
>>server (and perhaps even globally unique).  Lock tokens are the "key" for
>>DAV locks, and hence having as unique a key as possible is very desirable.
>>Note that DAV locks are not a substitute for strong authentication working
>>with an access control scheme.
>
>Thinking through this some more, I have recalled more of the rationale for
>why uniqueness constraints cause entity tags to be insufficient as lock
>tokens.
>
>1. If multiple advisory locks are allowable on the same resource (advisory
>locks are currently not in the specification, but they are in the
>requirements as reservations), and they use the same lock tokens as
>exclusive write locks, then multiple simultaneous locks might be held on
>the same resource.  In this case, the entity tag is not sufficient, since
>each lock needs a separate lock token to distinguish it from other locks on
>the same resource.  However, this does not argue for global uniqueness,
>only more uniqueness than is provided by a minimally unique entity tag.
>
>2. If a single server is acting as the coordinating agent for several
>separate servers (such as might be the case for a large-scale
>implementation of WEBDAV which handles high numbers of users), having a
>lock token which is unique across those cooperating servers allows them to
>map a lock token back to the server which handles it.  This argues for
>uniqueness across those cooperating servers.
>
>3. If you look to a future when a protocol will hopefully exist to support
>a whole Internet of coordinating WEBDAV servers, the lock tokens need to be
>unique across the entire Internet, and hence globally unique.
>
>4. Since lock tokens may be held by a client long after they have been
>expired by the server, lock tokens must also be temporally unique (unique
>across time), since otherwise there is the potential that a client may hold
>an expired lock token which coincidentally matches a current token (taken
>out later by another person).  If a lock was taken out on a resource by
>person A and the lock token is the entity tag E, and no edits were
>initially written to that resource, and the lock expires, and then person B
>takes out another lock on the resource which is also granted the same
>entity tag E, person A could then potentially write to the same resource
>(unless it was caught by authentication).  This argues against the use of
>entity tags as lock tokens.

- Jim

Received on Wednesday, 26 March 1997 20:58:54 UTC