Re: Change to Lock-Token

No, the lock token is not a credential. Rather, it is important to know that
a previously obtained lock is still valid before execuiting some methods.
If the lock has been lost (timed out, server canceled or lost, admin canceled)
then the premise of the change has moved out from under you and must be
reevaluated before continuing.

-src

>>> "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU> 03/25/97 11:57AM >>>
>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 Tuesday, 25 March 1997 15:37:00 UTC