Re: Change to Lock-Token

>> 2) Identity.  While a strong entity tag will correspond to the resource
>> when a lock is taken out on that resource, as soon as the resource is
>> changed its entity tag (strong for sure, weak potentially depending on the
>> scope of the change) will also need to change.  If intermediate results are
>> saved to the HTTP server before the lock is released, the lock token will
>> no longer correspond to the actual entity tag of the resource.
>
>This is a good argument for why lock tokens shouldn't be used as entity
>tags, then.

Hmm.  This is true.  However, perhaps I am confused on the benefit of using
an entity tag as a lock token.  I thought the benefit was that you get some
extra capability (unstated) by exploiting the equivalence of lock tokens
and entity tags.  However, since they are not guaranteed to be the same, it
then appears that an entity tag is only a convenient token which can be
reused at the time the lock is granted, thus gaining a small efficiency
advantage.  Was this the intent?

However, that discussion is probably moot.  Previously I wrote:

>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 Tuesday, 25 March 1997 20:18:38 UTC