- From: Lisa Dusseault <lisa@xythos.com>
- Date: Sun, 15 Sep 2002 11:31:53 -0700
- To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
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. Discussions on how to solve --------------------------- 1. Already solved by If header. Only slight clarifications needed to improve basic interoperability of this header (see below). 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. 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. 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. - 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. Lisa
Received on Sunday, 15 September 2002 14:32:51 UTC