[MGNLIMG-105] Ensure that images are set to cache into the far future Created: 03/Jan/13  Updated: 26/Jun/13  Resolved: 26/Jun/13

Status: Closed
Project: Imaging
Component/s: None
Affects Version/s: 3.0
Fix Version/s: 3.0

Type: Improvement Priority: Major
Reporter: Christopher Zimmermann Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLIMG-112 Ensure that assets and asset renditio... Open
relates to MGNLDAM-239 Thumbnails in Assets App are very slo... Closed
relation
is related to MGNLUI-340 Images and assets should be cached on... Closed
is related to MGNLIMG-103 Set a header on responses instructing... 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)
Date of First Response:

 Description   

now that we have a fingerprint technology which inserts the modification date into an images url, image caching should be set to the far future.



 Comments   
Comment by Christopher Zimmermann [ 03/Jan/13 ]

103 is now out of date and we should ensure that caching is set for future.

Comment by Magnolia International [ 16/Jan/13 ]

Here's a bit of a conversation I've had with Espen and Tobias on Hipchat

the finger printing is a simple cache killer, adds a timestamp to prevent caching.
like mgnlCK=1326122203385 but in this case its in the path

(although, IIRC, mgnlCK is "current timestamp" - whereas this "fingerprint" uses the image's modification date?)

What I don't understand is that the imaging module already takes care of that - if source was modified,
image gets regenerated. It doesn't (or didn't, before MGNLIMG-103) add browser headers, but implicitly relied on the cache module to handle that. By default, admincentral is(was?) excluded from the cache, but images generated by the servlet (under /.imaging) are indeed cached, even on an author instance, I believe. So I'm not sure what problem we're trying to work around here, but it sounds like we've been running in circles.

If images generated for admin central need to be behave differently from a caching perspective, why not configure a different servlet, and/or play with the settings of the cache module ?

Comment by Christopher Zimmermann [ 26/Jun/13 ]

Removed no-cache http headers in the Imaging servlet.

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