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

RE: PROPFIND vs REPORT vs depth infinity

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 5 Aug 2002 21:34:59 +0200
To: "Clemm, Geoff" <gclemm@rational.com>, "WebDAV" <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCCEIEFBAA.julian.reschke@gmx.de>

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 Monday, 5 August 2002 15:35:22 GMT

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