- From: Lisa Dusseault <lisa@xythos.com>
- Date: Tue, 11 Mar 2003 08:18:56 -0800
- To: "'Clemm, Geoff'" <gclemm@rational.com>, "'WebDAV'" <w3c-dist-auth@w3.org>
GULP changes the way the If header works in a fairly way in all the proposed wordings I've seen. Some of the recent discussion: > > This doesn't mention untagged-list syntax in If header. > Is a corollary > > of this proposal that we remove the untagged-list > syntax? Or was the > > omission of untagged-list accidental? I'd prefer to > keep the untagged > > list syntax, so I believe this should read: > > "A lock token is "submitted" in a request when it > appears in an If > > header." > > I'd prefer > > "when it appears in an If header tagged-list whose tag is > the lock-root > of > the lock, or if it appears in an untagged list and the > request-URL is the > lock-root of the lock". > > I agree this change should be made, and I prefer Julian's > rewording, as > it is more precise. I'll post a new version of GULP with this change. > This changes the way the If header is parsed. It means the client can't submit an untagged token list without matching the lock-root of the token against the Request-URI. That's not how the If header worked before. I'll give an example of what should work today, and what GULP forbids. Let's say I want to DELETE an unlocked collection, and in that collection are two independently locked descendants. The descendants have these two Etags: <opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6> and <opaquelocktoken:e71d4fae-5dec-22d6-cc76-121d8d23f> The following request should allow the lock tokens to match and the server should accept both tokens, because they are in an OR list: DELETE /tld/ HTTP/1.1 If: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6>) (<opaquelocktoken:e71d4fae-5dec-22d6-cc76-121d8d23f>) I don't want to change this behaviour, because it's a very convenient way for a client to provide a bunch of lock tokens in exactly the situation of deleting or moving a collection with locked descendants. Lisa
Received on Tuesday, 11 March 2003 11:19:12 UTC