[
https://issues.apache.org/jira/browse/SLING-8427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu resolved SLING-8427.
------------------------------------
Resolution: Fixed
> Sling Dynamic Include - TTL not being set on synthetic resources
> ----------------------------------------------------------------
>
> Key: SLING-8427
> URL: https://issues.apache.org/jira/browse/SLING-8427
> Project: Sling
> Issue Type: Bug
> Affects Versions: Dynamic Include 3.1.2
> Environment: AEM 6.3 - AEM 6.5
> Reporter: Eric Van Geem
> Assignee: Robert Munteanu
> Priority: Major
> Fix For: Dynamic Include 3.1.8
>
>
> 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
> {code:java}
> dispatcher = slingRequest.getRequestDispatcher(resource, options);{code}
> This is then followed by a call to
> {code:java}
> dispatcher.forward(request, response);{code}
> 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
