Setting ACLs that use DAV:property fails with BAD_REQUEST

[macosforgebot]

jorge@… originally submitted this as ticket:803

• Keywords: acl

---

I'm trying to set an ACL for a calendar with the following body:

<?xml version="1.0" encoding="utf-8" ?>
<acl xmlns="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
 <ace>
  <principal>
   <property>
    <owner/>
   </property>
  </principal>
  <grant>
   <privilege>
    <all/>
   </privilege>
  </grant>
 </ace>
 <ace>
  <principal>
   <authenticated/>
  </principal>
  <grant>
   <privilege>
    <C:read-free-busy/>
   </privilege>
  </grant>
 </ace>
</acl>

CalendarServer answers with a 400 Bad Request, and logs the following error message:

2013-03-29 13:47:00+0100 [-] [caldav-1]  [-] [twext.web2.dav.method.acl#error] Error while handling ACL body: Attribute name is required in {DAV:}property element

WebDAV ACL RFC doesn't mention the need for this attribute, and there is even an ACL example with DAV:property that doesn't use it at section 5.9: http://webdav.org/specs/rfc3744.html#rfc.section.5.9

CalendarServer should accept the above ACL as it is well formed.

[macosforgebot]

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

• Summary changed from Setting ACLs that use DAV:property fails to _Setting ACLs that use DAV:property fails with BADREQUEST
• Priority changed from 1: Blocker to 4: Nice to have
• Milestone set to Later

---

The response code here is probably wrong; it should be FORBIDDEN, not BAD_REQUEST.

But the result is the same for you: do not set ACLs, we do not support doing that and never will. We did, once upon a time, and that was a big mistake.

So, what you want will not be fixed, but we should keep this open to fix the status code. Low priority, though.

[macosforgebot]

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

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

---

Expiring old bugs with unknown impact