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

Add VARY header for Resources/Files fetch endpoints #4295

Closed
pgetta opened this issue Sep 22, 2023 · 1 comment
Closed

Add VARY header for Resources/Files fetch endpoints #4295

pgetta opened this issue Sep 22, 2023 · 1 comment

Comments

@pgetta
Copy link

pgetta commented Sep 22, 2023

Is your feature request related to a problem? Please describe.
Complex applications (e.g. SBO) in some cases require fetching a lot of interconnected data from KG either by using SPARQL queries or sets of subsequent calls to ES/resource/file endpoints. Such operations might be slow which leads to degraded user experience.

Describe the solution you'd like.
Web clients these days support Cache API which, in the context of SBO, can be efficiently used to cache resources/files with fixed revisions, but requires VARY header (the spec, some pretty good article) to be present on the HTTP responses in order for key matching algorithm to function properly.

I think that a minimal solution would be to have a Vary: Accept header for Resources/Files fetch endpoints, so that clients can discriminate between requests for a file or its metadata, a resource or it's Web representation/redirect (when using Accept: text/html request header).

This will not only enable efficient caching on the client side, improving the UX, but as a side-effect will lower the amount of requests to KG.

An alternative solution would be to implement a custom key matching algorithm on the front-end with a config defining the list of headers that might impact the form of response, but this is less efficient and also requires keeping in tight sync with subsequent KG API changes (If out of sync - wrong content might be served to the client, I suspect this can be also tricky to detect/debug).

@imsdu
Copy link
Contributor

imsdu commented Oct 10, 2023

Fixed in #4337

@imsdu imsdu closed this as completed Oct 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants