Currently, ERP5 response based on Caching Policy Manager does not have Cache-Control header in '304 Not Modified' response case. Imagine the following scenario with intermediate cache server (like Apache Traffic Server) :
- intermediate cache server fetches from Zope and store it in its cache.
- we modify Caching Policy Manager configuration.
- intermediate cache server tries to revalidate its cache with 'If-Modified-Since' header.
- Zope responses '304 Not Modified' with the same Last-Modified value but without (updated) Cache-Control header.
- intermediate cache server does not (cannot) update its cache with updated cache configuration.
Thus cache inside intermediate cache server can stay forever, unless Zope returns a different Last-Modified value.
RFC 7232 says :
The server generating a 304 response MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request: Cache-Control, Content-Location, Date, ETag, Expires, and Vary.
With this PR, _setCacheHeaders is called before returning '304 Not Modified' so that intermediate cache can update its cache with updated Caching Policy Manager configuration.
Note that this bug also exists in CMFCore where Caching Policy Manager is implemented. zopefoundation/Products.CMFCore#111 (merged)