Eric Van Geem created SLING-8427:
------------------------------------

             Summary: 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
             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
(v7.6.3#76005)

Reply via email to