fruux.com: getting 415 on a valid REPORT, if sync token is still "0"

[jobisoft]

I mentioned this already but Dominik from fruux asked me to open a new issue. This issue is specific to fruux.com, I did not see that with my sabre/dav testinstallation.

Sync a "fresh" (newly created, empty) collection as written in your how-to-guide. First, I get the initial copy of the collection (which is empty in this case) and also try to get the sync-token.

<d:propfind xmlns:d="DAV:" xmlns:cs="http://calendarserver.org/ns/">
  <d:prop>
     <cs:getctag />
     <d:sync-token />
  </d:prop>
</d:propfind>

The answer from fruux.com is as follows:

<d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:fx="http://fruux.com/ns" xmlns:cal="urn:ietf:params:xml:ns:caldav" xmlns:cs="http://calendarserver.org/ns/" xmlns:card="urn:ietf:params:xml:ns:carddav">
 <d:response>
  <d:href>/addressbooks/a3298191804/6cf052c8-d871-44a2-b118-438b2cd46328/</d:href>
  <d:propstat>
   <d:prop>
    <cs:getctag>http://sabre.io/ns/sync/0</cs:getctag>
    <d:sync-token>0</d:sync-token>
   </d:prop>
   <d:status>HTTP/1.1 200 OK</d:status>
  </d:propstat>
 </d:response>
</d:multistatus>

At some later time, I want to get the changes and do a REPORT

<d:sync-collection xmlns:d="DAV:">
  <d:sync-token>0</d:sync-token>
  <d:sync-level>1</d:sync-level>
  <d:prop>
    <d:getetag/>
  </d:prop>
</d:sync-collection>

This returns a 415.

[RESPONSE] : 415 : <?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:sabredav-version>3.1.0-alpha2</s:sabredav-version>
  <s:exception>Sabre\DAV\Exception\ReportNotSupported</s:exception>
  <s:message>No sync information is available at this node</s:message>
  <d:supported-report/>
</d:error>

After adding a contact via the web interafce, the exact same request returns a 403:

[RESPONSE] : 403 : <?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:sabredav-version>3.1.0-alpha2</s:sabredav-version>
  <s:exception>Sabre\DAV\Exception\InvalidSyncToken</s:exception>
  <s:message>Invalid or unknown sync token</s:message>
  <d:valid-sync-token/>
</d:error>

So I fall back to ctag sync and then ask for a new sync-token:

<d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:fx="http://fruux.com/ns" xmlns:cal="urn:ietf:params:xml:ns:caldav" xmlns:cs="http://calendarserver.org/ns/" xmlns:card="urn:ietf:params:xml:ns:carddav">
 <d:response>
  <d:href>/addressbooks/a3298191804/6cf052c8-d871-44a2-b118-438b2cd46328/</d:href>
  <d:propstat>
   <d:prop>
    <cs:getctag>http://sabre.io/ns/sync/1</cs:getctag>
    <d:sync-token>http://sabre.io/ns/sync/1</d:sync-token>
   </d:prop>
   <d:status>HTTP/1.1 200 OK</d:status>
  </d:propstat>
 </d:response>
</d:multistatus>

And from there on everything is fine.

I assume this is a bug, because the client should not evaluate the returned sync-token and interpreted "0" as "none". In that case, the server should return a 404 on the property itself. Right?

[evert]

This:

<d:sync-token>0</d:sync-token>

Is definitely wrong. Sync tokens must be urls and should be wrapped in a <d:href />

So it makes sense that if we send the wrong thing back, your client would use that wrong thing when doing the next request. This must be a fruux bug then.

[jobisoft]

Sure about the href wrapper? Fruux and other Servers send it this way:

<d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:fx="http://fruux.com/ns" xmlns:cal="urn:ietf:params:xml:ns:caldav" xmlns:cs="http://calendarserver.org/ns/" xmlns:card="urn:ietf:params:xml:ns:carddav">
 <d:response>
  <d:href>/addressbooks/a3298191804/6cf052c8-d871-44a2-b118-438b2cd46328/</d:href>
  <d:propstat>
   <d:prop>
    <cs:getctag>http://sabre.io/ns/sync/1</cs:getctag>
    <d:sync-token>http://sabre.io/ns/sync/1</d:sync-token>
   </d:prop>
   <d:status>HTTP/1.1 200 OK</d:status>
  </d:propstat>
 </d:response>
</d:multistatus>

[evert]

Oops, no href. Definitely a URI though:

https://tools.ietf.org/html/rfc6578#section-6.2

[jobisoft]

Let me know, when this has been fixed on fruux.com, so I can test it.