[jira] [Updated] (SLING-8427) Sling Dynamic Include - TTL not being set on synthetic resources

["Robert Munteanu (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-8427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Munteanu updated SLING-8427:
-----------------------------------
    Fix Version/s:     (was: Dynamic Include 3.1.6)
                   Dynamic Include 3.1.8

> 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
>            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.2#803003)