[Akonadi] [Bug 326846] New: DAV resource requests ALL calendar data without a [comp-filter] set

[Ingo Ratsdorf]

https://bugs.kde.org/show_bug.cgi?id=326846

            Bug ID: 326846
           Summary: DAV resource requests ALL calendar data without a
                    [comp-filter] set
    Classification: Unclassified
           Product: Akonadi
           Version: 4.11
          Platform: Ubuntu Packages
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: DAV Resource
          Assignee: kdepim-bugs at kde.org
          Reporter: ingo at envirology.co.nz

You set up a CalDAV resource and wait and wait and wait, .....
The calendar server log files show that the DAV resource is requesting ALL
calendar data without a [comp-filter][time-range] set.
This is going to request ALL available VEvent data for all the acessible
calendars, in my case 5 shared calendars with 6 years of data, some 20,000
events....
The server will be working for hours.

Reproducible: Always

Steps to Reproduce:
1. set up a CalDAV resource
2. wait
3. watch server logs
Actual Results:  
Server chokes up, apache2 processes have to be killed, resource deleted again

Expected Results:  
A subset of events from each calendar to be requested, ie last 3 months and
fiture events, like other calendar clients do. iPhone works fine with server,
Thunderbird/Lighning works fine, EMClient works fine, even iCal.
Just not KDE DAV.

The dav request the KDE DAV resource is sending to the server:

<?xml version="1.0" encoding="utf-8"?>
<calendar-query xmlns="urn:ietf:params:xml:ns:caldav">
 <prop xmlns="DAV:">
  <getetag xmlns="DAV:"/>
  <resourcetype xmlns="DAV:"/>
 </prop>
 <filter xmlns="urn:ietf:params:xml:ns:caldav">
  <comp-filter xmlns="urn:ietf:params:xml:ns:caldav" name="VCALENDAR">
   <comp-filter xmlns="urn:ietf:params:xml:ns:caldav" name="VEVENT"/>
  </comp-filter>
 </filter>
</calendar-query>

While I realise that some server may not support [time-range], I also wonder
whether it is wise to request all data and rely on the server to make some
educated guess on whether that would be good or not...
Of course the server could be changed to only return sensible amount of data,
too...

-- 
You are receiving this mail because:
You are the assignee for the bug.