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

RE: Lightweight PROPFIND requests

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 29 May 2002 08:41:45 +0200
To: "Jim Luther" <luther.j@apple.com>, <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCEEMEEKAA.julian.reschke@gmx.de>

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Luther
> Sent: Wednesday, May 29, 2002 3:19 AM
> To: w3c-dist-auth@w3.org
> Subject: Lightweight PROPFIND requests
> There are a few times when the Mac OS X WebDAV file system client needs
> to use the PROPFIND method with "Depth: 1" on a collection resource to
> determine if it contains any children resources. For example, POSIX
> requires that my rmdir code must not delete a directory (collection)
> unless it is empty. Since the WebDAV DELETE method doesn't work that way
> (it deletes all children), my code uses the PROPFIND method with "Depth:
> 1" to determine if the DELETE method can be called on the empty
> collection, or if ENOTEMPTY should be returned because the collection
> has children. I don't need any properties from that PROPFIND, just the
> list of children.
> I tried this:
> <?xml version="1.0" encoding="utf-8"?>
> <D:propfind xmlns:D="DAV:">
> <D:prop>
> </D:prop>
> </D:propfind>
> and it works with mod_dav. However (and this is my question), is this
> legal by the rule <!ELEMENT prop ANY>? I looked through the XML docs to
> see how ANY was defined but couldn't tell it allowed an empty set.

It's legal according to the DTD, and I don't think that RFC2518 explicitly
forbids it. It certainly works with our server.

> If that's illegal and I must I ask for at least one property, I'll just
> ask for the resourcetype property since it looks like the only property
> that MUST be defined for all DAV compliant resources (all of the other
> DAV properties are shoulds, or are MUSTs under certain conditions).

That's probably the cheapest workaround -- but I'd try to stay with the
former solution. If this breaks somewhere, please report the issue.
Received on Wednesday, 29 May 2002 03:07:47 UTC

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