sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Van Geem (JIRA)" <>
Subject [jira] [Commented] (SLING-8427) Sling Dynamic Include - TTL not being set on synthetic resources
Date Mon, 20 May 2019 20:14:00 GMT


Eric Van Geem commented on SLING-8427:

Github PR created []

> Sling Dynamic Include - TTL not being set on synthetic resources
> ----------------------------------------------------------------
>                 Key: SLING-8427
>                 URL:
>             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.4
> 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

View raw message