Does MKCOL no longer work on radicale?

[WhyNotHugo]

Hi! I've been contributing to vdirsyncer for quite some time, and I've recently stepped up to maintain it and bring it up to date (since it won't work on modern Pythons/libraries).

I've started testing against a docker-contained radicale 3.0, and noticed a single tests is now failing (where previously it wasn't with a ~June 2018 radicale). That's the creation of collections via MKCOL.

This is the body of the request I'm sending (MKCOL http://127.0.0.1:8001/radicale/test):

<?xml version="1.0" encoding="utf-8" ?>
  <D:mkcol xmlns:D="DAV:">
    <D:set>
      <D:prop>
        <D:resourcetype>
          <D:collection/>
          <ns0:addressbook xmlns:ns0="urn:ietf:params:xml:ns:carddav" />
        </D:resourcetype>
      </D:prop>
    </D:set>
  </D:mkcol>

I'm getting a 405 as a response.

Am I trying to use a feature that radicale does not support? (405 would seem to indicate that, but I'd rather confirm to be safe). Or is there something wrong on my testing?

[Unrud]

Radicale returns 405 if the collection already exists. https://github.com/Kozea/Radicale/blob/53c1648738f2672ccb34a53fb22f96489897ecd4/radicale/app/mkcol.py#L57-L59

[ArnyminerZ]

I have kind of a similar issue. I confirm the behavior told by @Unrud (405 is returned if the collection exists), but I think it's not creating collections correctly. I've analyzed the requests .web makes, and copied the exact same one. This is the MKCOL's request body at /arnyminerz/2a1fac41-e3a7-407e-ab7d-9511f06ad5b6/:

<?xml version="1.0" encoding="UTF-8"?>
<mkcol xmlns="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:CR="urn:ietf:params:xml:ns:carddav" xmlns:I="http://apple.com/ns/ical/" xmlns:INF="http://inf-it.com/ns/ab/">
  <set>
    <prop>
      <resourcetype>
        <CR:addressbook/>
        <collection/>
      </resourcetype>
      <displayname>Testing ab</displayname>
      <INF:addressbook-color>#ff0000ff</INF:addressbook-color>
      <CR:addressbook-description>Addressbook description</CR:addressbook-description>
    </prop>
  </set>

I'm getting 201: Created, so there should not be any issue.

At .web, the /arnyminerz/ endpoint now returns:

<?xml version="1.0" encoding="utf-8"?>
<multistatus xmlns="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:CR="urn:ietf:params:xml:ns:carddav" xmlns:ICAL="http://apple.com/ns/ical/" xmlns:RADICALE="http://radicale.org/ns/" xmlns:ns3="http://inf-it.com/ns/ab/">
  <response>
    <href>/arnyminerz/</href>
    <propstat>
      <prop>
        <resourcetype>
          <principal/>
          <collection/>
        </resourcetype>
      </prop>
      <status>HTTP/1.1 200 OK</status>
    </propstat>
    <propstat>
      <prop>
        <RADICALE:displayname/>
        <ICAL:calendar-color/>
        <ns3:addressbook-color/>
        <C:calendar-description/>
        <C:supported-calendar-component-set/>
        <CR:addressbook-description/>
      </prop>
      <status>HTTP/1.1 404 Not Found</status>
    </propstat>
  </response>
  ...
  <response>
    <href>/arnyminerz/2a1fac41-e3a7-407e-ab7d-9511f06ad5b6/</href>
    <propstat>
      <prop>
        <resourcetype>
          <collection/>
        </resourcetype>
      </prop>
      <status>HTTP/1.1 200 OK</status>
    </propstat>
    <propstat>
      <prop>
        <RADICALE:displayname/>
        <ICAL:calendar-color/>
        <ns3:addressbook-color/>
        <C:calendar-description/>
        <C:supported-calendar-component-set/>
        <CR:addressbook-description/>
      </prop>
      <status>HTTP/1.1 404 Not Found</status>
    </propstat>
  </response>
</multistatus>

So there's definitely an issue while adding the <CR:addressbook/> prop.

For comparison, this is the response for a .web created addressbook:

  <response>
    <href>/arnyminerz/78a89ad5-bfba-1d6b-5899-238ce1e27512/</href>
    <propstat>
      <prop>
        <resourcetype>
          <CR:addressbook/>
          <collection/>
        </resourcetype>
        <RADICALE:displayname>New addressbook</RADICALE:displayname>
        <ns3:addressbook-color>#16ffcfff</ns3:addressbook-color>
        <C:supported-calendar-component-set>
          <C:comp name="VTODO"/>
          <C:comp name="VEVENT"/>
          <C:comp name="VJOURNAL"/>
        </C:supported-calendar-component-set>
        <CR:addressbook-description>qwerty</CR:addressbook-description>
      </prop>
      <status>HTTP/1.1 200 OK</status>
    </propstat>
    <propstat>
      <prop>
        <ICAL:calendar-color/>
        <C:calendar-description/>
      </prop>
      <status>HTTP/1.1 404 Not Found</status>
    </propstat>
  </response>

There are a lot of missing props in the first one. Do you know what I may be doing wrong? Thanks in advance.

[ArnyminerZ]

A extra information. The mentioned addressbook called New addressbook has the following .Radicale.props file:

{"CR:addressbook-description": "qwerty", "D:displayname": "New addressbook", "tag": "VADDRESSBOOK", "{http://inf-it.com/ns/ab/}addressbook-color": "#16ffcfff"}

The other collection doesn't have any files in the directory.

[ArnyminerZ]

More information. After running a PROPPATCH with this body:

<?xml version="1.0" encoding="UTF-8"?>
<propertyupdate xmlns="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:CR="urn:ietf:params:xml:ns:carddav" xmlns:I="http://apple.com/ns/ical/" xmlns:INF="http://inf-it.com/ns/ab/">
  <set>
    <prop>
      <displayname>Testing ab</displayname>
      <INF:addressbook-color>#ff0000ff</INF:addressbook-color>
      <CR:addressbook-description>Addressbook description</CR:addressbook-description>
    </prop>
  </set>
</propertyupdate>

Now there's a .Radicale.props, but it's empty ({}). I'm starting to suspect there's something wrong with my request's body... 🤔

[ArnyminerZ]

Yeah, totally my bad, I've now added the Content-Length and Content-Type headers and it works perfectly.

[pbiering]

looks like solved, closing