[SLING-8427] Sling Dynamic Include - TTL not being set on synthetic resources

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: Dynamic Include 3.1.2
• Fix Version/s: Dynamic Include 3.2.0
• Environment: AEM 6.3 - AEM 6.5
• Assignee: Robert Munteanu
• Reporter: Eric Van Geem
• Created: 20/May/19 19:57
• Updated: 22/Jun/20 12:10
• Resolved: 10/Jan/20 09:29

Description

When a TTL value is configured, the Cache-Control header does not get set in the response headers of the resource when the resource is synthetic. 

Expected behavior:

The existing SyntheticResourceFilter is responsible for identifying if the requested resource is synthetic, and if so, force the resourceType into the request by taking the resourceType from the request URL suffix. Then, the CacheControlFilter is to be invoked after this which reads the resource from the request (now the forced resourceType from the prior step) and sets the appropriate Cache-Control header if this resourceType is configured for SDI.

Actual behavior:

The CacheControlFilter is never executed after the SyntheticResourceFilter sets the forced resourceType in the request for the synthetic resource, thus the Cache-Control response header never gets set. 

 

More details:

I believe the cause of this issue is due to the way the CacheControlFilter's filter scope is defined; it is missing the forward filter scope. The SyntheticResourceFilter forces the resourceType by passing a new object of options to the request dispatcher 

dispatcher = slingRequest.getRequestDispatcher(resource, options);

This is then followed by a call to 

dispatcher.forward(request, response);

to forward the request in the filter chain.

This is where the CacheControlFilter should receive the request, but does not happen because the CacheControlFilter's filter scope has not been declared to receive forwarded requests. Simply adding the forward scope to the CacheControlFilter's list of scopes seems to resolve the issue.