Subject: Puzzle: DELETE of a locked collection

From: Greg Stein <[email-masked]>
Date: Thu, 13 Apr 2000 04:51:59 -0700 (PDT)

Consider the following directory structure:

  Collection         [locked with token A, depth=0]
   \
    SubCollection    [locked with token B, depth=infinity]
     \
      File1
      File2          [these inherit token B]
      ...
      FileN

Now, how do you delete SubCollection?

Note that you must provide token A to remove SubCollection from
Collection. Also, you must provide token B for SubCollection *and*
File1..N.

What's the IF: header look like?

(presume that you cannot delineate all the (recursive) members of
 SubCollection and insert them *all* into the IF: header)

I can't see a way to do it. Normally, no-tag-lists are used for specifying
locks for a hierarchy. But you must use a tagged-list to specify token A.

Ideas?

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Thu, 13 Apr 2000 11:19:10 -0400 (EDT)

Greg's question illustrates something that I believe is inherently
broken in the current WebDAV approach to operating against write-locked
resources.

When you are performing an operation against write-locked resources,
all you should be required to do is to include the appropriate list of
lock-tokens with your request.  The semantics is then very simple:

If any of the resources that your request attempts to modify is locked
with a lock token not in your list, the request fails.

Instead of this simple list, 2518 gives us the wonderfully baroque
(pronounced "broke" :-) If header, which lets us do ands and ors and
nots of state tokens and entity tags, and even tag the expressions
with the resource it should apply to, but does not in fact let us do
the one thing we really want to do, namely identify a list of lock
tokens.

The answer I'd like us to make is that you can include an arbitrary
number of Lock-Token headers with a request, and this defines the
lock token list for your request (no If header required).

Until then, as far as I can tell, 2518 requires Greg to do the
obviously non-scalable insertion of a tagged list for *every* member
of the collection being moved in the If header.

Cheers,
Geoff

   Date: Thu, 13 Apr 2000 04:51:59 -0700 (PDT)
   From: Greg Stein <[email-masked]>

   Ideas?

   Cheers,
   -g

---

From: Greg Stein <[email-masked]>
Date: Thu, 13 Apr 2000 13:18:59 -0700 (PDT)

> lock token list for your request (no If header required).

Agreed.

Go one step further, then: if you do not use IF: to specify lock tokens,
it is only good for etags. If that is the case, then we have If-Match in
HTTP/1.1. Why keep the IF: header? :-)

> of the collection being moved in the If header.

Based on feedback from some people on the dav-dev mailing list, I'm going
to do the following:

*) if a tagged-list state-list specifies a URL and its locktoken, then the
   state-list will be applied to the internal members (to the extend of
   the lock depth). this will effectively replicate the state list down to
   all affected members.
   (any existing tagged-list for an internal member will override this
    implied state-list)

This should solve the problem, even if it isn't "strictly" by-the-book. I
have no idea how hard this will be, but I'll dig in and try it...

Cheers,
-g

---

From: Juergen Reuter <[email-masked]>
Date: Thu, 13 Apr 2000 22:29:00 +0200

Please, remember that:

"Multiple message-header fields with the same field-name may be
present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list [i.e., #(values)]"
(RFC 2068, section 4.2).

Hence, following Geoffrey's thoughts, it may be reasonable to redefine
the Lock-Token header as follows:

Lock-Token = "Lock-Token" ":" 1#Coded-URL

Bye,
     Juergen

Geoffrey M. Clemm wrote:
> number of Lock-Token headers with a request
> ...

[email-masked] wrote:
> That's because 1) you can't mix tagged and
> non-tagged lists in the same If header
> ...

---

From: Greg Stein <[email-masked]>
Date: Thu, 13 Apr 2000 16:05:00 -0700 (PDT)

I believe that I have an answer to this. The trick is to realize that a
no-tag-list can specify a set of OR'd states. So the answer is:

If: (<A>) (<B>) (Not <A>) (Not <B>)

Ugly, but it basically means that every resource will match something, and
that the lock token is provided to navigate through the lock.

Eek.

-g

---

From: Greg Stein <[email-masked]>
Date: Thu, 13 Apr 2000 16:17:00 -0700 (PDT)

Oh. I found Yet Another Bastard Solution.

S9.4.2 specifies that if no Tagged-list matches the resource [URI], then
the If: header should be ignored.

S7.6 simply states that lock tokens must be supplied in an If: header. It
says nothing about them being supplied in a *matching* Tagged-list or
No-tag-list.

Therefore, the following If: header should *always* succeed:

    If: <DAV:just-ignore-this> (<A> <B>)

Good fun, huh?

Okay. So we have found a way to circumvent the *intent* of the spec, but
what is the true answer here? What *should* be the specification?

IMO, the above form is just like submitting a Lock-Token header with a
list of locktokens. We should use the Lock-Token header.

This is not required, but I highly recommend it: also throw out the If:
header. The damn thing is complicated as all hell. I've got a couple
thousand lines of code just to deal with the bugger. And it is *still* not
processing it correctly despite many revisions, refinements, and a couple
people working on it. Call us bad coders, but I like to think it is just
because the thing is too complex and possibly unclearly specified.

Cheers,
-g