[MGNLCACHE-125] Cache header negotiation does not work for first request after cache flush Created: 23/Oct/15  Updated: 15/Apr/16  Resolved: 02/Nov/15

Status: Closed
Project: Cache Modules
Component/s: cache core
Affects Version/s: 5.3.2
Fix Version/s: 5.3.3, 5.4.3

Type: Bug Priority: Critical
Reporter: Frank Sommer Assignee: Roman Kovařík
Resolution: Fixed Votes: 0
Labels: support
Remaining Estimate: 0d
Time Spent: 40m
Original Estimate: Not Specified

Issue Links:
Relates
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Sprint: Kromeriz 17
Story Points: 3

 Description   

We've got trouble with different cache headers for the same page request. Sometimes we saw the correct no-cache headers and sometimes the default cache configuration headers.

The pattern is that every first request after a cache flush will use the configured browser cache policies and overwrite the cache headers set by code. See Cache header negotiation

The reason seems to be that missing cache entries will be stored as uncacheable cache entries in the cache. And then the cache will bypass such cache entry requests. But for the first request the browser cache policies will overwrite the existing cache headers.



 Comments   
Comment by Roman Kovařík [ 02/Nov/15 ]

Investigation so far:

  • First request
    • wrapped by GzipCacheResponseWrapper in GZipFilter
    • SetExpirationHeaders (browser cache policy)
      • wrapped by CacheResponseWrapper in Store executor
      • A custom Header set in rendering on CacheResponseWrapper.
      • The headers set on the CacheResponseWrapper are never replayed (never used)!
    • GzipCacheResponseWrapper replays browser cache policy headers in GZipFilter
      As result, only browser cache policy headers are set.
  • Second request
    • wrapped by GzipCacheResponseWrapper in GZipFilter
    • SetExpirationHeaders (browser cache policy)
      • not wrapped by CacheResponseWrapper in Store executor since we know that the request should be bypassed.
      • A custom Header set in rendering on GzipCacheResponseWrapper can override a browser cache policy header.
    • GzipCacheResponseWrapper replays custom headers and browser cache policy headers (if those were not overridden) in GZipFilter.
      As result, only custom or both headers are set.
Comment by Roman Kovařík [ 02/Nov/15 ]

The cause:

  1. info.magnolia.module.cache.filter.CacheResponseWrapper#replaceHeader and appendHeader swallow cache negotiation headers which are never replayed.
  2. info.magnolia.module.cache.filter.ContentCachedEntry#addHeaders skips headers which are already set which make it impossible to override e.g. headers set by cache browser policy.
Comment by Evzen Fochr [ 02/Nov/15 ]

Commented PR.

Generated at Sun Feb 11 23:52:27 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.