- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Tue, 25 Mar 1997 17:04:30 -0800
- To: masinter@parc.xerox.com, w3c-dist-auth@w3.org
>> 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