W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1999

FW: Circular Bindings

From: Slein, Judith A <JSlein@crt.xerox.com>
Date: Mon, 9 Aug 1999 09:08:19 -0400
Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD243E0@crte147.wc.eso.mc.xerox.com>
To: "'WebDAV'" <w3c-dist-auth@w3.org>
A useful note from Jason.

-----Original Message-----
From: ccjason@us.ibm.com [mailto:ccjason@us.ibm.com] 
Sent: Friday, August 06, 1999 6:51 PM
To: Slein, Judith A
Subject: Re: Circular Bindings

Jason also suggested in earlier e-mail that there is really no reason why a
request should fail when it encounters a cycle during Depth: infinity.  For
DELETE, MOVE, COPY, and LOCK if the server can detect the cycle (which is
presumed to be easy), it can do the right thing with it and report success.
For PROPFIND, we could just have the server report 506 for a single response
element whenever it encounters a collection for the second time, and not go
into that collection.
One other thing that I said was that there are two cases to consider...
 1) if the loop includes the request URI... and
 2) if the loop only includes elements that are pure descendents of
     the request URI.

The same thing goes for the destination URI in a copy.  If the destination
(or more precisely, the "parent" of the destination URI) is not included in
loop, the deletion phase of the COPY is pretty easy.  But consider if if the
destination (and it's parent) is in a loop....


if /a/b/c/d is the destination, then a deletion is probably also going to
various links and leave us
with /a/b/ before we try to actually begin copying at /a/b/c/d....  but
wait! we
can't copy to /a/b/c/d unless /a/b/c  exists.

Now if /a/b/c is the destination, once again the deletion phase will leave
with /a/b/.  And the COPY should work just fine.

Now let's take the above situation and also say that there exists
/e/c/d/b/c/d/b/c/d/...  And let's say the destination is /e/c/d/.  That's
same destination resource as in the troublesome first situation, but we are
using a different URI to specify it.   The deletion phase leaves us with
and /e/c/ and the subsequent COPY phase can be pulled off. with much of the
result that we would have expected in that first scenario.

Now let's us consider this previous siutation, where there is an /e/c, but
make the destination URI the same as the first situation: /a/b/c/d/.  Once
again, we are left with /a/b and /e/c/ after the deletion phase.  Are we
to go through with the COPY phase?  The parent resource still exists... but
URI that was used to specify it doesn't....  Hmmmm. :-)

Anyway, my point is that if the request URI (or the destination URI) is
in a loop, that can pose real problems that aren't as easily resolved as
that reside entirely decendants of request URI.  We should be aware of these
distinctive classes of loops.

Another observations that's not related to loops but that my example reminds
of.  In the rfc2518 we say that a COPY performs a implicit delete at the
destination.  That has the possibly unfortunate side effect that if a
portion of
the destination subtree is shared via bindings with another portion of the
space, that sharing is lost.  For that reason down the road I think we
have an operation that is much like DOS's XCOPY /s.  I don't want to delay
spec now for that.  It can be added later.

BTW, this also reminds me that with AdvColl, it is possible that a portion
the source tree and the destination might be common.  And that initial
phase of the COPY might actually essentially delete a portion of the source
tree.  It's probably a red herring, but it's probably also something we
mention in the spec.
Received on Monday, 9 August 1999 09:08:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:20 UTC