CalDav Client for iCloud: MKCOL fails with 412 precondition failed

I need help.
I implemented a CalDav Client on our System and it worked like a charm. Now I have some problems with creating new calendars on iCloud. Maybe some of you know how I can fix this.

Currently I get a 412 Error.

Headers:

"Depth: 1"
"Content-Type: application/xml; charset=UTF-8"
"User-Agent: DAVKit/4.0.1 (730); CalendarStore/4.0.1 (973); iCal/4.0.1 (1374); Mac OS X/10.6.2 (10C540)"`

Request:

`MKCOL`

Body:

 <D:mkcol xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"> 
 <D:set>
 <D:prop>
 <D:resourcetype>
 <D:collection/>
 <C:calendar-collection/>
 </D:resourcetype>"
 <D:displayname>some name</D:displayname>
 </D:prop>
 </D:set>
 </D:mkcol>`

URL:

https://caldav.icloud.com/1722222111/calendars/64DA8FE9D95A40E4B83A45B47DEC6C53/

The URL ist my Principle (I changed it of course) and a randomly generated UUID for the calendar resource.

Maybe somebody spots any errors?
Used to work fine 6 months ago.

Thank you very much!

asked Nov 14 '18 at 16:48

Klerafukan

156

It seems to work if I use the URI: https://caldav.icloud.com/1722222111/calendars/ However is only one collection allowed and I want to at least create three calendars. I am not sure how to access or create a new URI for those calendars. As I mentioned, it used to work with generation a UUID and just concatenate the UUID to the calendar URI.

– Klerafukan
Nov 15 '18 at 14:37

add a comment |

I need help.
I implemented a CalDav Client on our System and it worked like a charm. Now I have some problems with creating new calendars on iCloud. Maybe some of you know how I can fix this.

Currently I get a 412 Error.

Headers:

"Depth: 1"
"Content-Type: application/xml; charset=UTF-8"
"User-Agent: DAVKit/4.0.1 (730); CalendarStore/4.0.1 (973); iCal/4.0.1 (1374); Mac OS X/10.6.2 (10C540)"`

Request:

`MKCOL`

Body:

 <D:mkcol xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"> 
 <D:set>
 <D:prop>
 <D:resourcetype>
 <D:collection/>
 <C:calendar-collection/>
 </D:resourcetype>"
 <D:displayname>some name</D:displayname>
 </D:prop>
 </D:set>
 </D:mkcol>`

URL:

https://caldav.icloud.com/1722222111/calendars/64DA8FE9D95A40E4B83A45B47DEC6C53/

The URL ist my Principle (I changed it of course) and a randomly generated UUID for the calendar resource.

Maybe somebody spots any errors?
Used to work fine 6 months ago.

Thank you very much!

asked Nov 14 '18 at 16:48

Klerafukan

156

It seems to work if I use the URI: https://caldav.icloud.com/1722222111/calendars/ However is only one collection allowed and I want to at least create three calendars. I am not sure how to access or create a new URI for those calendars. As I mentioned, it used to work with generation a UUID and just concatenate the UUID to the calendar URI.

– Klerafukan
Nov 15 '18 at 14:37

add a comment |

I need help.
I implemented a CalDav Client on our System and it worked like a charm. Now I have some problems with creating new calendars on iCloud. Maybe some of you know how I can fix this.

Currently I get a 412 Error.

Headers:

"Depth: 1"
"Content-Type: application/xml; charset=UTF-8"
"User-Agent: DAVKit/4.0.1 (730); CalendarStore/4.0.1 (973); iCal/4.0.1 (1374); Mac OS X/10.6.2 (10C540)"`

Request:

`MKCOL`

Body:

 <D:mkcol xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"> 
 <D:set>
 <D:prop>
 <D:resourcetype>
 <D:collection/>
 <C:calendar-collection/>
 </D:resourcetype>"
 <D:displayname>some name</D:displayname>
 </D:prop>
 </D:set>
 </D:mkcol>`

URL:

https://caldav.icloud.com/1722222111/calendars/64DA8FE9D95A40E4B83A45B47DEC6C53/

The URL ist my Principle (I changed it of course) and a randomly generated UUID for the calendar resource.

Maybe somebody spots any errors?
Used to work fine 6 months ago.

Thank you very much!

asked Nov 14 '18 at 16:48

Klerafukan

156

I need help.
I implemented a CalDav Client on our System and it worked like a charm. Now I have some problems with creating new calendars on iCloud. Maybe some of you know how I can fix this.

Currently I get a 412 Error.

Headers:

"Depth: 1"
"Content-Type: application/xml; charset=UTF-8"
"User-Agent: DAVKit/4.0.1 (730); CalendarStore/4.0.1 (973); iCal/4.0.1 (1374); Mac OS X/10.6.2 (10C540)"`

Request:

`MKCOL`

Body:

 <D:mkcol xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"> 
 <D:set>
 <D:prop>
 <D:resourcetype>
 <D:collection/>
 <C:calendar-collection/>
 </D:resourcetype>"
 <D:displayname>some name</D:displayname>
 </D:prop>
 </D:set>
 </D:mkcol>`

URL:

https://caldav.icloud.com/1722222111/calendars/64DA8FE9D95A40E4B83A45B47DEC6C53/

The URL ist my Principle (I changed it of course) and a randomly generated UUID for the calendar resource.

Maybe somebody spots any errors?
Used to work fine 6 months ago.

Thank you very much!

icloud caldav http-status-code-412

asked Nov 14 '18 at 16:48

Klerafukan

156

asked Nov 14 '18 at 16:48

Klerafukan

156

asked Nov 14 '18 at 16:48

Klerafukan

156

asked Nov 14 '18 at 16:48

Klerafukan

156

asked Nov 14 '18 at 16:48

Klerafukan

156

It seems to work if I use the URI: https://caldav.icloud.com/1722222111/calendars/ However is only one collection allowed and I want to at least create three calendars. I am not sure how to access or create a new URI for those calendars. As I mentioned, it used to work with generation a UUID and just concatenate the UUID to the calendar URI.

– Klerafukan
Nov 15 '18 at 14:37

add a comment |

It seems to work if I use the URI: https://caldav.icloud.com/1722222111/calendars/ However is only one collection allowed and I want to at least create three calendars. I am not sure how to access or create a new URI for those calendars. As I mentioned, it used to work with generation a UUID and just concatenate the UUID to the calendar URI.

– Klerafukan
Nov 15 '18 at 14:37

It seems to work if I use the URI: https://caldav.icloud.com/1722222111/calendars/ However is only one collection allowed and I want to at least create three calendars. I am not sure how to access or create a new URI for those calendars. As I mentioned, it used to work with generation a UUID and just concatenate the UUID to the calendar URI.

– Klerafukan
Nov 15 '18 at 14:37

add a comment |

2 Answers
2

active

oldest

votes

While there seems to be a mapping bug on the caldav.icloud.com endpoint (filed that as Radar 46258347 if you want to refer), you are not supposed to hit a /calendars URL on this endpoint in the first place.

You only use caldav.icloud.com to discover the principal resource (representing the user/account). This contains the actual partition hosting the caldav server for your account, it looks like:

https://pXX-caldav.icloud.com/asdfjasdjkjfd/calendars/

Those endpoint still seem to work just fine (just tried).

So how do you get from caldav.icloud.com to the actual CalDAV server? You need to retrieve the calendar-home-set property of the principal.

The whole process is described in the CalDAV RFC or in this nice guide:
http://sabre.io/dav/building-a-caldav-client/#discovery.

answered Nov 26 '18 at 23:17

hnh

6,62541431

Good point. I will do that. So far I can't seem to do the PROPFIND request on the caldav.icloud.com/principle. It always returns a 404 "not foud". But I will figure it out.

– Klerafukan
Nov 30 '18 at 9:17

Ok just a last statement to finish this: I implemented the discovery approach and a workaround for the bug. Everything works fine! I thank you guys a lot!!! Til

– Klerafukan
Dec 5 '18 at 8:23

Would you mind marking this answer as the one then? The accepted one may work, but it is a non-conforming hack that will break as soon as they fix it ...

– hnh
Dec 5 '18 at 9:35

I marked the second answer. Because I agree that this is best practice. However my problem solves solution 1. I hope Apple will fix this bug soon and I can remove my workaround.

– Klerafukan
Dec 6 '18 at 10:18

If the hack is required, it sounds that we don't have a proper answer yet. When I do a MKCALENDAR in Calendar.app and look in the Charles trace, it makes a proper request and succeeds. Now that could be due to user-agent sniffing, not sure. 🤔

– hnh
Dec 6 '18 at 12:48

add a comment |

If you use https://pXX-caldav.icloud.com/123456789/new-calendar-name-or-href/ for making MKCOL request, then you will get 201 CREATED status and the href of your new collection will be pXX-caldav.icloud.com/123456789/calendars/new-calendar-name-or-href/

so remove calendars/ from your path to create

edited Nov 28 '18 at 9:40

answered Nov 18 '18 at 10:11

sarigalin

2,69711513

I could kiss you right now!! Thank you so much. Is there any way that is documented somewhere?

– Klerafukan
Nov 19 '18 at 15:32

Unfortunately, the most problem with iCloud is lack of documentation. I found the answer by some try and error.

– sarigalin
Nov 20 '18 at 10:01

That would be a straight bug though and should be Radar'ed: radar.apple.com

– hnh
Nov 26 '18 at 22:50

"Unfortunately, the most problem with iCloud is lack of documentation" - the CalDAV protocol is a proper standard w/ a complete RFC and plenty of documentation! 😀

– hnh
Nov 26 '18 at 23:24

Thanks for your comment, actually the url I provided in my comment was wrong and I corrected it. as I said, I have to send MKCOL request to pXX-caldav.icloud.com/123456789/new-calendar-name-or-href to create a new calendar at pXX-caldav.icloud.com/123456789/calendars/….

– sarigalin
Nov 28 '18 at 9:42

add a comment |

Your Answer

StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);

);

draft saved

draft discarded

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53305100%2fcaldav-client-for-icloud-mkcol-fails-with-412-precondition-failed%23new-answer', 'question_page');

);

Post as a guest

Name

Required, but never shown

2 Answers
2

active

oldest

votes

2 Answers
2

active

oldest

votes

You only use caldav.icloud.com to discover the principal resource (representing the user/account). This contains the actual partition hosting the caldav server for your account, it looks like:

https://pXX-caldav.icloud.com/asdfjasdjkjfd/calendars/

Those endpoint still seem to work just fine (just tried).

So how do you get from caldav.icloud.com to the actual CalDAV server? You need to retrieve the calendar-home-set property of the principal.

The whole process is described in the CalDAV RFC or in this nice guide:
http://sabre.io/dav/building-a-caldav-client/#discovery.

answered Nov 26 '18 at 23:17

hnh

6,62541431

Good point. I will do that. So far I can't seem to do the PROPFIND request on the caldav.icloud.com/principle. It always returns a 404 "not foud". But I will figure it out.

– Klerafukan
Nov 30 '18 at 9:17

Ok just a last statement to finish this: I implemented the discovery approach and a workaround for the bug. Everything works fine! I thank you guys a lot!!! Til

– Klerafukan
Dec 5 '18 at 8:23

Would you mind marking this answer as the one then? The accepted one may work, but it is a non-conforming hack that will break as soon as they fix it ...

– hnh
Dec 5 '18 at 9:35

I marked the second answer. Because I agree that this is best practice. However my problem solves solution 1. I hope Apple will fix this bug soon and I can remove my workaround.

– Klerafukan
Dec 6 '18 at 10:18

If the hack is required, it sounds that we don't have a proper answer yet. When I do a MKCALENDAR in Calendar.app and look in the Charles trace, it makes a proper request and succeeds. Now that could be due to user-agent sniffing, not sure. 🤔

– hnh
Dec 6 '18 at 12:48

add a comment |

You only use caldav.icloud.com to discover the principal resource (representing the user/account). This contains the actual partition hosting the caldav server for your account, it looks like:

https://pXX-caldav.icloud.com/asdfjasdjkjfd/calendars/

Those endpoint still seem to work just fine (just tried).

So how do you get from caldav.icloud.com to the actual CalDAV server? You need to retrieve the calendar-home-set property of the principal.

The whole process is described in the CalDAV RFC or in this nice guide:
http://sabre.io/dav/building-a-caldav-client/#discovery.

answered Nov 26 '18 at 23:17

hnh

6,62541431

Good point. I will do that. So far I can't seem to do the PROPFIND request on the caldav.icloud.com/principle. It always returns a 404 "not foud". But I will figure it out.

– Klerafukan
Nov 30 '18 at 9:17

Ok just a last statement to finish this: I implemented the discovery approach and a workaround for the bug. Everything works fine! I thank you guys a lot!!! Til

– Klerafukan
Dec 5 '18 at 8:23

Would you mind marking this answer as the one then? The accepted one may work, but it is a non-conforming hack that will break as soon as they fix it ...

– hnh
Dec 5 '18 at 9:35

I marked the second answer. Because I agree that this is best practice. However my problem solves solution 1. I hope Apple will fix this bug soon and I can remove my workaround.

– Klerafukan
Dec 6 '18 at 10:18

If the hack is required, it sounds that we don't have a proper answer yet. When I do a MKCALENDAR in Calendar.app and look in the Charles trace, it makes a proper request and succeeds. Now that could be due to user-agent sniffing, not sure. 🤔

– hnh
Dec 6 '18 at 12:48

add a comment |

You only use caldav.icloud.com to discover the principal resource (representing the user/account). This contains the actual partition hosting the caldav server for your account, it looks like:

https://pXX-caldav.icloud.com/asdfjasdjkjfd/calendars/

Those endpoint still seem to work just fine (just tried).

So how do you get from caldav.icloud.com to the actual CalDAV server? You need to retrieve the calendar-home-set property of the principal.

The whole process is described in the CalDAV RFC or in this nice guide:
http://sabre.io/dav/building-a-caldav-client/#discovery.

answered Nov 26 '18 at 23:17

hnh

6,62541431

You only use caldav.icloud.com to discover the principal resource (representing the user/account). This contains the actual partition hosting the caldav server for your account, it looks like:

https://pXX-caldav.icloud.com/asdfjasdjkjfd/calendars/

Those endpoint still seem to work just fine (just tried).

So how do you get from caldav.icloud.com to the actual CalDAV server? You need to retrieve the calendar-home-set property of the principal.

The whole process is described in the CalDAV RFC or in this nice guide:
http://sabre.io/dav/building-a-caldav-client/#discovery.

answered Nov 26 '18 at 23:17

hnh

6,62541431

answered Nov 26 '18 at 23:17

hnh

6,62541431

answered Nov 26 '18 at 23:17

hnh

6,62541431

answered Nov 26 '18 at 23:17

hnh

6,62541431

Good point. I will do that. So far I can't seem to do the PROPFIND request on the caldav.icloud.com/principle. It always returns a 404 "not foud". But I will figure it out.

– Klerafukan
Nov 30 '18 at 9:17

Ok just a last statement to finish this: I implemented the discovery approach and a workaround for the bug. Everything works fine! I thank you guys a lot!!! Til

– Klerafukan
Dec 5 '18 at 8:23

Would you mind marking this answer as the one then? The accepted one may work, but it is a non-conforming hack that will break as soon as they fix it ...

– hnh
Dec 5 '18 at 9:35

I marked the second answer. Because I agree that this is best practice. However my problem solves solution 1. I hope Apple will fix this bug soon and I can remove my workaround.

– Klerafukan
Dec 6 '18 at 10:18

If the hack is required, it sounds that we don't have a proper answer yet. When I do a MKCALENDAR in Calendar.app and look in the Charles trace, it makes a proper request and succeeds. Now that could be due to user-agent sniffing, not sure. 🤔

– hnh
Dec 6 '18 at 12:48

add a comment |

Good point. I will do that. So far I can't seem to do the PROPFIND request on the caldav.icloud.com/principle. It always returns a 404 "not foud". But I will figure it out.

– Klerafukan
Nov 30 '18 at 9:17

Ok just a last statement to finish this: I implemented the discovery approach and a workaround for the bug. Everything works fine! I thank you guys a lot!!! Til

– Klerafukan
Dec 5 '18 at 8:23

Would you mind marking this answer as the one then? The accepted one may work, but it is a non-conforming hack that will break as soon as they fix it ...

– hnh
Dec 5 '18 at 9:35

I marked the second answer. Because I agree that this is best practice. However my problem solves solution 1. I hope Apple will fix this bug soon and I can remove my workaround.

– Klerafukan
Dec 6 '18 at 10:18

If the hack is required, it sounds that we don't have a proper answer yet. When I do a MKCALENDAR in Calendar.app and look in the Charles trace, it makes a proper request and succeeds. Now that could be due to user-agent sniffing, not sure. 🤔

– hnh
Dec 6 '18 at 12:48

Good point. I will do that. So far I can't seem to do the PROPFIND request on the caldav.icloud.com/principle. It always returns a 404 "not foud". But I will figure it out.

– Klerafukan
Nov 30 '18 at 9:17

Ok just a last statement to finish this: I implemented the discovery approach and a workaround for the bug. Everything works fine! I thank you guys a lot!!! Til

– Klerafukan
Dec 5 '18 at 8:23

Would you mind marking this answer as the one then? The accepted one may work, but it is a non-conforming hack that will break as soon as they fix it ...

– hnh
Dec 5 '18 at 9:35

I marked the second answer. Because I agree that this is best practice. However my problem solves solution 1. I hope Apple will fix this bug soon and I can remove my workaround.

– Klerafukan
Dec 6 '18 at 10:18

If the hack is required, it sounds that we don't have a proper answer yet. When I do a MKCALENDAR in Calendar.app and look in the Charles trace, it makes a proper request and succeeds. Now that could be due to user-agent sniffing, not sure. 🤔

– hnh
Dec 6 '18 at 12:48

add a comment |

so remove calendars/ from your path to create

edited Nov 28 '18 at 9:40

answered Nov 18 '18 at 10:11

sarigalin

2,69711513

I could kiss you right now!! Thank you so much. Is there any way that is documented somewhere?

– Klerafukan
Nov 19 '18 at 15:32

Unfortunately, the most problem with iCloud is lack of documentation. I found the answer by some try and error.

– sarigalin
Nov 20 '18 at 10:01

That would be a straight bug though and should be Radar'ed: radar.apple.com

– hnh
Nov 26 '18 at 22:50

"Unfortunately, the most problem with iCloud is lack of documentation" - the CalDAV protocol is a proper standard w/ a complete RFC and plenty of documentation! 😀

– hnh
Nov 26 '18 at 23:24

Thanks for your comment, actually the url I provided in my comment was wrong and I corrected it. as I said, I have to send MKCOL request to pXX-caldav.icloud.com/123456789/new-calendar-name-or-href to create a new calendar at pXX-caldav.icloud.com/123456789/calendars/….

– sarigalin
Nov 28 '18 at 9:42

add a comment |

so remove calendars/ from your path to create

edited Nov 28 '18 at 9:40

answered Nov 18 '18 at 10:11

sarigalin

2,69711513

I could kiss you right now!! Thank you so much. Is there any way that is documented somewhere?

– Klerafukan
Nov 19 '18 at 15:32

Unfortunately, the most problem with iCloud is lack of documentation. I found the answer by some try and error.

– sarigalin
Nov 20 '18 at 10:01

That would be a straight bug though and should be Radar'ed: radar.apple.com

– hnh
Nov 26 '18 at 22:50

"Unfortunately, the most problem with iCloud is lack of documentation" - the CalDAV protocol is a proper standard w/ a complete RFC and plenty of documentation! 😀

– hnh
Nov 26 '18 at 23:24

Thanks for your comment, actually the url I provided in my comment was wrong and I corrected it. as I said, I have to send MKCOL request to pXX-caldav.icloud.com/123456789/new-calendar-name-or-href to create a new calendar at pXX-caldav.icloud.com/123456789/calendars/….

– sarigalin
Nov 28 '18 at 9:42

add a comment |

so remove calendars/ from your path to create

edited Nov 28 '18 at 9:40

answered Nov 18 '18 at 10:11

sarigalin

2,69711513

so remove calendars/ from your path to create

edited Nov 28 '18 at 9:40

answered Nov 18 '18 at 10:11

sarigalin

2,69711513

edited Nov 28 '18 at 9:40

answered Nov 18 '18 at 10:11

sarigalin

2,69711513

answered Nov 18 '18 at 10:11

sarigalin

2,69711513

answered Nov 18 '18 at 10:11

sarigalin

2,69711513

I could kiss you right now!! Thank you so much. Is there any way that is documented somewhere?

– Klerafukan
Nov 19 '18 at 15:32

Unfortunately, the most problem with iCloud is lack of documentation. I found the answer by some try and error.

– sarigalin
Nov 20 '18 at 10:01

That would be a straight bug though and should be Radar'ed: radar.apple.com

– hnh
Nov 26 '18 at 22:50

"Unfortunately, the most problem with iCloud is lack of documentation" - the CalDAV protocol is a proper standard w/ a complete RFC and plenty of documentation! 😀

– hnh
Nov 26 '18 at 23:24

Thanks for your comment, actually the url I provided in my comment was wrong and I corrected it. as I said, I have to send MKCOL request to pXX-caldav.icloud.com/123456789/new-calendar-name-or-href to create a new calendar at pXX-caldav.icloud.com/123456789/calendars/….

– sarigalin
Nov 28 '18 at 9:42

add a comment |

I could kiss you right now!! Thank you so much. Is there any way that is documented somewhere?

– Klerafukan
Nov 19 '18 at 15:32

Unfortunately, the most problem with iCloud is lack of documentation. I found the answer by some try and error.

– sarigalin
Nov 20 '18 at 10:01

That would be a straight bug though and should be Radar'ed: radar.apple.com

– hnh
Nov 26 '18 at 22:50

"Unfortunately, the most problem with iCloud is lack of documentation" - the CalDAV protocol is a proper standard w/ a complete RFC and plenty of documentation! 😀

– hnh
Nov 26 '18 at 23:24

Thanks for your comment, actually the url I provided in my comment was wrong and I corrected it. as I said, I have to send MKCOL request to pXX-caldav.icloud.com/123456789/new-calendar-name-or-href to create a new calendar at pXX-caldav.icloud.com/123456789/calendars/….

– sarigalin
Nov 28 '18 at 9:42

I could kiss you right now!! Thank you so much. Is there any way that is documented somewhere?

– Klerafukan
Nov 19 '18 at 15:32

Unfortunately, the most problem with iCloud is lack of documentation. I found the answer by some try and error.

– sarigalin
Nov 20 '18 at 10:01

That would be a straight bug though and should be Radar'ed: radar.apple.com

– hnh
Nov 26 '18 at 22:50

"Unfortunately, the most problem with iCloud is lack of documentation" - the CalDAV protocol is a proper standard w/ a complete RFC and plenty of documentation! 😀

– hnh
Nov 26 '18 at 23:24

Thanks for your comment, actually the url I provided in my comment was wrong and I corrected it. as I said, I have to send MKCOL request to pXX-caldav.icloud.com/123456789/new-calendar-name-or-href to create a new calendar at pXX-caldav.icloud.com/123456789/calendars/….

– sarigalin
Nov 28 '18 at 9:42

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Pfthb