[sync] Efficient handling of denied CalDAV-Requests

[Jens Wahnes]

Jan Schneider wrote:

> Zitat von Jens Wahnes <wahnes at uni-koeln.de>:
>> in our setup, we have a number of users that use CalDAV to access both
>> their own calendars and calendars that other users have shared with
>> them. Of the shared calendars, of course not all allow write access.
>>
>> When a CalDAV client tries to write to such a calendar for which it
>> does not have permissions, then of course access to it is denied and
>> the calendar remains unchanged.  However, there seem to be many
>> clients out there that repeat this kind of "unsuccessful" request over
>> and over again.  That is, these clients to not get the fact that they
>> will never be able to write to the calendar and over time they send a
>> huge amount of requests that have to be denied each and every time.

> Maybe you could talk to the developers of the affected clients and ask
> them to support the current-user-privilege-set property that we
> propagate correctly according to the user's permissions on a share.

Thanks for the idea.  I'm afraid that this will be rather tough because 
it's mostly (or even exclusively, I'd have to check) closed-source 
applications that show this behaviour and I don't think their developers 
care much about the annoyance their software causes for some unrelated 
server operator.

The most prominent example (i.e. the application that most such requests 
originate from) is Apple's OS X Calendaring tool which is probably meant 
to work with Apple's own calendar servers anyway.  Second place is 
Blackberry's (RIM) OS 10 CalDAV client, which is most likely not being 
developed at all any more, given the future of their Blackberry 10 OS.

Well, I still can hope for relief with the forthcoming release of 
Kronolith that incorporates a newer version von SabreDAV. :)


Jens


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4986 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.horde.org/archives/sync/attachments/20160405/8c97e71f/attachment.bin>