- From: Jason Crawford <nn683849@smallcue.com>
- Date: Tue, 24 Sep 2002 15:27:58 -0400
- To: "Lisa Dusseault" <lisa@xythos.com>
- Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
This thread seemed to get overlooked, so I want to get discussion going on it... On Sunday, 09/15/2002 at 11:31 MST, "Lisa Dusseault" wrote: > At this week's Interop event, as at last year's, many interoperability > problems were found with scenarios involving change methods where a lock > token is required. A long, animated, exciting conversation was held to > finally achieve consensus among attendees on goals for a new way to > supply lock tokens to servers. > > GOALS for Lock Token Provision > ------------------------------ > > 1. Clients should be able to provide lock tokens in conditional requests > that cause the request to fail if the token does not still match the > state. This goal is currently met by the If header, but this goal must > continue to be met by any new solution. > > 2. Clients should ALSO be able to provide multiple unqualified lock > tokens in order to prove that they have those tokens and can do write > requests legally, in a way that does not impose conditions on the > success of the request. This mechanism should not use or affect the > Lock-Token header which is required in UNLOCK to specify a single lock > token to remove or refresh. This mechanism should be capable of > supporting many values. > > 3. Servers should be able to inform clients when lock tokens being used > in any way are no longer valid. This helps clients keep their > understanding of the server's state up-to-date. I basically agree with (1) and (2). I value keeping the server driven submission of tokens seperate from client driven consistancy checks. Hopefully this will simplify the If: header semantics. (3) is new to me. I'd like to hear more discussion on it. Perhaps as a seperate thread. > Discussions on how to solve > --------------------------- > > 1. Already solved by If header. Only slight clarifications needed to > improve basic interoperability of this header (see below). OK > 2. The mechanism to provide multiple tokens could easily be a new > header. The syntax should involve comma-separated values, because then > lines can be split across multiple instances of the header according to > RFC2616 header rules. OK. I can see how that can be implemented without breaking compatibility. > 3. A new response header or two could allow servers to return invalid or > unnecessary lock tokens. This should be a response header so that the > information can easily be marshaled even on responses that already > contain a body. Again, the response header syntax should be > comma-separated. I'd like to hear more about the requirement for this. > > Slight changes to existing definitions > -------------------------------------- > > - The existing Lock-Token header is used to specify a single lock token, > in methods that must operate on a single lock. It is used on UNLOCK to > remove a lock. The LOCK refresh request should ALSO use this header > (and the If header should continue to be supported by servers in order > to handle existing clients). This includes the clarification that LOCK > refresh can only be used to refresh a single lock. That's a good thing, > because the Timeout header only exists once per request too. OK with me. > - An untagged token in the IF header should apply ONLY to the resource > named in the Request-URI. The original definition is that they apply to > any resources "affected" by the request. This has turned out to be too > ambiguous and arduous to determine. Also most lock tokens only apply to > one resource, not the entire set of resources "affected" by a request > like MOVE/COPY. Since any token in the IF header can be tagged with a > URL in order to make it explicit what resource the token refers to, we > can make the untagged token equally explicit without removing any client > functionality in the If header. OK. So what do other people have to say? J. ------------------------------------------ Phone: 914-784-7569
Received on Tuesday, 24 September 2002 15:32:51 UTC