[MAGNOLIA-4805] CLONE - Items with .cache. in their url should have far future Cache headers set, but do not. Created: 30/Jan/13  Updated: 04/Sep/13  Resolved: 24/Apr/13

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: 4.4.10, 4.5.7
Fix Version/s: 4.4.12, 4.5.9

Type: Bug Priority: Critical
Reporter: Christopher Zimmermann Assignee: Jaroslav Simak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
clones MGNLCACHE-4 Items with .cache. in their url shoul... Closed
Relates
causality
caused by MAGNOLIA-4568 Cache temp files are not cleared out ... Closed
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:

 Description   

Files such as css and js should be far future cached, there should be a header like: Cache-Control="max-age:525600". As originally implemented in http://jira.magnolia-cms.com/browse/MAGNOLIA-3297

But the files with .cache. in the url do not have any Cache-Control header set. For example look at this file on demopublic:
http://localhost:8080/magnolia-bundled-webapp/resources/templating-kit/themes/pop/css/mobile.2013-01-25-11-12-21-633.cache.css

Debugging on my local instance it looks like the executor which gets run for this file is Bypass. Bypass contains two executors.
#1. setExpirationHeader - which looks like it is working great - adding a really long Cache-Control max-age.
#2. executor.Bypass - which just continues down the filter chain.

Could it be that the executor.Bypass somehow nullifies the effect of the setExpirationHeader?

Im not an expert on the Cache module - perhaps there are timing concerns or something else. But it appears to be a problem.



 Comments   
Comment by Jan Haderka [ 24/Apr/13 ]

I don't see a test anywhere. And since the issue causing this problem was applied also on 4.4. branch we need to apply fix there as well.

Generated at Mon Feb 12 03:59:12 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.