Geoffrey M Clemm | 3 Aug 15:17 2003
Picon

RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings)


"Julian Reschke" <julian.reschke <at> gmx.de> wrote on 07/20/2003 12:18:01 PM:

> > From: Geoffrey M Clemm
> >
> > How about the following alternative:
> >
> > For PROPFIND, define a new 208 status code that means "resource already
> > reported".
> >
> > A server that detects a loop in a PROPFIND result, would use 208 status
> > code for the 2'nd (and subsequent) encounters with a given resource.  This
> > allows
> > the client to reconstruct the binding structure based on just a single
> > PROPFIND call.

> OK, this issue has been coming up several times (see
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0081.html> for
> the last time).
>
> 1) Can we get rid of 506 (loop detected)? No, we can't. 506 can occur as
> result of operations other than PROPFIND, for instance COPY.

I agree that we need the 506 for methods that want to just fail the request.
The 208 was for operations like PROPFIND, that do not want to fail, but want
to give an accurate report while avoiding the infinite loop.

> 2) What error condition do we need to really indicate for the documented
> example (PROPFIND depth infinity)? The problem is not with the resource
> itself or a specific binding to it. In fact, a PROPFIND depth:1 wouldn't
> indicate any special condition at all. The problem occurs *only* because
> there's a bind loop, yet the request asked for a depth: infinity resource
> listing. So there's not a specific resource that can be "blamed" -- instead,
> it's the traversal of the collection's children that can't be done, and for
> which optimally the response should indicate failure.

There is no error.  We just need to provide a way for the server to convey to
the client that there is a loop.

> 3) A similar problem exists with PROPFINDing deph != 0 on collections when
> access privileges forbid listing the members.

That can be handled by the appropriate status on the appropriate members.

> 4) Will clients that aren't aware of the ordering protocol ignore resources
> with a status of 208? Not necessarily -- there may be clients that accept
> all 2xx status codes as success (and I think those a stricly conforming to
> RFC2518 and RFC2616!). This would mean that we can't use a 2xx code, or if
> we do use it, we can simply use the approach outlined in
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0080.html>.

I believe the protocol should be designed to produce good behavior to a
client that understands the protocol, and reasonable behavior for a client that
does not.  I believe the 208 will produce this result.

> I'm not convinced that a new 2xx status code is a good idea -- one approach
> that's much more simpler would be just to forbid depth:infinity PROPFINDs on
> collections that contain bind loops and to define an according precondition
> value.

A server that believes that can chose to just return 506.  But a server should
be allowed to do better than this.

> If we *do* want a new 2xx code, I'd rephrase the status condition. As a
> matter of fact, the issue is *not* that the resource already was reported!
> In fact, having multiple bindings to the same resource within the same
> PROPFIND result is just fine.

The 208 status code is explicitly designed to allow a server to use it to
minimize the size of the response in this case as well.

> So, I'd propose:
>
> "208 OK, but children not listed"
>
> We could then extend the response body to indicate *why* children haven't
> been traversed:
>
> DAV:no-bind-loop (recursing below this collection would result in a loop)
> DAV:need-privileges (you are allowed to see this collection, but not it's
> content)> (see
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0080.html> for
> a proposal how to marshall that).

I see no need for this added complexity.  208 Already Reported handles
both of these cases equally well.

Cheers,
Geoff
Nevermann, Dr., Peter | 3 Aug 17:24 2003

BIND: precondition DAV:locked-overwrite-allowed

Some time ago, I asked what status code should a BIND request return, if the precondition
DAV:locked-update-allowed is violated. Apparently, there has been consensus in that is should be:

423 "Locked" with <D:error><D:locked-update-allowed/></error> in the response-body

What if DAV:locked-overwrite-allowed is violated? It could be:

1) 423 "Locked" with <D:error><D:locked-overwrite-allowed/></error> in the response-body

2) 409 "Conflict" with <D:error><D:locked-overwrite-allowed/></error> in the response-body

Isn't 2) more reasonable in this case, because this time it is not the resource identified by the request URI which is locked?

Thanks,
Peter

Julian Reschke | 4 Aug 11:53 2003
Picon
Picon

RE: BIND: precondition DAV:locked-overwrite-allowed


> From: w3c-dist-auth-request <at> w3.org [mailto:w3c-dist-auth-request <at> w3.org]On
> Behalf Of Nevermann, Dr., Peter
> Sent: Sunday, August 03, 2003 5:24 PM
> To: 'w3c-dist-auth <at> w3.org'
> Subject: BIND: precondition DAV:locked-overwrite-allowed
>
>
> Some time ago, I asked what status code should a BIND request
> return, if the
> precondition
> DAV:locked-update-allowed is violated. Apparently, there has been
> consensus
> in that is should be:
> 423 "Locked" with <D:error><D:locked-update-allowed/></error> in the
> response-body
> What if DAV:locked-overwrite-allowed is violated? It could be:
> 1) 423 "Locked" with <D:error><D:locked-overwrite-allowed/></error> in the
> response-body
> 2) 409 "Conflict" with
> <D:error><D:locked-overwrite-allowed/></error> in the
> response-body
> Isn't 2) more reasonable in this case, because this time it is not the
> resource identified by the request URI which is locked?

Agreed.

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

Julian Reschke | 4 Aug 14:52 2003
Picon
Picon

RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings)


> From: w3c-dist-auth-request <at> w3.org [mailto:w3c-dist-auth-request <at> w3.org]On
> Behalf Of Geoffrey M Clemm
> Sent: Sunday, August 03, 2003 3:18 PM
> To: w3c-dist-auth <at> w3.org
> Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY
> and bindings)
>
>
> ...
>
> > 2) What error condition do we need to really indicate for the documented
> > example (PROPFIND depth infinity)? The problem is not with the resource
> > itself or a specific binding to it. In fact, a PROPFIND depth:1 wouldn't
> > indicate any special condition at all. The problem occurs *only* because
> > there's a bind loop, yet the request asked for a depth: infinity
resource
> > listing. So there's not a specific resource that can be "blamed" --
instead,
> > it's the traversal of the collection's children that can't be done, and
for
> > which optimally the response should indicate failure.
>
> There is no error.  We just need to provide a way for the server to convey
to
> the client that there is a loop.

I really don't care how you call it. The client is asking for a recursive
listing, and the server can't provide it. The *problem* is that recursing
into the collection would lead to an infinite loop, so there's really no
issue with the collection itself.

> > 3) A similar problem exists with PROPFINDing deph != 0 on collections
when
> > access privileges forbid listing the members.
>
> That can be handled by the appropriate status on the appropriate members.

How? If you don't have permission to list the members of a collection, how
do you report it for a PROPFIND depth!=0?

> > 4) Will clients that aren't aware of the ordering protocol ignore
resources
> > with a status of 208? Not necessarily -- there may be clients that
accept
> > all 2xx status codes as success (and I think those a stricly conforming
to
> > RFC2518 and RFC2616!). This would mean that we can't use a 2xx code, or
if
> > we do use it, we can simply use the approach outlined in
> >
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0080.html>.
>
> I believe the protocol should be designed to produce good behavior to a
> client that understands the protocol, and reasonable behavior for a client
that
> does not.  I believe the 208 will produce this result.

I believe it has the same problem that you pointed out re: my proposal, in
particular:

"If we handled it the way proposed below, the old clients will just ignore
the new element, and the user will incorrectly conclude that the collection
had no child by that name."

I agree that it's less likely that an old client will treat 208 the same way
as 200, but it's quite possible.

> > I'm not convinced that a new 2xx status code is a good idea -- one
approach
> > that's much more simpler would be just to forbid depth:infinity
PROPFINDs on
> > collections that contain bind loops and to define an according
precondition
> > value.
>
> A server that believes that can chose to just return 506.  But a server
should
> be allowed to do better than this.

If we can find a way that is actually better. I fear that the 208 proposal
has the same problem as my original proposal, being that old clients may
incorrectly assume that the collection doesn't have children.

> > If we *do* want a new 2xx code, I'd rephrase the status condition. As a
> > matter of fact, the issue is *not* that the resource already was
reported!
> > In fact, having multiple bindings to the same resource within the same
> > PROPFIND result is just fine.
>
> The 208 status code is explicitly designed to allow a server to use it to
> minimize the size of the response in this case as well.

I see. So you'd also use it for all duplicates, no matter what the depth
parameter was and whether it's collection or not? This is more consistent,
yet it may cause old clients not to display the second binding to a resource
within a collection because it *doesn't* treat 208 as success.

So old clients that treat 208 as success will incorrectly assume that a
collection was empty, while old clients that treat 208 as error will fail to
display additional bindings to a resource.

> > So, I'd propose:
> >
> > "208 OK, but children not listed"
> >
> > We could then extend the response body to indicate *why* children
haven't
> > been traversed:
> >
> > DAV:no-bind-loop (recursing below this collection would result
> in a loop)
> > DAV:need-privileges (you are allowed to see this collection,
> but not it's
> > content)> (see
> > <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0080.html>
> for
> > a proposal how to marshall that).
>
> I see no need for this added complexity.  208 Already Reported handles
> both of these cases equally well.

I think not. Actually, I think that there is no easy way to marshall this
information in a way compatible with old clients. We've spent a lot of time
discussing this, but still don't have a solution. Therefore my alternate
proposal just to forbid this very special case.

Julian

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

Geoffrey M Clemm | 4 Aug 17:39 2003
Picon

RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings)


"Julian Reschke" <julian.reschke <at> gmx.de> wrote on 08/04/2003 08:52:26 AM:

> ... old clients that treat 208 as success will incorrectly assume
> that a collection was empty, while old clients that treat 208 as
> error will fail to display additional bindings to a resource.
>
> I think that there is no easy way to marshall this information in a
> way compatible with old clients. We've spent a lot of time
> discussing this, but still don't have a solution. Therefore my
> alternate proposal just to forbid this very special case.

My counter proposal is that servers who are concerned about this can
return 506 on the request as a whole, while servers that are not
concerned about old client behavior in this regard can take advantage
of 208.

Cheers,
Geoff
Nevermann, Dr., Peter | 4 Aug 17:50 2003

Clarification of COPY semantics with Overwrite: T

RFC2518, Section 8.8.4 states:

   If a resource exists at the destination and the
   Overwrite header is "T" then prior to performing
   the copy the server MUST perform a DELETE with
   "Depth: infinity" on the destination resource.

RFC3253, Section 1.7 states:

   If at the time of the request, there already is a
   resource at the destination that has the same
   resource type as the corresponding resource at the
   request-URL, that resource MUST NOT be deleted,
   but MUST be updated to have the content and dead
   properties of its corresponding member.

1) Resource-ID:
In terms of binding and with the semantics of RFC3253, I suppose that the DAV:resource-id of the resource being overwritten at destination doesn't change by the COPY operation. Right?

2) Bindings:
Suppose there is a collection C1 mapped to URI-1 with 2 bindings a1->R1 and a2->R2 ... moreover, a colletion C2 mapped to URI-2 with 2 bindings a1->R1' and a3->R3'.

Now I issue the follwing request:
  COPY URI-1
  Destination: URI-2
  Overwrite: T

How many bindings has C2 after the COPY? In the "old" semantics of RFC2518 the answer clearly is 2 since the tree of C2 gets deleted prior to the COPY. In the semantics of RFC3253 it could be 3: C2 is updated with the dead properties of C1, a1->R1' is updated with content+dead-props of R1, a2->R2' is created based of R2 and a3->R3' remains unchanged. Or should a3->R3' be unbinded?

Thanks,
Peter

Julian Reschke | 4 Aug 18:02 2003
Picon
Picon

RE: Clarification of COPY semantics with Overwrite: T

1) Yes.
 
2) 3 (I doubt that many servers get this right :-).
 
Julian
 

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

-----Original Message-----
From: w3c-dist-auth-request <at> w3.org [mailto:w3c-dist-auth-request <at> w3.org]On Behalf Of Nevermann, Dr., Peter
Sent: Monday, August 04, 2003 5:51 PM
To: 'w3c-dist-auth <at> w3.org'
Subject: Clarification of COPY semantics with Overwrite: T

RFC2518, Section 8.8.4 states:

   If a resource exists at the destination and the
   Overwrite header is "T" then prior to performing
   the copy the server MUST perform a DELETE with
   "Depth: infinity" on the destination resource.

RFC3253, Section 1.7 states:

   If at the time of the request, there already is a
   resource at the destination that has the same
   resource type as the corresponding resource at the
   request-URL, that resource MUST NOT be deleted,
   but MUST be updated to have the content and dead
   properties of its corresponding member.

1) Resource-ID:
In terms of binding and with the semantics of RFC3253, I suppose that the DAV:resource-id of the resource being overwritten at destination doesn't change by the COPY operation. Right?

2) Bindings:
Suppose there is a collection C1 mapped to URI-1 with 2 bindings a1->R1 and a2->R2 ... moreover, a colletion C2 mapped to URI-2 with 2 bindings a1->R1' and a3->R3'.

Now I issue the follwing request:
  COPY URI-1
  Destination: URI-2
  Overwrite: T

How many bindings has C2 after the COPY? In the "old" semantics of RFC2518 the answer clearly is 2 since the tree of C2 gets deleted prior to the COPY. In the semantics of RFC3253 it could be 3: C2 is updated with the dead properties of C1, a1->R1' is updated with content+dead-props of R1, a2->R2' is created based of R2 and a3->R3' remains unchanged. Or should a3->R3' be unbinded?

Thanks,
Peter

Lisa Dusseault | 4 Aug 18:43 2003

RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings)


> I really don't care how you call it. The client is asking for 
> a recursive listing, and the server can't provide it. The 
> *problem* is that recursing into the collection would lead to 
> an infinite loop, so there's really no issue with the 
> collection itself.

The client is asking for a recursive listing? That's one way to look at it.
Another way to look at it is that the client is asking for a listing of a
finite set of resources, and the specification can decide how to
successfully return properties of those resources in presence of loops.  It
serves no purpose for the client to get an infinite set of properties nor
does it want them.  So as we're defining what the behavior of
PROPFIND-depth-infinity is in the presence of loops, we can define what the
client "asks for" too, according to what we think the requirements are.

I agreed with your arguments about how existing clients might react to a new
status code.  I suspect that the way existing clients respond to a supposed
success (2xx) will be more interoperable than the way they will respond to a
supposed failure (4xx, 5xx).

Lisa

Lisa Dusseault | 4 Aug 18:53 2003

RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings)

Let's not encourage servers behave differently unless that's really necessary.  Clients that *do* support bindings, in particular, should be able to count on servers handling this case in predictable ways.
 
lisa
-----Original Message-----
From: w3c-dist-auth-request <at> w3.org [mailto:w3c-dist-auth-request <at> w3.org] On Behalf Of Geoffrey M Clemm
Sent: Monday, August 04, 2003 8:40 AM
To: w3c-dist-auth <at> w3.org
Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings)


"Julian Reschke" <julian.reschke <at> gmx.de> wrote on 08/04/2003 08:52:26 AM:

> ... old clients that treat 208 as success will incorrectly assume
> that a collection was empty, while old clients that treat 208 as
> error will fail to display additional bindings to a resource.
>
> I think that there is no easy way to marshall this information in a
> way compatible with old clients. We've spent a lot of time
> discussing this, but still don't have a solution. Therefore my
> alternate proposal just to forbid this very special case.

My counter proposal is that servers who are concerned about this can
return 506 on the request as a whole, while servers that are not
concerned about old client behavior in this regard can take advantage
of 208.

Cheers,
Geoff
Elias Sinderson | 4 Aug 19:47 2003

Re: URI scheme uniqueness

[...] <Elias Sinderson> Perhaps something along the lines of the following would be acceptable? "...are free to use any URI scheme so long as it meets the stated uniqueness requirements. One way to accomplish this is to use IETF-registered URI schemes."
<Julian Reschke> That's plain and simply wrong. The only way is to use an URI scheme that *both* is IETF-registered and meets the uniqueness criterium.
<Elias Sinderson> Goodness, you are correct, mea culpa - I see your point now.
<Elias Sinderson> This language seems specific enough to be unambiguous while flexible enough to allow for other mechanisms to ensure uniqueness. The drawback of not [...]
<Julian Reschke> See, this kind of proves that the spec needs to be enhanced. You and others seem to read it as a license to come up with "private" URI schemes, which is plainly wrong and breaks the uniqueness requirements. Therefore the text should be clarified.
<Elias Sinderson> Yes, I agree, the current text allows for a looser interpretation than is desired - consider me in favor of modifying the current wording.


Cheers,
Elias

Gmane