ETag with Android about caldav-adapter

[aharter]

I took the adapter on a test drive using davx5 on Android as a client.
To me, it seems like it requests an E-Tag using <getetag/> during a propfind request, which is not fulfilled by the response.
This is the output:

[...]
2020-12-15 20:59:19:829 verbose [server]: 	PROPFIND /caldav/cal/[email protected]/exampleCal1/ 207 - - 26.303 ms
2020-12-15 20:59:19:923 verbose [server]: 	user: user@ex, pass: pass
2020-12-15 20:59:19:924 verbose [index]: 	REQUEST BODY: 
<?xml version="1.0" encoding="UTF-8"?>
<CAL:calendar-query xmlns="DAV:" xmlns:CAL="urn:ietf:params:xml:ns:caldav">
  <prop>
    <getetag/>
  </prop>
  <CAL:filter>
    <CAL:comp-filter name="VCALENDAR">
      <CAL:comp-filter name="VEVENT">
        <CAL:time-range start="20200916T185919Z"/>
      </CAL:comp-filter>
    </CAL:comp-filter>
  </CAL:filter>
</CAL:calendar-query>
2020-12-15 20:59:19:928 verbose [index]: 	RESPONSE BODY: 
<?xml version="1.0"?>
<D:multistatus xmlns:D="DAV:" xmlns:CAL="urn:ietf:params:xml:ns:caldav" xmlns:CS="http://calendarserver.org/ns/" xmlns:ICAL="http://apple.com/ns/ical/">
  <D:response>
    <D:href>/caldav/cal/[email protected]/exampleCal1/</D:href>
    <D:propstat>
      <D:status>HTTP/1.1 200 OK</D:status>
      <D:prop>
        <D:supported-report-set>
          <D:supported-report>
            <D:report>
              <CAL:calendar-query/>
            </D:report>
          </D:supported-report>
          <D:supported-report>
            <D:report>
              <CAL:calendar-multiget/>
            </D:report>
          </D:supported-report>
          <D:supported-report>
            <D:report>
              <CAL:sync-collection/>
            </D:report>
          </D:supported-report>
        </D:supported-report-set>
      </D:prop>
    </D:propstat>
  </D:response>
  <D:response>
    <D:href>/caldav/cal/[email protected]/exampleCal1/41c6fcc0-aea7-304f-983a-a6fb7e568109.ics</D:href>
    <D:propstat>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
  <D:response>
    <D:href>/caldav/cal/[email protected]/exampleCal1/faf52014-372e-44ed-9eba-2fc1a2b8d82d.ics</D:href>
    <D:propstat>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
  <D:response>
    <D:href>/caldav/cal/[email protected]/exampleCal1/895a04b2-30df-4927-ba03-dfc55514f6e7.ics</D:href>
    <D:propstat>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>
2020-12-15 20:59:19:933 verbose [server]: 	REPORT /caldav/cal/[email protected]/exampleCal1/ 207 - - 9.741 ms

[sedenardi]

<D:getetag> is present on the actual event objects in the response. Are you expecting them on the actual calendars?

[aharter]

I digged a bit deeper and edited the log entry to only contain the request that seem to cause the problem. I also forgot to mention, that I only tested it with Example Calendar 1.
There are several things that come into play:
First, the request payload is ignored. This is due to the hard-coded /D:propfind/D:prop in getWithChildren as described by HeikoTheissen in #6.
After that, the request only defines start for time-range. The example retrieve function uses (v.startDate >= start && v.endDate <= end), which causes no events to returned. However, this triggers issue #8. Since the nsMap of the previous request is used, all events show up in the payload. However, without the etag, triggering the issue.

I modified the code accordingly. This causes the recurring events (as defined by Testing Event 5) to not be part of the payload. From what I can tell, this is due to the check v.weekly in examples/data.js, which is always undefined.

I hope I can hand in a PR soon. Just thought I share my findings for transparency.

[sedenardi]

Can you post the XML response that the server is sending that's jamming up the Android app?