[FOLIO-1663] Spike: back-end cache headers Created: 18/Dec/18  Updated: 23/Feb/22  Resolved: 23/Feb/22

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P3
Reporter: Matthew Jones Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: keep-bug, platform-backlog, security, security-reviewed
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to OKAPI-770 PoC: Okapi GET and HEAD cache Closed
relates to OKAPI-802 Okapi GET and HEAD cache: Code review... Closed
relates to OKAPI-772 Missing headers reported by ZAP need ... Open
Sprint:
Development Team: Core: Platform

 Description   

The back-end currently does not define any cache-control headers. We should be more explicit about which resources should and should not be cached and for how long. No caching can reduce client-side performance. Implicitly not caching can also have unexpected results, leaving caching decisions up to some intermediary network proxy.

Further, in a multi-tenant environment, we should instruct caching systems to take the x-okapi-token and x-okapi-tenant headers into consideration to avoid inadvertently caching responses across tenants or user (with say, fewer permissions). This can be done with the vary header.

How and when the headers are applied needs to be worked out. Should they be applied by Okapi? Are there defaults? The module owning the resource probably has the closest knowledge of what can and should be cached and for how long. Therefore should modules have some say (opt-in or opt-out) in which resources should have headers applied?



 Comments   
Comment by Dilshod_Khusanov [ 23/Feb/22 ]

Please provide concrete examples of the problem that it is supposed to solve. And ticket can be reopened.

Generated at Thu Feb 08 23:14:59 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.