Add ability to cache by response content, check if response was actually changed even if it expired, return same headers on 304 and 200 by OlegYch · Pull Request #13274 · playframework/playframework

@OlegYch

…lly changed even if it expired, return same headers on 304 and 200

This brings Cached implementation closer to http spec by:
1. actually using response content as described by https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/ETag
2. preserving headers as described by https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/304

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.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.