ketting icon indicating copy to clipboard operation
ketting copied to clipboard

Published 20 hours ago • verified publisher icon badgateway

Support ETag

Open reda-alaoui opened this issue 4 years ago • 6 comments

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.

reda-alaoui avatar Jun 28 '20 17:06 reda-alaoui

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

evert avatar Jun 28 '20 18:06 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?

evert avatar Mar 25 '22 22:03 evert

Hi @evert ,

I was thinking of it for browser to server.

reda-alaoui avatar Mar 25 '22 22:03 reda-alaoui

@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()?

evert avatar Mar 25 '22 23:03 evert

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.

reda-alaoui avatar Mar 25 '22 23:03 reda-alaoui

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)

evert avatar Mar 26 '22 00:03 evert