Also ref #143 ...
The save method have parameter that should prevent one from overwriting existing calendar items or creating new calendar items, but it seems not to be robust enough ...
- caldav objects have a path name which may or may not correspond to the UID. A UID check is not sufficient to prevent overwriting exisitng calendar items (and possibly on some calendar servers it may be possible to create two calendar items with the same UID but different path names).
- There is also a potential race condition as we first check and then PUT the new item.
(This would have been trivial if the caldav standard would have imposed some restrictions on the UID, asserted that the pathname and the UID should match, and used POST for new items and PUT for updating existing items ... did I ever mention that the caldav standard sucks, and the only reason for getting involved in this library was that I wanted to interface with it through some abstracted library rather than having to deal with the standard myself)?
Also ref #143 ...
The
savemethod have parameter that should prevent one from overwriting existing calendar items or creating new calendar items, but it seems not to be robust enough ...(This would have been trivial if the caldav standard would have imposed some restrictions on the UID, asserted that the pathname and the UID should match, and used POST for new items and PUT for updating existing items ... did I ever mention that the caldav standard sucks, and the only reason for getting involved in this library was that I wanted to interface with it through some abstracted library rather than having to deal with the standard myself)?