[MAGNOLIA-3714] Expiration headers are not set for bypassed resources Created: 26/May/11 Updated: 11/Oct/11 Resolved: 19/Aug/11 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | cache |
| Affects Version/s: | 4.4 |
| Fix Version/s: | 4.4.5 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Jan Haderka | Assignee: | Ondrej Chytil |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||
| Issue Links: |
|
||||||||||||
| 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 |
|
When resource is evaluated to be bypassed by cache policy, the browser cache policies are not applied at all leading to situation where content recognized as dynamic by Magnolia will be cached by client browser. |
| Comments |
| Comment by Jan Haderka [ 26/May/11 ] |
|
The workaround for this issue is to convert bypass executor into chain and configure expirationHeader executor for it as shown in the attached screenshot. |
| Comment by Jan Haderka [ 28/Jun/11 ] |
|
After discussion, this issue will be solved by adding the expirationHeader executor to the bypass to allow most granular configuration possible. |
| Comment by Jan Haderka [ 04/Jul/11 ] |
|
tests in trunk are failing |
| Comment by Ondrej Chytil [ 04/Jul/11 ] |
|
Following builds are OK without changes of cache module also local build runs fine. |
| Comment by Jan Haderka [ 15/Aug/11 ] |
|
setExpirationHeader is executed after {{bypass}. IMHO this is not correct as executing the rendering might cause commit of the response in which case it would be no longer possible to set the headers. |
| Comment by Federico Grilli [ 18/Aug/11 ] |
|
Hi Ondřej, To reproduce it:
The result will be now a blank adminCentral. If one looks at the page source, one sees an empty dom. The fishy thing is that upon first Magnolia restart a module update is triggered and this is what shows up in the logs 2011-08-18 15:33:18,440 INFO info.magnolia.module.ui.ModuleManagerNullUI : ********************************************************************************************************* * * * Magnolia needs module updates or installs, and the magnolia.update.auto property is set to true, * * so they will be applied automatically now. * * * ********************************************************************************************************* 2011-08-18 15:33:18,510 WARN info.magnolia.module.InstallContextImpl : > Property "class" was expected not to exist at /modules/cache/config/configurations/default/executors/bypass/setExpirationHeader, but exists with value "info.magnolia.module.cache.executor.SetExpirationHeaders" and was going to be created with value "info.magnolia.module.cache.executor.SetExpirationHeaders". 2011-08-18 15:33:18,514 INFO info.magnolia.module.InstallContextImpl : > Replacing property class at /modules/cache/config/configurations/default/executors/bypass/bypass with value null. Previous value was info.magnolia.module.cache.executor.Bypass Subsequent restarts don't show this module update. |
| Comment by Federico Grilli [ 18/Aug/11 ] |
|
Wait, don't move. It's most likely a stupid version string error in info.magnolia.module.cache.setup.CacheModuleVersionHandler. |
| Comment by Federico Grilli [ 18/Aug/11 ] |
|
Yeah, problem solved! Thanks for the psychological support. |