CalDav Client for iCloud: MKCOL fails with 412 precondition failed












2















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







share|improve this question























  • 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


















2















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







share|improve this question























  • 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
















2












2








2








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







share|improve this question














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




icloud caldav http-status-code-412






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 14 '18 at 16:48









KlerafukanKlerafukan

156




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





















  • 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







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














2 Answers
2






active

oldest

votes


















2














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.






share|improve this answer
























  • 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



















1














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






share|improve this answer


























  • 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











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















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









2














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.






share|improve this answer
























  • 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
















2














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.






share|improve this answer
























  • 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














2












2








2







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.






share|improve this answer













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.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 26 '18 at 23:17









hnhhnh

6,56541431




6,56541431













  • 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

















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





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





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





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





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





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













1














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






share|improve this answer


























  • 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
















1














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






share|improve this answer


























  • 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














1












1








1







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






share|improve this answer















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







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 28 '18 at 9:40

























answered Nov 18 '18 at 10:11









sarigalinsarigalin

2,61711513




2,61711513













  • 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

















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







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





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





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





"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





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


















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














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















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







-

Popular posts from this blog

Bressuire

Image
Subprefecture and commune in Nouvelle-Aquitaine, France Bressuire Subprefecture and commune Chateau de Bressuire and the Eglise Notre-Dame Coat of arms Location of Bressuire Bressuire Show map of France Bressuire Show map of Nouvelle-Aquitaine Coordinates: 46°50′27″N 0°29′14″W  /  46.8408°N 0.4872°W  / 46.8408; -0.4872 Coordinates: 46°50′27″N 0°29′14″W  /  46.8408°N 0.4872°W  / 46.8408; -0.4872 Country France Region Nouvelle-Aquitaine Department Deux-Sèvres Arrondissement Bressuire Canton Bressuire Government  • Mayor .mw-parser-output .nobold{font-weight:normal} (2014–20) Jean Michel Bernier Area 1 180.59 km 2 (69.73 sq mi) Population (2014) 2 19,300  • Density 110/km 2 (280/sq mi) Time zone UTC+01:00 (CET)  • Summer (DST) UTC+02:00 (CEST) INSEE/Postal code 79049 /79300 Elevation 98–236 m (322–774 ft) (avg. 173 m or 568 ft) 1 French Land Register data, which exclude
Read more

Vorschmack

Image
Vorschmack Ukrainian Jewish-style vorschmack served on rye bread Course Hors d'oeuvre Region or state Eastern Europe Associated national cuisine Ashkenazi Jewish, Finnish, German, Ukrainian, Polish, Russian Main ingredients Ground meat and/or fish Cookbook: Vorschmack   Media: Vorschmack Vorschmack or forshmak (Yiddish: פֿאָרשמאַק ‎, from archaic German Vorschmack , "foretaste" [1] or "appetizer" [2] ) is an originally East European dish made of salty minced fish or meat. Different variants of this dish are especially common in Ashkenazi Jewish and Finnish cuisine. Some varieties are also known in Russian and Polish cuisine. Contents 1 In Jewish cuisine 2 In Russian cuisine 3 In Polish cuisine 4 In Finnish cuisine 5 See also 6 References In Jewish cuisine According to Gil Marks, the German name points to the possible Germanic origin of this dish. [1] William Pokhlyobkin descr
Read more

Quarantine

Image
For other uses, see Quarantine (disambiguation). Signal flag "Lima" called the "Yellow Jack" which when flown in harbor means ship is under quarantine. A simple yellow flag (also called the "Yellow Jack") had historically been used to signal quarantine (it stands for Q among signal flags), but now indicates the opposite, as a signal of a ship free of disease that requests boarding and inspection. A quarantine is used to separate and restrict the movement of people; it is 'a restraint upon the activities or communication of persons or the transport of goods designed to prevent the spread of disease or pests', for a certain period of time. [1] This is often used in connection to disease and illness, such as those who may possibly have been exposed to a communicable disease. [2] The term is often erroneously used to mean medical isolation, which is "to separate ill persons who have a communicable disease from those who are healthy
Read more