Propfind of depth 1 finds no children of /

[wsanchez@…]

4/10/07 11:30 AM TIMOTHY:

A PROPFIND with depth 1, only on "/", is missing children, it's the exact same result as a propfind of depth 0.

* STEPS TO REPRODUCE

PROPFIND / HTTP/1.1
Content-Length: 160
Depth: 1
Content-Type: text/xml; charset="utf-8"

<?xml version='1.0' encoding='UTF-8'?>
<ns0:propfind xmlns:ns0="DAV:"><ns0:prop><ns0:getetag /><ns0:resourcetype /><ns0:displayname /></ns0:prop></ns0:propfind>

* RESULTS

HTTP/1.1 207 Multi-Status
Content-Length: 399
Accept-Ranges: bytes
Server: Twisted/2.5.0+rUnknown TwistedWeb/[twisted.web2, version 0.2.0 (SVN rUnknown)]
Last-Modified: Wed, 04 Apr 2007 22:31:01 GMT
DAV: 1, access-control
ETag: "C773F-2A8-46142725"
Date: Tue, 10 Apr 2007 18:17:20 GMT
Content-Type: text/xml

<?xml version='1.0' encoding='UTF-8'?>
<multistatus xmlns='DAV:'>
  <response>
    <href>/</href>
    <propstat>
      <prop>
        <getetag>"C773F-2A8-46142725"</getetag>
        <resourcetype>
          <collection/>
        </resourcetype>
        <displayname>data</displayname>
      </prop>
      <status>HTTP/1.1 200 OK</status>
    </propstat>
  </response>
</multistatus>

Exists in r1458

[wsanchez@…]

4/10/07 2:02 PM TIMOTHY: Unauthenticated HTTP access does see the children. I figured I would've seen /calendars and /principals, or the views would've been consistent.

4/10/07 3:37 PM Wilfredo Sanchez: By HTTP, I assume you mean GET, and yes, Cyrus and I implemented different policies here.

4/10/07 5:44 PM Cyrus Daboo: I still believe that if you don't have DAV:read access to a resource you should not have a way to find out that it exists. i.e. it should not be returned in a PROPFIND Depth:1 on the parent.

There is a simple fix to Tim's issue: require authentication on the root resource. If you are going to require it on all the resources below, why not on the root? I know that it would be nice to have the public "welcome to xxx server" page accessible without authentication, but if you can't actually do anything on the server without authenticating anyway, why not require it?

Since we disagree on this we could try the tie-breaker of posting to the webdav list to solicit suggestions. But I suspect the response will be that we are free to do whatever we want in this case, perhaps even use a new privilege to control the behavior we want.

At the end of the day, if we do relax the current restriction we do have to make sure that none of the properties on the child resources are exposed via PROPFIND - only a DAV:href and DAV:status should be present. It might be interesting to see whether WebDAV client choke on that...

4/10/07 5:47 PM Cyrus Daboo: BTW This is really a deficiency in HTTP auth. There ought to have been a mode in which a server could return a WWW-Authenticate header on a successful unauthenticated request to indicate to the client that if they did authenticate they might actually get more information.

4/10/07 6:06 PM Wilfredo Sanchez: Sure, though it's a tough nut to crack, since it could depend on who they authenticate as.

[wsanchez@…]

It's pretty clear to me that DAV ACL allows us to go either way on this. Let's make this behave the same as filesystems do on UNIX; if you can read the collection, you can see the names of its children. If you think the names are private information, you need to make the collection appropriately secure.