Support ETag

[reda-alaoui]

First of all, thank you for this amazing library!

I would like Ketting to support ETag for 2 reasons:

• caching
• optimistic locking

With each GET, Ketting would send ETag value in the If-None-Match header. On GET success, Ketting would store the ETag in the resource.

On each PUT, Ketting would send the ETag value in If-Match header. On PUT success, Ketting would refresh the ETag value.

[evert]

Agreed, this is a good idea. With ketting 6 this should also be pretty achievable.

[evert]

Hi @reda-alaoui ,

Been a while since I looked at this, but wanted to confirm.. supporting etag and if-match is strictly for server-to-server right?

[reda-alaoui]

Hi @evert ,

I was thinking of it for browser to server.

[evert]

@reda-alaoui forgive my igorance, but don't browsers already do this out of the box? if you send an ETag, a subsequent GET will automatically get a If-None-Match, no? Or is this not true for fetch()?

[reda-alaoui]

I maybe the ignorant one here :)
I agree with you about the GET that is automatically managed by the browser.

My purpose is to use the full power of http to let the server manage optimistic locking. Therefore I would like Ketting to send the information during a modifying http request call (e.g. PUT). If the etag of a PUT request does not match the Etag on the server, the server would fail with a conflict status code.

But I may have made the wrong assumption that this use case was supported by the http spec.

[evert]

Ah the PUT use-case makes sense. I don't think the browser will do this automatically. In that case there's a few questions we'd need to answer:

• How can the user opt in/out of this behavior. Perhaps it's not desirable if this happens by default.
• What should happen if we do get a 412 error? Just pass on the exception?

There's also some tricky stuff to solve. In react-ketting users will continue to update the cache as they are making local modifications. The cache basically acts as a central state management system. So, it's not enough to just inspect the cache and grab the ETag. Perhaps the cache needs to be modified to store both the latest state + the latest server state if they differ.

(just brainstorming a bit here)