我正在将本地客户端与DAV文件夹同步（在这种特殊情况下为CardDAV）。
对于这个文件夹，我有ETag（SabreDAV方言中的CTag，以区分文件夹etags和项etags）。如果CTag发生了变化，我需要再次重新同步。但如果这个改变是由我自己引起的（例如我刚刚将一个联系人上传到这个CardDAV文件夹中），有没有办法避免重新同步？
理想情况下，我希望DAV服务器会在每个更改服务器上任何内容的请求上返回此信息：
这将让我了解CTag更改是否仅由我自己的操作引起（并且不需要重新同步）或其间发生了其他事情（因此需要重新同步）。
目前，我只能在任何时候查询文件夹中的CTag，但我不知道如果CTag改变了怎么办（伪代码）：
cTag0 = ReadStoredValue() ' The value left from the previous sync.
cTag1 = GetCTag()
If cTag0 <> cTag1 Then
Resync()
End If
UploadItem() ' Can get race condition if another client changes anything right now
cTag2 = GetCTag()
cTag2显然与cTag1不同，但这提供了关于中间是否发生了其他事情的零信息（另一个客户端在同一文件夹中更改了某些内容）。所以，cTag0 <> cTag1比较不会让我免于竞争条件，我可以认为我是同步的，而其他一些更新却没有引起注意。
很高兴有：
cTag0 = ReadStoredValue() ' The value left from the previous sync.
(cTag1, cTag2) = UploadItem()
If cTag0 == cTag1
' No resync needed, just remember new CTag for the next sync cycle.
cTag0 = cTag2
Else
Resync()
cTag0 = cTag2
End If
我知道DAV-Sync协议扩展，但这将是一个不同的故事。在这个任务中，我指的是标准的DAV，不允许扩展。
编辑：我想到的一个想法。我注意到CTag是连续的。这是一个数字，在每次操作文件夹时都会增加1。因此，如果在获得CTag之间增加超过1，进行我的操作然后再次获得CTag，这将表明其他事情刚刚发生。但这似乎并不可靠，我担心它依赖于这种行为的实现特定。寻找更强大的解决方案。
这与How to avoid time conflict or overlap for CalDAV? 非常相似
从技术上讲，在纯粹的DAV中，您无法保证能够做到这一点。虽然在现实世界中，大多数服务器会在响应PUT时返回ETag，用于创建/更新资源。这允许您将并发更改协调到同一资源。
还有一些服务器支持的Calendar Server Bulk Change Requests for *DAV Protocols，它提供了一种更具体的方法来实现这一点。由于它不是RFC，我不建议依赖它。
所以你可能会做的就是PUT。如果它返回ETag，你很好并且可以通过同步集合来协调（通过任何机制，PROPFIND：1，CTag或sync-report）。如果没有，您可以选择通过其他方式进行协调（例如，比较/散列内容），或者只是将更改视为并发编辑，我认为大多数实现都会这样做。
如果你很幸运，服务器也可以在PUT中返回CTag / sync-token。但AFAIK没有标准，服务器不需要这样做。
这是对你的误解。一个CTag绝对不像ETag一样，它在这里记录了自己的东西：CalDAV CTag。
CTag根本不是DAV标准，它是private Apple extension（没有RFC）。
标准HTTP / 1.1规范了ETag。它对应于资源表示，不适用于与此不同的WebDAV集合内容。 WebDAV集合通常也有内容（可以通过GET等检索），ETag对应于此。
取代专有CTag扩展的官方标准实际上是DAV-Sync又名RFC 6578.而sync-token属性和标题是取代CTag标题的内容。
因此，如果“不允许扩展”是您的用例，则需要在客户端进行资源比较。纯WebDAV不提供此功能。
CTag不是顺序的，它们是不透明的令牌。特定服务器可以使用序列，但这完全是任意的。 （所有DAV令牌都是如此，它们总是不透明的）