W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2016

[whatwg] Semantic detection of stale server state

From: James Roper <james@lightbend.com>
Date: Tue, 22 Nov 2016 22:41:03 +1100
Message-ID: <CABY0rKNj14afbSsNrVvaAo+fzuM2Et2rb=t_SwN4o2L4euOpXg@mail.gmail.com>
To: whatwg@whatwg.org
Hi all,

This is my first post to this list, so if this discussion is best had
elsewhere, please let me know :)

In today's world of servers being implemented as distributed systems, eg
microservices, there are situations where a client may have more up to date
knowledge of a resource than the server it's requesting the resource from
does.  An example would be one where the server employs CQRS - in CQRS you
have a write-side that is updated synchronously, and a read-side that may
be updated asynchronously, and it may take time for updates to be
propagated from the write-side to the read-side.  So, if a client makes a
PUT request on a resource, and the response returns successfully, and then
the client immediately issues a GET request on that same resource, the
returned resource may not yet reflect the result of the PUT request.  This
is not a caching issue that could be solved by adding a no cache pragma
header - the servers read-side representation of the resource has simply
not yet been updated due to the asynchronous nature of the implementation
of the server.

In order to address the problems associated with these scenarios, it would
be useful if the client could, semantically, detect whether a response it
receives to a query is out of date compared to the knowledge that it has.
It perhaps could use date based headers such as Last-Modified, but this
doesn't tend to work so well in a distributed system - it is impossible in
a distributed system for all nodes to agree on the current time, and clock
skew can be a big problem.  Additionally, the prime use case - a client
seeing its own writes immediately - is likely to need much better precision
than what date headers can offer.

Unless there is a more recent spec that I'm not aware of, I can't see
anything in the HTTP spec that addresses this problem. I'm thinking a
mechanism that extends the use of ETags may be useful - in response to a
PUT, POST or DELETE request, a server may send an ETag header, then the
client in a subsequent request may send that ETag in an If-At-Least-Match
or If-Up-To-Date header. I have considered the existing If-Match header,
except that it's not usually a match that you need to assert - a client
would generally be interested in any other updates that have happened since
it did its update, so If-Match probably isn't the right approach, it should
be a precondition that the server can satisfy at least that tag, not
exactly that tag. The ETag, a value opaque to the client, could represent
the version of the entity after the update was performed, and then the
server, when serving the request, could use it to check whether its
read-side view has a representation that matches at least that version of
the entity.  If it's not, then perhaps the server could respond with a 412
response, though whether this should be considered a client error or server
error is up for debate.

There are also some other considerations, such as what if the client makes
a request to get a resource of which the resource it updated is a subset
of, such as a list of resources, as would be done in a UI where you create
a new thing and then return to a view of all the things you've created - is
there a semantic way that an ETag or other tag could be applied to the list
of things resource?  Also, maybe a failure response is not useful, since
this is intended for use on a GET and so proceeding the request is safe,
maybe it's just useful to return the not yet updated resource in the
response, but indicate to the client that it is stale in a header or with a
new 200 or 300 response code.

Does anyone think that this would be a problem that would be interesting to
provide a semantic solution for in HTTP?


*James Roper*
*Software Engineer*

Lightbend <https://www.lightbend.com/> – Build reactive apps!
Twitter: @jroper <https://twitter.com/jroper>
Received on Tuesday, 22 November 2016 11:42:04 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:40 UTC