Errata Search
RFC Number:		Errata ID:
Source of RFC		Status:	All/Any Verified+Reported Verified Reported Held for Document Update Rejected
Area Acronym:	All/Any app art gen int ops rai rtg sec tsv	Type:	All/Any Editorial Technical
WG Acronym:		Submitter Name:
Other:	All/Any IAB INDEPENDENT IRTF Legacy Editorial	Date Submitted:
Summary Table Full Records

RFC 4791, "Calendaring Extensions to WebDAV (CalDAV)", March 2007

Source of RFC: IETF - NON WORKING GROUP
Area 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.

Report New Errata