For reference and transparency: We have created this report on Apple Bug Reporter on 12 Oct 2018 here:


When iCloud send 412 Precondition failed on an invalid sync-token, it uses “text/plain” instead of “application/xml” MIME type for the XML error description.

Steps to reproduce:

  1. Send an HTTP REPORT sync-collection [] request with an invalid (outdated, etc.) sync-token to iCloud:
<?xml version='1.0' encoding='UTF-8' ?><sync-collection xmlns="DAV:"><sync-token>this-is-invalid</sync-token><sync-level>1</sync-level><prop><getetag /></prop></sync-collection>

Actual result:

Server responds with 412 Precondition Failed and valid-sync-token XML precondition element []

<-- 412 Precondition Failed
Server: AppleHttpServer/2f080fc0
Date: Fri, 12 Oct 2018 10:17:59 GMT
Content-Type: text/plain; charset=UTF-8
Connection: keep-alive
X-Apple-Jingle-Correlation-Key: xxxxxxxxxxxxx
apple-seq: 0
apple-tk: false
Apple-Originating-System: UnknownOriginatingSystem
X-Responding-Instance: carddav:15900201:st42p59ic-tyfb13213201:8001:1819B41:51222b91b
Strict-Transport-Security: max-age=31536000; includeSubDomains;
via: icloudedge:br30p01ic-zteu03012201:7401:18RC550:Berlin
X-Apple-Request-UUID: xxxxxxxxxxxxxxxx
access-control-expose-headers: X-Apple-Request-UUID
access-control-expose-headers: Via

<?xml version='1.0' encoding='UTF-8'?>
<error xmlns='DAV:'>

As you can see, the Content-Type is “text/plain; charset=UTF-8”, although it should be application/xml or text/xml [].

This causes clients like our software DAVdroid to

  1. not parse the response as XML, so
  2. that valid-sync-token is not recognized as the reason why the request has failed, so
  3. DAVdroid does NOT retry without sync token, but aborts with an error message.
  4. So the sync has failed with an error message.

Expected result:

Same response, but with Content-Type: application/xml [].