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

Re: Lightweight PROPFIND requests

From: Jim Luther <luther.j@apple.com>
Date: Wed, 29 May 2002 07:29:41 -0700
To: w3c-dist-auth@w3.org
Message-Id: <838226AC-7310-11D6-B08A-0003934B6A22@apple.com>

On Tuesday, May 28, 2002, at 11:41 PM, Julian Reschke wrote:

>> 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.

Thanks for the quick feedback. As you may have guessed, I'm attempting 
to reduce the number of transactions and the  amount of data transferred 
(and parsed) to the minimum possible. I'll continue to test our client 
for interoperability against all servers I can get access to and report 
any problems found.

- Jim
Received on Wednesday, 29 May 2002 10:30:19 GMT

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