Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork4.1k
Add ability to cache by response content, check if response was actually changed even if it expired, return same headers on 304 and 200#13274
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Is there any issue or related PR? |
@mkurz not that i've seen |
I support the change from a conceptual point of view, it's a noticeable improvement. I looked at the commit briefly, I'd suggest to create the hash of the response content in a streamed way (e.g. via a |
…lly changed even if it expired, return same headers on 304 and 200This brings Cached implementation closer to http spec by:1. actually using response content as described byhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/ETag2. preserving headers as described byhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/304For performance reasons this still uses two cache entries per resource, to avoid retrieving potentially large result content from potentially remote cache.For compatibility reasons new ability is gated via `play.cache.hashResponse` config entry.It should probably become default in the future as the old ETag value based on expiration date (essentially random value) doesn't seem to be useful or specified anywhere in http.The config value and relevant code should be removed then.
@alexdupre makes sense, updated |
Uh oh!
There was an error while loading.Please reload this page.
The primary reason for this is to increase performance by decreasing the amount of result content returned from server side and utilizing 304 response headers to drive the client to make less requests.
This also brings Cached implementation closer to http spec by:
For performance reasons this still uses two cache entries per resource, to avoid retrieving potentially large result content from potentially remote cache.
For compatibility reasons new ability is gated via
play.cache.hashResponseconfig entry. It should probably become default in the future as the old ETag value based on expiration date (essentially random value) doesn't seem to be useful or specified anywhere in http. The config value and relevant code should be removed then.cc@julienrf as the original author
cc@alexdupre as the most recent functionality contributor