4

I have custom built a CalDav server in C# for a product we are selling and everything works quite peachy. There is just one thing that is bothering me, but nowhere in the standards I could find a solution for my 'annoyance'.

When a client is connected to our CalDav server and creates a new Event, the client tells the server what the UID is for the Event that is submitted. Our server saves that Event in it's own database (as a different model) and that object gets an ID from our server.

I respond to the client that the object is saved and that it got a new location, which makes the client retrieve the latest version of the object.

But I would love to change the UID of the Event that was sent by the client, to the ID we use to look-up the object.

Is there a way to tell the client "I stored the object for you, but please retrieve this version, with a changed UID and dump the old one?"

Because the way it works now is that the client indeed retrieves the newly created Event after it was sent to us (using a PUT request), but because of the new UID the Event has, the client thinks it is a new object.

I already tried doing this by saying to the client that the item that they tried to post to /mycaldav/SOME-WEIRD-UID-HERE.ics should actually be posted to /mycaldav/MY-OWN-UID.ics.

This resulted in a post to the right URL, but with the wrong UID.

Wim Haanstra
  • 5,918
  • 5
  • 41
  • 57

1 Answers1

3

It's quite simple: in CalDAV/CardDAV the UID is assigned by the client (and for PUTs the URL as well). You can't just change it, as the client might as well need "its" ID to associate stuff on the client side (e.g. attachments, scheduling requests, associated contacts and so on).

Summary: You need to keep a map of the client assigned UID (and URL) to your internal ID on your server. It's inconvenient, but the way it works. Maybe just store it in the same structure which you use to store all the X properties of the client?

hnh
  • 13,957
  • 6
  • 30
  • 40
  • Thanks, that is what we are currently doing, but I was hoping on some kind of way to force a 'refreshed' item to the client. But indeed this seems to be impossible. – Wim Haanstra Sep 03 '14 at 05:07
  • 1
    A kinda convention to trigger a refresh is to not return an ETag in the PUT response, but this is also really edgy wrt HTTP RFCs. There is also work on a Prefer header to return changed content. This has something similar: https://svn.calendarserver.org/repository/calendarserver/CalendarServer/trunk/doc/Extensions/calendarserver-bulk-change.txt (return-changed-data). BUT: Even if you could return new content 'immediately', it is still a VERY bad idea to change the UID for reasons I mentioned. You just can't expect a client to reconcile all the associated data. – hnh Sep 04 '14 at 20:53