- From: Yaron Goland <yarong@microsoft.com>
- Date: Wed, 26 Mar 1997 21:42:28 -0800
- To: "'Jim Whitehead'" <ejw@ics.uci.edu>, w3c-dist-auth@w3.org
I'm sorry, I thought we agreed that lock tokens had to be unique across space and time at the Irvine meeting. I didn't realize it was an open issue. If it is, I'm with the 6 foot tall Chair Dude. =) Yaron > -----Original Message----- > From: Jim Whitehead [SMTP:ejw@ics.uci.edu] > Sent: Wednesday, March 26, 1997 5:49 PM > To: Yaron Goland; w3c-dist-auth@w3.org > Subject: 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 Thursday, 27 March 1997 00:42:25 UTC