WebDAV properties returned back in request even after setting them

Question

I am trying to develop a simple CalDAV server for my application and in this regard I am trying to serve the initial PROPFIND request from the calendar client.

The calendar client requests for a set of properties (as shown below) to be set by the server in response to the request:

Method: PROPFIND /calendars/user/ HTTP/1.1

Request Header:

Accept-encoding  gzip, deflate
Accept  */*
Connection  keep-alive
Prefer  return=minimal
Host  192.168.0.12:8080
Brief  t
User-agent  Mac+OS+X/10.10.5 (14F27) CalendarAgent/316.1
Depth  0
Authorization  Basic YWRtaW46cGFzc3dvcmQ=
Accept-language  en-us
Content-type  text/xml
Content-length  743

Request Body:

<?xml version="1.0" encoding="UTF-8"?>
<A:propfind xmlns:A="DAV:">
 <A:prop>
   <B:calendar-home-set xmlns:B="urn:ietf:params:xml:ns:caldav"/>
   <B:calendar-user-address-set xmlns:B="urn:ietf:params:xml:ns:caldav"/>
   <A:current-user-principal/>
   <A:displayname/>
   <C:dropbox-home-URL xmlns:C="http://calendarserver.org/ns/"/>
   <C:email-address-set xmlns:C="http://calendarserver.org/ns/"/>
   <C:notification-URL xmlns:C="http://calendarserver.org/ns/"/>
   <A:principal-collection-set/>
   <A:principal-URL/>
   <A:resource-id/>
   <B:schedule-inbox-URL xmlns:B="urn:ietf:params:xml:ns:caldav"/>
   <B:schedule-outbox-URL xmlns:B="urn:ietf:params:xml:ns:caldav"/>
   <A:supported-report-set/>
 </A:prop>
</A:propfind>

As a response to the above PROPFIND request I set the response as shown below:

Response Header

Accept-encoding  gzip, deflate
Accept  */*
Connection  keep-alive
Prefer  return=minimal
Host  192.168.0.12:8080
Brief  t
User-agent  Mac+OS+X/10.10.5 (14F27) CalendarAgent/316.1
Depth  0
Authorization  Basic YWRtaW46cGFzc3dvcmQ=
Accept-language  en-us
Content-type  text/xml
Content-length  743

Response Body

String response = "<?xml version=\"1.0\" encoding=\"UTF-8\" ?>"+
            "<A:multistatus xmlns:A=\"DAV:\" xmlns:cs=\"http://calendarserver.org/ns/\">" +
            "<A:response>" +
                "<A:href>/calendars/user/</A:href>" + 
                "<A:propstat>" +
                    "<A:prop>" +
                        "<B:calendar-home-set xmlns:B=\"urn:ietf:params:xml:ns:caldav\"><B:href>/admin/calendar/test/</B:href></B:calendar-home-set>"+
                        "<B:calendar-user-address-set xmlns:B=\"urn:ietf:params:xml:ns:caldav\"/><A:href>mailto:admin@example.de</A:href></B:calendar-user-address-set>"+
                        "<A:current-user-principal><A:href>/principals/users/admin</A:href></A:current-user-principal>"+
                        "<A:displayname>Test calendar</A:displayname>"+
                        "<A:principal-collection-set><A:href>/principals/users/</A:href><A:href>/principals/groups/</A:href></A:principal-collection-set>"+
                        "<A:principal-URL><A:href>http://192.168.0.12/principals/users/admin/</A:href></A:principal-URL>"+
                        "<A:supported-report-set xmlns:n2=\"urn:inverse:params:xml:ns:inverse-dav\" xmlns:n3=\"urn:ietf:params:xml:ns:carddav\" xmlns:A=\"DAV:\" xmlns:n1=\"urn:ietf:params:xml:ns:caldav\">"+ 
                        "<A:supported-report><A:report><n1:calendar-query/></A:report></A:supported-report>"+
                        "<A:supported-report><A:report><n1:calendar-multiget/></A:report></A:supported-report>"+
                        "<A:supported-report><A:report><n2:acl-query/></A:report></A:supported-report>"+
                        "<A:supported-report><A:report><A:sync-collection/></A:report></A:supported-report>"+
                        "<A:supported-report><A:report><A:expand-property/></A:report></A:supported-report>"+
                        "<A:supported-report><A:report><n3:addressbook-query/></A:report></A:supported-report>"+
                        "<A:supported-report><A:report><n1:free-busy-query/></A:report></A:supported-report>"+
                        "</A:supported-report-set>"+    
                        "<B:schedule-inbox-URL xmlns='urn:ietf:params:xml:ns:caldav'><href xmlns='DAV:'>/calendars/__uids__/admin/inbox/</href></B:schedule-inbox-URL>"+
                        "<B:schedule-outbox-URL xmlns='urn:ietf:params:xml:ns:caldav'><href xmlns='DAV:'>/calendars/__uids__/admin/outbox/</href></B:schedule-outbox-URL>"+
                        "<C:dropbox-home-URL xmlns='http://calendarserver.org/ns/'><href xmlns='DAV:'>/calendars/__uids__/admin/dropbox/</href></C:ropbox-home-URL>"+
                    "</A:prop>" +
                    "<A:status>HTTP/1.1 200 OK</A:status>" +
                "</A:propstat>" +
            "</A:response>" +
        "</A:multistatus>";

After sending the response to client, the client again sends back the same properties (not all - as shown below).

<?xml version="1.0" encoding="UTF-8"?>
<A:propfind xmlns:A="DAV:">
  <A:prop>
    <A:current-user-principal/>
    <A:principal-collection-set/>
  </A:prop>
</A:propfind>

So can anyone let me know where am I going wrong in setting these properties ?

There might not be anything wrong in particular. Some clients are just a bit chatty. — Evert, Nov 04 '15 at 00:07
Evert since I am getting back these request once again, I am not able to proceed further. That is, serving calendar home or the next steps. How do I tackle ? — SGuru, Nov 04 '15 at 00:34
Can you share the _actual_ full responses (including headers?). One thing you might want to try as well is to use relative uri's everywhere instead of the absolute ones. — Evert, Nov 04 '15 at 00:38
1) What happens if you respond to the second request? What will the client to next? 2) It's not a task for the server to serve the calendar home. It's a task for the client to request it. — Martin Prikryl, Nov 04 '15 at 07:08
Evert Thank you for the reply. I have edited the above post to include the complete request and response (including the headers). Also, I will check with relative uri now. — SGuru, Nov 04 '15 at 12:23
Martin Prikryl Thank you for your reply. 1. When I respond the next request with same response. It doesn't send anymore request, but it says can't connect to the account "to my server -192-168..." . 2. The client asks for the calendar home in the first request itself (as shown in the above request code). — SGuru, Nov 04 '15 at 13:22
Also, I strongly suggest building your XML response bodies as XML, and not as strings. A whole lot less ugly, a whole lot easier to maintain, and a whole lot easier to debug. — Brian Warshaw, Nov 06 '15 at 12:03
Brian Warshaw Thanks for the reply. Yes the client is Mac OS X calendar App. OK I would convert them to XML format — SGuru, Nov 06 '15 at 12:07
What does Calendar show after the request? Is it displaying what you would expect? — Brian Warshaw, Nov 06 '15 at 14:54
No not. It is supposed to request for list of calendars from the server. It doesn't request anything further apart from the same `current-user-principal` property. — SGuru, Nov 06 '15 at 15:09
What leads you to believe that it is supposed to now request a list of calendars from the server? And what specifications are you using to code your responses to the client? — Brian Warshaw, Nov 06 '15 at 15:43
I am using [RFC 4791](https://www.ietf.org/rfc/rfc4791.txt) to encode the responses. The reason for my inference is: once the server answers the client for its PROPFIND request and its the client task to request for the list oof calendars which is could synchronize. I think I had read it some blog as well on developing caldav server. kindly let me know if I am not taking the right direction. Thank you for your responses. — SGuru, Nov 06 '15 at 16:10

score 1 · Answer 1 · answered Apr 13 '16 at 14:46

1

As Evert mentioned in the comment section, the client is bit chatty. After several observations even I found the same.

answered Apr 13 '16 at 14:46

SGuru

645
1
11
28

WebDAV properties returned back in request even after setting them

1 Answers1