Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support ETag #221

Open
reda-alaoui opened this issue Jun 28, 2020 · 6 comments
Open

Support ETag #221

reda-alaoui opened this issue Jun 28, 2020 · 6 comments
Labels
Cosium Features Cosium needs enhancement

Comments

@reda-alaoui
Copy link
Contributor

reda-alaoui commented Jun 28, 2020

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
Copy link
Collaborator

evert commented Jun 28, 2020

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

@evert
Copy link
Collaborator

evert commented Mar 25, 2022

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
Copy link
Contributor Author

Hi @evert ,

I was thinking of it for browser to server.

@evert
Copy link
Collaborator

evert commented Mar 25, 2022

@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
Copy link
Contributor Author

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
Copy link
Collaborator

evert commented Mar 26, 2022

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 evert added the Cosium Features Cosium needs label Sep 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Cosium Features Cosium needs enhancement
Projects
None yet
Development

No branches or pull requests

2 participants