Subject: RE: GULP vs RFC2518bis

From: "Clemm, Geoff" <[email-masked]>
Date: Sun, 9 Mar 2003 14:11:30 -0500

From: Julian Reschke [mailto:[email-masked]]

   > From: Lisa Dusseault
   >
   > Here's some initial feedback on the latest GULP.
   >
   > "An UNLOCK request deletes the lock with the specified lock token.
   >  The request-URL of the request MUST identify a resource that
   >  is either directly or indirectly locked by that lock.
   >  After a lock is deleted, no resource is locked by that lock."
   >
   > Do we really want to allow an UNLOCK to an indirectly-locked
   > resource to remove the lock on the directly locked parent?  I'd
   > like to know whether

   RFC2518 says about UNLOCK:

   "The UNLOCK method removes the lock identified by the lock token in
   the Lock-Token request header from the Request-URI, and all other
   resources included in the lock. If all resources which have been
   locked under the submitted lock token can not be unlocked then the
   UNLOCK request MUST fail.  "

   So I think GULP only repeats what RFC2518 has been saying all the
   time (BTW: this is issue UNLOCK_WHAT_URL on the open issues list).

Yes, this was just echoing what appeared to be in 2518.  I'd probably
go with the tighter restriction (i.e. the client must issue the UNLOCK
against the URL that was specified in the LOCK request), but either
one is fine with me.  Since this issue is already been tracked, I
suggest we handle this issue independently of GULP (the change to GULP
is obvious and trivial, i.e. replace "either directly or indirectly"
with just "directly").

   > "A lock token is "submitted" in a request when it appears in an If
   >   header tagged-list whose tag is the lock-root of the lock."
   >
   > 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.

   > Then this paragraph, with the substitution to "internal member"
   > made as Julian suggested...
   >
   >   "If a request would modify the content for a locked resource, a
   >   dead property of a locked resource, a live property that is
   >   defined to be lockable for a locked resource, or a member URL
   >   in a locked collection, the request MUST fail unless the
   >   lock-token for that lock is submitted in the request."
   >
   > Being picky here, this sentence is conditional on a request
   > modifying "a member URL" in a locked collection. Isn't it any
   > modifications to the internal member, not just the URL?
   > E.g. this definition must encompass a PUT to a indirectly locked
   > internal member, as well as a MOVE.

   No. The *shallow* lock on a collection locks it's member URLs. If
   the lock on the collection isn't deep, you can modify internal
   members without the lock token, as long as you don't change their
   name (affecting the state of the collection itself).

Julian is correct.  If the lock is deep, then the first phrase of
of this section handles the lock on the content of the member
resource.

Cheers,
Geoff

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 11 Mar 2003 08:18:56 -0800

GULP changes the way the If header works in a fairly way in all the

> 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

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 11 Mar 2003 17:46:23 +0100

Lisa,

> 	(<opaquelocktoken:e71d4fae-5dec-22d6-cc76-121d8d23f>) 

I just checked this format with 

1) moddav
2) IIS
3) SAP EP
4) sharemation

and none of the servers accept it (and I think that's correct).

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 11 Mar 2003 12:22:12 -0800

Sorry, I omitted one important detail for this to work. You need one
clause in the OR statement that will succeed, otherwise you'll get a 412
Precondition Failed response.  So take 2, this should work: 

DELETE /tld/ HTTP/1.1
     (Not <nolock>)

(No line returns, of course)

The request should work because:
 (1) The required lock tokens for the two locked descendants are there
 (2) the precondition succeeds because one Ored condition is true (Not
Nolock)

With the proposed changes in GULP, part (1) would fail because the
server would have to make sure the tokens were tagged correctly or
matched the Request-URI exactly.  I suppose the intention would be to
respond with 423 Locked because although the lock tokens are there,
they're not tagged correctly, even though the precondition is
successful?  I think that's a bad idea. The lock tokens are provided;
take them.

Lisa

> -----Original Message-----
> Sent: Tuesday, March 11, 2003 8:46 AM
> To: Lisa Dusseault; 'Clemm, Geoff'; 'WebDAV'
> Subject: RE: GULP vs RFC2518bis
> 
> 
> Lisa,
>

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 11 Mar 2003 21:34:19 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Tuesday, March 11, 2003 9:22 PM
> To: 'Julian Reschke'; 'Clemm, Geoff'; 'WebDAV'

But they haven't been submitted for the right URL. Is this really
sufficient?

>  (2) the precondition succeeds because one Ored condition is true (Not

"<nolock>" isn't a valid Coded-URL. Using "<DAV:nolock>" instead fails both
on moddav and Sharemation (can't try with IIS right now).

> successful?  I think that's a bad idea. The lock tokens are provided;

My understanding is that a client needs to supply the lock tokens tagged for
the right URLs. Where's the problem with that approach? It's interoperable
and works right now.

Julian