CalDAV: Avoid GET after PUT if the server returned Schedule-Tag header
evolution-calendar-factory reports, when I upload a new event:
> PUT /dav/calendars/user/me/Default/15ad1570bf38dd61889c27005fc94a2ea2c2dd36.ics HTTP/1.1
> Soup-Debug-Timestamp: 1532037683
> Soup-Debug: EWebDAVSession 1 (0x7febbc0a85d0), SoupMessage 10 (0x7febbc0130c0), SoupSocket 11 (0x7febbc0034e0)
> Host: mail.aegee.org
> User-Agent: Evolution/3.29.90
> Connection: close
> Cache-Control: no-cache
> Pragma: no-cache
> If-None-Match: *
> Prefer: return=minimal
> Content-Type: text/calendar; charset="utf-8"
> Accept-Language: en-us, en;q=0.9
> Authorization: Basic [me:**********]
>
> BEGIN:VCALENDAR
> CALSCALE:GREGORIAN
> PRODID:-//Ximian//NONSGML Evolution Calendar//EN
> VERSION:2.0
> BEGIN:VEVENT
> UID:15ad1570bf38dd61889c27005fc94a2ea2c2dd36
> DTSTAMP:20180719T220101Z
> DTSTART:20180719T220000Z
> DTEND:20180719T223000Z
> SEQUENCE:2
> ORGANIZER;CN=Дилян Палаузов:MAILTO:
> me@example.org
> ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;
> RSVP=TRUE;CN=me;LANGUAGE=en:MAILTO:user@example.com
> SUMMARY:QQQ 1
> TRANSP:OPAQUE
> DESCRIPTION:QQQ 2
> RRULE:FREQ=DAILY;COUNT=2
> CLASS:PUBLIC
> CREATED:20180719T220123Z
> LAST-MODIFIED:20180719T220123Z
> END:VEVENT
> END:VCALENDAR
< HTTP/1.1 201 Created
< Soup-Debug-Timestamp: 1532037683
< Soup-Debug: SoupMessage 10 (0x7febbc0130c0)
< Server: nginx
< Date: Thu, 19 Jul 2018 22:01:23 GMT
< Content-Length: 0
< Connection: close
< Cache-Control: no-cache
< Accept-Patch: text/calendar; charset=utf-8; component=VPATCH; optinfo="PATCH-VERSION:1"
< Schedule-Tag: "da39a3ee5e6b4b0d3255bfef95601890afd80709"
<
> GET /dav/calendars/user/me/Default/15ad1570bf38dd61889c27005fc94a2ea2c2dd36.ics HTTP/1.1
> Soup-Debug-Timestamp: 1532037683
> Soup-Debug: EWebDAVSession 1 (0x7febbc0a85d0), SoupMessage 11 (0x7febbc0132a0), SoupSocket 12 (0x7febbc0034e0)
> Host: mail.aegee.org
> User-Agent: Evolution/3.29.90
> Connection: close
> Cache-Control: no-cache
> Pragma: no-cache
> Accept-Language: en-us, en;q=0.9
> Authorization: Basic [me:**********]
BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
BEGIN:VEVENT
UID:15ad1570bf38dd61889c27005fc94a2ea2c2dd36
DTSTAMP:20180719T220101Z
DTSTART:20180719T220000Z
DTEND:20180719T223000Z
SEQUENCE:2
ORGANIZER;CN=Дилян Палаузов:MAILTO:
me@example.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;
RSVP=TRUE;CN=me;LANGUAGE=en:MAILTO:user@example.com
SUMMARY:QQQ 1
TRANSP:OPAQUE
DESCRIPTION:QQQ 2
RRULE:FREQ=DAILY;COUNT=2
CLASS:PUBLIC
CREATED:20180719T220123Z
LAST-MODIFIED:20180719T220123Z
END:VEVENT
END:VCALENDAR
As of https://tools.ietf.org/html/rfc6638#section-3.2.10 Schedule-Tag substitutes ETag in some circumstances, so in this case no GET is necessary. Moreover, the GET above does not show ETag, but curl -u me:pw -D- https://mail.aegee.org/dav/calendars/user/me/Default/15ad1570bf38dd61889c27005fc94a2ea2c2dd36.ics
returns
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 19 Jul 2018 22:13:06 GMT
Content-Type: text/calendar; charset=utf-8
Content-Length: 642
Connection: keep-alive
Cache-Control: must-revalidate, no-transform, max-age=3600
Expires: Thu, 19 Jul 2018 23:13:06 GMT
Vary: Accept, Accept-Encoding
Accept-Ranges: bytes
Schedule-Tag: "da39a3ee5e6b4b0d3255bfef95601890afd80709"
ETag: "03394b198a60efcc25668d136e287b5522b3b3be"
Last-Modified: Thu, 19 Jul 2018 22:01:23 GMT
BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
BEGIN:VEVENT
UID:15ad1570bf38dd61889c27005fc94a2ea2c2dd36
DTSTAMP:20180719T220101Z
DTSTART:20180719T220000Z
DTEND:20180719T223000Z
SEQUENCE:2
ORGANIZER;CN=Дилян Палаузов:MAILTO:
me@example.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;
RSVP=TRUE;CN=didopalauzov;LANGUAGE=user@example.com
SUMMARY:QQQ 1
TRANSP:OPAQUE
DESCRIPTION:QQQ 2
RRULE:FREQ=DAILY;COUNT=2
CLASS:PUBLIC
CREATED:20180719T220123Z
LAST-MODIFIED:20180719T220123Z
END:VEVENT
END:VCALENDAR
So the server returns on GET ETag, which is not shown by evolution-calendar-factory. This makes me doubt, whether PUT returned an ETag, which the log hid.