This is corresponding to https://tools.ietf.org/html/rfc7232#section-2.3 but excludes "quotes" and still only permits A-Za-z0-9 afterwards.
From IEEE 2791-2020:
Everything except for the
spec_versionshall be included in the generation of an ETag - which can be "strong" or "weak". It is recommended that the ETag be deleted or updated if the object file is changed (except in cases using weak ETags in which the entirety of the change comprises a simple re-writing of the JSON).
An entity-tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.
ETag = entity-tag entity-tag = [ weak ] opaque-tag weak = %x57.2F ; "W/", case-sensitive opaque-tag = DQUOTE *etagc DQUOTE etagc = %x21 / %x23-7E / obs-text ; VCHAR except double quotes, plus obs-text
ETag: "xyzzy" ETag: W/"xyzzy" ETag: ""
This PR adds the weakness indicator
W/ - the character
/ was not permitted before.
Examples of suggested new BCO etags allowed:
"etag": "cfb77c3e5c9b0e937de215190106dadcc9af9f40fa19a4deacf9a5a3a42f5de6" "etag": "W/9ADBA1DF580548298010736EC6E8408B" "etag": "W/12871" "etag": "W/20210223T144401" "etag": "rev5"
Now a good question is if we also want to allow the rest of ASCII like in
etagc above, or stick with the more restrictive checksum-like alphabet as of today.
- should be allowed in order to use UUIDs like
. for version numbers and
: to allow time stamps? Or better leave this field quite restricted to force people thinking a bit about their opaque string?
I can see good reasons why we don't want the nested
" quote symbols within a JSON "strong". Of course we can't put the
W/ outside the
" string in JSON so the current description may still be confusing?