comp-filter delivers too many results

[brunt82]

It seems that the comp-filter delivers too many results in special case. Following my test environment:

1. I upload the following three ics-files:

1.ics

CALSCALE:GREGORIAN
PRODID:-//Example Inc.//Example Calendar//EN
VERSION:2.0
BEGIN:VTIMEZONE
LAST-MODIFIED:20040110T032845Z
TZID:US/Eastern
BEGIN:DAYLIGHT
DTSTART:20000404T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20001026T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20051222T205953Z
CREATED:20060101T150000Z
DTSTART;TZID=US/Eastern:20170101T100000
DURATION:PT1H
SUMMARY:event 1
UID:54E181BC7CCC373042B28842@ninevah.local
CATEGORIES:cool
END:VEVENT
END:VCALENDAR

2.ics

CALSCALE:GREGORIAN
PRODID:-//Example Inc.//Example Calendar//EN
VERSION:2.0
BEGIN:VTIMEZONE
LAST-MODIFIED:20040110T032845Z
TZID:US/Eastern
BEGIN:DAYLIGHT
DTSTART:20000404T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20001026T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20051222T210507Z
CREATED:20060102T190000Z
DTSTART;TZID=US/Eastern:20170102T140000
DURATION:PT1H
RRULE:FREQ=DAILY;COUNT=5
SUMMARY:event 6
UID:F5B811E00073B22BA6B87551@ninevah.local
CATEGORIES:warm,hot
CATEGORIES:cool
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20051222T210507Z
UID:F5B811E00073B22BA6B87551@ninevah.local
RECURRENCE-ID;TZID=US/Eastern:20170104T140000
CREATED:20060102T190000Z
DTSTART;TZID=US/Eastern:20170104T160000
DURATION:PT1H
SUMMARY:event 6 changed
DESCRIPTION:Some notes
BEGIN:VALARM
ACTION:AUDIO
TRIGGER;RELATED=START:-PT10M
END:VALARM
END:VEVENT
END:VCALENDAR

3.ics

CALSCALE:GREGORIAN
PRODID:-//Example Inc.//Example Calendar//EN
VERSION:2.0
BEGIN:VTIMEZONE
LAST-MODIFIED:20040110T032845Z
TZID:US/Eastern
BEGIN:DAYLIGHT
DTSTART:20000404T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20001026T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20051222T210507Z
CREATED:20060102T230000Z
DTSTART;TZID=US/Eastern:20170102T180000
DURATION:PT1H
RRULE:FREQ=DAILY;COUNT=5
SUMMARY:event 7
UID:F5B811E00073B22BA6B87562@ninevah.local
CATEGORIES:warm
CATEGORIES:hot
BEGIN:VALARM
ACTION:AUDIO
TRIGGER;RELATED=START:-PT10M
END:VALARM
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20051222T210507Z
UID:F5B811E00073B22BA6B87562@ninevah.local
RECURRENCE-ID;RANGE=THISANDFUTURE;TZID=US/Eastern:20170104T180000
CREATED:20060102T230000Z
DTSTART;TZID=US/Eastern:20170104T200000
DURATION:PT1H
SUMMARY:event 7 changed
DESCRIPTION:Some notes
END:VEVENT
END:VCALENDAR

Afterwards I send the following request to filter the ics:

REPORT http://baikal0603.example.com:8080/calendars/groupware-test1@example.com/compfilter/
Depth: 1
Accept-Encoding: identity
Content-Type: text/xml; charset=utf-8
Username: admin
<?xml version="1.0" encoding="utf-8" ?>
<C:calendar-query xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:prop>
<D:getetag/>
</D:prop>
<C:filter>
<C:comp-filter name="VCALENDAR">
<C:comp-filter name="VEVENT">
<C:comp-filter name="VALARM">
<C:is-not-defined/>
</C:comp-filter>
</C:comp-filter>
</C:comp-filter>
</C:filter>
</C:calendar-query>

And get the following response:

207 Multi-Status
Connection:  Keep-Alive
Content-Length:  948
Content-Type:  application/xml; charset=utf-8
Date:  Wed, 13 Sep 2017 09:51:21 GMT
Keep-Alive:  timeout=5, max=100
Server:  Apache/2.4.10 (Debian)
Vary:  Brief,Prefer
X-NoScript-ReqData:  {}
X-Sabre-Version:  3.2.2

<?xml version="1.0"?>
<d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:cal="urn:ietf:params:xml:ns:caldav" xmlns:cs="http://calendarserver.org/ns/" xmlns:card="urn:ietf:params:xml:ns:carddav">
	<d:response>
		<d:href>/calendars/groupware-test1@example.com/compfilter/1.ics</d:href>
		<d:propstat>
			<d:prop>
				<d:getetag>&quot;76344143f0ee42783c894e5f464b41a4&quot;</d:getetag>
			</d:prop>
			<d:status>HTTP/1.1 200 OK</d:status>
		</d:propstat>
	</d:response>
	<d:response>
		<d:href>/calendars/groupware-test1@example.com/compfilter/2.ics</d:href>
		<d:propstat>
			<d:prop>
				<d:getetag>&quot;60812e72d5ecdaaddcbd81e311c7a7cc&quot;</d:getetag>
			</d:prop>
			<d:status>HTTP/1.1 200 OK</d:status>
		</d:propstat>
	</d:response>
	<d:response>
		<d:href>/calendars/groupware-test1@example.com/compfilter/3.ics</d:href>
		<d:propstat>
			<d:prop>
				<d:getetag>&quot;1d3c1bfe5ae0ec3517e3f660d78a21d4&quot;</d:getetag>
			</d:prop>
			<d:status>HTTP/1.1 200 OK</d:status>
		</d:propstat>
	</d:response>
</d:multistatus>

But I expected only "1.ics" because of the VALARMS within the events. When I change the filter request and remove the "<C:is-not-defined/>"-tag, the response only contains 2.ics and 3.ics (1.ics is not responded because of the missing VALARM).

Can somebody explain this behavior?

[staabm]

Sorry for the very late reply.

Is this still an issue on the latest version?

[brunt82]

What do you mean? There was no new version of sabreDAV since September, doesn't? So I assume, that the issue still exists. I used sabreDAV 3.2 at that time.

[alecpl]

My test in #1608 shows the issue is already fixed.