- From: Steve Carter <SRCarter@novell.com>
- Date: Tue, 25 Mar 1997 13:33:44 -0700
- To: fielding@kiwi.ICS.UCI.EDU, yarong@microsoft.com
- Cc: w3c-dist-auth@w3.org
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