Description
This is exceeding the current corrections-clarifications and even maybe-orthogonal classification, but running into it as an implementer and having remembered it wrong for several years gave me reason to suggest a relaxation of the specification.
This list summarizes what is in 7252 (and 7959 for the Block2 relation):
- ETag can be set in a response to indicate a property of the tagged representation, and is 1-8 byte long. It can not be repeated
- ETag can be set in a request to indicate that the client has some ETags and wants to have them validated. It can be repeated.
- Most of the time, the server may or may not send one, but there are a few situations where it MUST send it with a 2.03 Valid, and SHOULD send it with a Block2 (it won't send it, for example, if that resource is constant).
- ETag has lengths 1-8. In contrast, If-Match also allows the empty ETag, which means "only process this request if there is no current resource".
What this is missing is a way for the client to solicit the ETag, which makes sense when the server chooses not to send it (eg. on a resource too small to trigger block-wise transfer, or where the representation is in the order of size of the ETag). Still, a client can be in a situation where it needs to know the ETag, eg. to trigger a conditional deletion.
Currently, the only way for a client to obtain an ETag where the server doesn't usually send it is to either request a ridiculously small block size (for payloads >16 byte), or to guess a wrong ETag, send it in the request, hope that the server takes the hint to send the current one, and retries with a different guessed ETag if it was so unlucky as to be lucky with its guess. Yikes.
Proposed change, updating 7252:
ETag has a length of 0-8. A server IS ENCOURAGED TO send the tagged resource's ETag when responding to any request that contains an ETag. The zero-length ETag MUST only be used in requests, and by virtue of not matching any possible ETag, solicits the current representation and ETag.
Inspired by chrysn/aiocoap#371