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

RE: Adv Coll review

From: <ccjason@us.ibm.com>
Date: Tue, 3 Aug 1999 15:41:51 -0400
To: w3c-dist-auth@w3.org
Message-ID: <852567C2.00744809.00@D51MTA07.pok.ibm.com>

>>>> 4.2.2 Bindings to Collections
>>>> paragraph one, last last sentence -- REally.  It must respond
>>>> with 506 Loop
>>>> Detected?  Even if they are benign subloops?
>>>I'm not seeing how a loop could be benign for a Depth:
>>>infinity request.
>>>The kind of case we had in mind was:
>>>B1 is a binding to collection C1, which contains a binding
>>>B2 to collection
>>>C2, which contains a binding B3 to collection C1.
>>>What kind of case were you thinking about?
>>The same but... where the root of the infinite tree
>>(specified by the request
>>URI) is C4 and not involved in the loop.  C4 might have a C1
>>as a member for
>>example and the loop lies entirely within the tree.  If the
>>server can deal with
>>this, I don't see a reason for returning an error code.  But
>>perhaps I missed
>>the purpose for returning an error code for loops.
> I don't really see why the case is different if the loop is at
> the top level
> versus lower in the hierarchy.  But it seems right that if the
> server can
> detect the loop, it can do the right thing for a DELETE, MOVE, or COPY.
> What would we like the response element to be for a PROPFIND when it
> encounters a loop?  A 506 might be appropriate for that one response
> element.
Ahhh... PROPFIND.  Well, it would be a pity to reject the whole
request for the sake of flagging the loop.  Perhaps if 506 were a
multistatus sub-error code.  But perhaps that's what was being proposed
in the first place.  If so, the wording should be clarified.

In fact, in general, we probably should be clear about status
codes that are intended to reside within a MULTISTATUS response and
those that are intended to be the response error code..
(Do we even have vocabulary to distinguish?)
Received on Tuesday, 3 August 1999 17:10:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:17 UTC