GitLab

This MR is to revert my 5-years-old change, where CachingPolicyManager 'updates' already-computed Cache-Control header, instead of 'overrides' it.

Honestly, I don't remeber the reason why I introduced such change 5 years ago.

(Note that, at the time of writing this, Caching Policy Manger is NOT called for all requests, but for view() and conversion results only. Try grep _setCacheHeaders.)

Here are several cases affected by this MR :

• For authenticated user access

1. CookieCrumbler sets Cache-Control: private for ANY authenticated access.
2. Caching Policy Manager result is max-age=300, public, like by 'public-conversion-result-no-language' policy in generic ERP5.

Without this MR, the result is Cache-Control: private, max-age=300, public but with this MR, the result is Cache-Control: max-age=300, public.

This is the main reason of this MR, so that logged-in user can have benefit of shared server-side cache for DMS conversion result etc.

• With tricky assignment in form etc.

1. In form or whatever called in view() processing, set explicitly RESPONSE.setHeader('Cache-Control', 'no-store')
2. But Caching Policy Manager result is max-age=300, public

Without this MR, the result is Cache-Control: no-store, max-age=300, public but with this MR, the result is Cache-Control: max-age=300, public.

For me, such no-store, public is non-sense and Caching Policy Manager should be always responsible for any 'matching' case. Also, if we want to support such, we can still create a dedicated Caching Policy by checking like 'no-store' in (request.RESPONSE.getHeader('Cache-Control') or '').lower() in its Predicate configuration.

/cc @romain @jerome @cedric.leninivin @vpelletier