search

nextcloud / deck

🗂 Kanban-style project & personal management tool for Nextcloud, similar to Trello
https://apps.nextcloud.com/apps/deck
GNU Affero General Public License v3.0
1.22k stars 278 forks source link

ETag vs headers #6387

Open JesperBllnbm opened 1 month ago

JesperBllnbm commented 1 month ago

Describe the bug The API returns conflicting headers: ETag is provided for resource validation, but Cache-Control is set to no-store. This prevents the client from caching and validating the resource, rendering the ETag ineffective.

To Reproduce

  1. Make a request to any endpoint returning ETag.
  2. Observe the response headers: Cache-Control:"no-cache, no-store, must-revalidate".
  3. Notice that caching is prevented despite ETag being present.

Expected behavior Either remove the no-store directive to allow caching with validation or remove the ETag header if caching is not intended.

Client details:

stefan-niedermann commented 1 month ago

I can't see a direct conflict (even though I have to admit that the pure presence of an ETag header has a semantical condlict with the cache-control header).

Both are separate features, and I read it as "The UserAgent is supposed to not cache the response. In case caching is wanted, don't assume that the data us still valid, so use the ETag to check conflicts in this case).

Can you please post references to what

the client

means in your context and ideally post a reference to a specification that says this combination is invalid?

remove the ETag header if caching is not intended.

Nice quick shot with nearly zero impact (except the ten thousands of users of the Deck Android app who will start downloading nearly the whole database on every sync - and the suffering administrators 😆). Jokes aside: Please (obviously) don't do that.

JesperBllnbm commented 1 month ago

I understand your point and agree that deleting the ETag can't be the solution here.

I think there is a misunderstanding, the critical header is no-store and not no-cache as you already referenced correctly:

Note that no-cache does not mean "don't cache". no-cache allows caches to store a response but requires them to revalidate it before reuse. If the sense of "don't cache" that you want is actually "don't store", then no-store is the directive to use.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control