MUST ETag on GET, but only SHOULD If-Match on PUT and DELETE

[BigBlueHat]

I'm thinking these should match. 😉

We should either:
a) require MUST If-Match on PUT & DELETE (though that's a new heavy-ish requirement / system expectation--however wise!)
b) lower ETag to SHOULD on GET, so it matches the others.

Granted, ETag headers are super good for caching, but not all systems generate them so good (nor by default).

Thoughts?

[azaroth42]

The ETag header requirement (as opposed to SHOULD) comes from LDP, e.g. 4.2.1.3 (https://www.w3.org/TR/ldp/#ldpr-resource or thereabouts)

Making If-Match a MUST would be a burden for very high traffic and low fidelity systems. It's only significantly useful when multiple users have write access to the same resource ... which doesn't seem like a primary use case for Annotations.

I appreciate the desire to be consistent (symmetry is beauty, after all) ... but I think the uses for ETag are greater than the uses of If-Match (e.g. cache control), so it's already in favor of ETag being more useful than If-Match.

[BigBlueHat]

👍 I'm cool to close then.

[azaroth42]

Agreement on call of 7/15 to make editorial change to describe the rationale for the difference, as above, in the specification.

[BigBlueHat]

@azaroth42 related question. Should the ETag value change whenever Content-Location and/or the id change?

Currently, all the various representations of the container share the same ETag value even, though the contents vary widely based on the Prefer values.

The entity itself, of course, is unchanged, however, so should we add Prefer to the Vary list to make these distinct to caches?

That seems more accurate than having the ETag value change when the underlying entity has not.

Thoughts?

[azaroth42]

This is (essentially) the difference between Strong and Weak ETags: https://en.wikipedia.org/wiki/HTTP_ETag#Strong_and_weak_validation

LDP simply requires ETags and doesn't make any statement about strong vs weak. My preference is for weak, as changing the ETag for every different representation makes it useless. The resource hasn't changed, even if a different representation of the resource has been requested. The Content-Location header should be sufficient for caching (but would love to hear practical experience of that), though it would be good to put Prefer into Vary.

And the same applies to both container/collection and annotation representations.