IEEE.org     |     IEEE Xplore Digital Library     |     IEEE Standards     |     IEEE Spectrum     |     More Sites

Skip to content

Allow weak etag prefix W/

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 etag, object_id, and spec_version shall 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).

But https://tools.ietf.org/html/rfc7232#section-2.3 says:

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

Examples:

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.

Perhaps - should be allowed in order to use UUIDs like 9ADBA1DF-5805-4829-8010-736EC6E8408B, . 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?

Edited by Stian Soiland-Reyes

Merge request reports