RFC Errata
RFC 4791, "Calendaring Extensions to WebDAV (CalDAV)", March 2007
Note: This RFC has been updated by RFC 5689, RFC 6638, RFC 6764, RFC 7809, RFC 7953, RFC 8996
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 4840
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ricki Hirner
Date Reported: 2016-10-25
Section 5.3.4 says:
A response to a GET request targeted at a calendar object resource MUST contain an ETag response header field indicating the current value of the strong entity tag of the calendar object resource.
It should say:
A response to a GET request targeted at a calendar object resource MUST contain an ETag response header field indicating the current value of the strong entity tag of the calendar object resource. Note that using another content coding (Content-Encoding) than "identity" (for instance, when a compressed version of the resource is sent) will cause the ETag reported by GET to change and make it unusable for If-Match etc.
Notes:
Content-Encoding (in opposite to Transfer-Encoding) changes strong ETags, see RFC 7232 2.3.3 for an example. So if you GET a resource with another content coding than "identity" (for instance, "gzip"), the (strong) ETag could be "abc-gzip" instead of "abc". If you then send a conditional request (which requires a strong ETag) with If-Match: "abc-gzip", it may not work as expected. The solution seems to be to use Transfer-Encoding whenever possible.