Specify If-Unmodified-Since-Subsecond header?

[escowles]

The vagaries of RDF serialization prevent us from using ETags for conditional PUT/PATCH requests, leaving the If-Unmodified-Since header as the main alternative. However, the specification for If-Unmodified-Since requires a date format that does not allow fractional seconds. Implementers have found 1-second granularity insufficient — e.g., the Valkyrie optimistic locking implementation for Fedora 4 resorted to supplementing If-Unmodified-Since with a finer-grained in-memory lock, to avoid having to insert pauses in their test suite.

Should we specify an alternative header that allows finer granularity, called If-Unmodified-Since-Subsecond?

[dannylamb]

Another standard way to implement this type of behaviour is with a "version" counter. Quotes are there b/c this has nothing to do with preservation or mementos. But you can provide the "version" in a header upon request and work with it using the same behaviour/logic as an ETAG. Every time the resource is updated, you bump the counter.

I roughed out this sort of behaviour in CLAW, and ended up using a separate db table to avoid sticking the counter in the RDF.

[zimeon]

For reference: RFC7232 description of If-Unmodified-Since

[acoburn]

Generally, I am strongly 👎 on adding new headers, especially headers that may overlap with existing HTTP headers. @dannylamb is correct that many REST APIs that need to support arbitrary (millisecond) precision use a "version" parameter (or header). In the wild, I have always seen the query parameter used as opposed to a header. If you do specify a version parameter, you will want to be careful about the choice of term -- Trellis already uses a version parameter for use with Mementos.

One consideration with this issue, though, is that the weak ETag issue is really an issue that affects the Fedora4 implementation. It does not necessarily affect all implementations.

[tpendragon]

version is fine with me, and for optimistic locking is actually better in many ways.