- From: Clemm, Geoff <gclemm@rational.com>
- Date: Fri, 27 Sep 2002 09:42:21 -0400
- To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
- Message-ID: <3906C56A7BD1F54593344C05BD1374B1085A9376@SUS-MA1IT01>
Could someone post what exactly were the interoperability problems that were found? As far as I can tell, the If header is a superior way of handling the locking scenarios than the alternatives being proposed. In particular, I do not find the "separation of concerns" argument convincing, since issue #3 (detecting when you have an invalid lock token) is exactly the reason why a single header is used both to check state and demonstrate possession of the required token (i.e. I believe the concerns are inherently linked). In particular, I do not support #2, because it leads a client to perform updates against resources that it has lost its lock on. Why would a client ever want to do that, instead of reacquiring a lock? A key benefit of locks as currently defined is that they solve the lost update problem for servers that cannot provide etags, but updating a resource for which you have lost your lock opens you up to the lost update problem. Note: If lengthy If headers has proven to be a problem, I am happy to allow a "," to separate If clauses, so that you can submit multiple If headers in one request. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:nn683849@smallcue.com] 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 Friday, 27 September 2002 09:42:55 UTC