RE: GULP vs RFC2518bis

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

AltStyle によって変換されたページ (->オリジナル) /