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

RE: PROPFIND vs REPORT vs depth infinity

From: Clemm, Geoff <gclemm@rational.com>
Date: Thu, 8 Aug 2002 16:09:45 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B107839176@SUS-MA1IT01>
To: WebDAV <w3c-dist-auth@w3.org>

That sounds sensible to me.

If there are no objections, I'll add this as the resolution
to this issue to the RFC 3253 Errata/Issue list.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Thursday, August 08, 2002 4:01 PM
To: Clemm, Geoff; WebDAV
Subject: RE: PROPFIND vs REPORT vs depth infinity



Ok,

so we have:

- REPORT not defined for this depth --> 400 (bad request)

- REPORT is defined, but server doesn't allow depth infinity --> 403
(forbidden). Should we define an error condition name for this situation and
add that to the RFC3253 (proposal: "DAV:depth-infinity-allowed")?

Julian

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Monday, August 05, 2002 10:09 PM
> To: WebDAV
> Subject: RE: PROPFIND vs REPORT vs depth infinity
>
>
>
> I agree that if PROPFIND MAY refuse to process a Depth:infinity
> request, than it should also be the case that REPORT MAY refuse
> to process a Depth:infinity request.  For REPORT, I'd also define
> a DAV:error value for this condition, so that a client can tell
> that it is non-support for Depth:Infinity that caused the failure.
>
> But note that I think it is fine for specific reports to return 400
> (meaning that the report by definition does not allow
> the specified Depth), while other reports return 403
> meaning that this implementation
> does not support it, even if it the report is defined for
> that Depth.
>
> Cheers,
> Geoff
>
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Monday, August 05, 2002 3:35 PM
> To: Clemm, Geoff; WebDAV
> Subject: RE: PROPFIND vs REPORT vs depth infinity
>
>
> Sorry for not being clear.
>
> What I meant is that for the same reasons a server may want to reject
> PROPFINDs with depth infinity, it may want to reject REPORTs with depth
> infinity as well. In particular, I can use DAV:expand-property to
> simulate a
> PROPFIND/DAV:prop, so it doesn't seem to make sense to change RFC2518 to
> make PROPFIND/DAV:prop/depth-infinity optional, while requiring
> support for
> an equivalent REPORT (DAV:expand-property).
>
> Julian
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> > Sent: Monday, August 05, 2002 9:20 PM
> > To: WebDAV
> > Subject: RE: PROPFIND vs REPORT vs depth infinity
> >
> >
> >
> > What do you have in mind for making this consistent?
> >
> > There are some reports in RFC-3253 that are usefully applied with
> > Depth>0 (e.g. DAV:expand-property and DAV:version-tree).  There are
> > others that only make sense for Depth=0 (DAV:compare-baseline and
> > DAV:merge-preview).  So I agree that we can make the reports that only
> > make sense for Depth=0 to say so explicitly, as does the ACL spec.
> > Is that what you had in mind?
> >
> > Cheers,
> > Geoff
> >
> > -----Original Message-----
> > From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > Sent: Monday, August 05, 2002 2:45 PM
> > To: WebDAV
> > Subject: PROPFIND vs REPORT vs depth infinity
> >
> >
> >
> > Hi,
> >
> > re: RFC2518 issue: PROPFIND_INFINITY.
> >
> > So the plan is that servers MAY reject PROPFIND with depth
> > infinity, and the
> > currently suggested return value is 403 (forbidden).
> >
> > Now what applies to PROPFIND should apply to REPORT as well, right?
> >
> > The ACL draft defines only reports with depth == 0, and
> requires 400 (bad
> > request) otherwise.
> >
> > RFC3253 is silent about that issue, suggesting that servers may
> not reject
> > the request.
> >
> > It would be nice if we could make this consistent before it's
> too late...
> >
> > Julian
> >
>
Received on Thursday, 8 August 2002 16:10:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:01 GMT