Skip to content
This repository has been archived by the owner. It is now read-only.

Propfind of depth 1 finds no children of / #137

Closed
macosforgebot opened this issue Apr 19, 2007 · 10 comments
Closed

Propfind of depth 1 finds no children of / #137

macosforgebot opened this issue Apr 19, 2007 · 10 comments

Comments

@macosforgebot
Copy link

@macosforgebot macosforgebot commented Apr 19, 2007

@wsanchez originally submitted this as ticket:164

  • Keywords: 6310825

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

@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Apr 19, 2007

@wsanchez originally submitted this as comment:1:⁠ticket:164

  • Description modified
@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Apr 19, 2007

@wsanchez originally submitted this as comment:2:⁠ticket:164


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.

@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Apr 19, 2007

@wsanchez originally submitted this as comment:3:⁠ticket:164


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.

@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Jul 30, 2007

@wsanchez originally submitted this as comment:4:⁠ticket:164

  • Milestone changed from 1.0 to 1.1
@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Dec 15, 2007

@wsanchez originally submitted this as comment:5:⁠ticket:164

  • Milestone changed from 1.1 to 1.2
@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Mar 10, 2008

@wsanchez originally submitted this as comment:6:⁠ticket:164

  • Milestone changed from 1.2 to 1.3
@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Oct 28, 2008

@wsanchez originally submitted this as comment:7:⁠ticket:164

  • Milestone changed from CalendarServer-1.3 to CalendarServer-2.0
@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Mar 9, 2009

@wsanchez originally submitted this as comment:8:⁠ticket:164

  • Keywords 6310825 added
@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Mar 9, 2009

@wsanchez originally submitted this as comment:9:⁠ticket:164

  • Milestone changed from CalendarServer-2.0 to Later
@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Mar 26, 2015

@wsanchez originally submitted this as comment:10:⁠ticket:164

  • Status changed from new to closed
  • Resolution set to Not to be fixed

Expiring old bugs with unknown state and impact.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.