RE: Change to Lock-Token

The goal behind having if-lock is for atomicity. Locks can disappear at
any time for any reason. Having an "if-lock" lets a user say "Only
process this request if my lock is still in force."

In addition I will be proposing advisory locks in the context of
versioning. So users will want to be able to say "Only process this
request if no locks are outstanding on the resource."


	Yaron

> -----Original Message-----
> From:	Roy T. Fielding [SMTP:fielding@kiwi.ICS.UCI.EDU]
> Sent:	Tuesday, March 25, 1997 9:54 AM
> To:	Yaron Goland
> Cc:	w3c-dist-auth@w3.org
> Subject:	Re: Change to Lock-Token 
> 
> >The problem is that e-tags are opaque and we really need to be able
> to
> >put lock tokens into if-match headers. Are we going to be forced to
> >invent our own "if-match" header for lock tokens or can we extend the
> >if-match syntax to accept tokens?
> 
> If what you want to do is say to the server "do this method only if
> the
> resource is still locked with this lock token", then yes you will need
> to define yet another If-* header field.  That design decision was
> made
> by the HTTP WG in spite of my vehement objections, as Larry can
> attest.
> 
> >My feeling is that lock tokens should be URIs (this also gives the
> >possibility of having cross server locks on day, FAR FAR FAR into the
> >future =) and that we should extend the e-tag if headers to accept
> >tokens instead of just quoted strings.
> 
> There is zero chance of extending If-Match or If-None-Match -- they
> were
> not designed to be extensible and cannot be safely changed once
> implemented.
> In any case, making the lock token a URI would not improve
> cross-server
> locks, since either the client would have to ask for the lock on each
> server or the requested server would have to establish the lock in
> such
> a way that it affects the other servers, and thus in a way that allows
> any server to know of the lock and the lock token.
> 
> BTW, why do you need the functionality of If-Lock?  Are you treating
> the
> lock token as a credential for authentication?
> 
> .....Roy

Received on Wednesday, 26 March 1997 01:43:49 UTC