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 Tuesday, 25 March 1997 13:57:44 UTC