Server Side Include on internal Dispatchers on AEMaaCS

[DanielWiFi]

Hello Adobe Community,

I'm currently trying to solve a problem regarding SSI includes on every internal instance, so dev, qa and stage. This issue does not happen on the prod-instance, but I'd still like to fix it to properly test the functionality also on other instances. Its annoying that it only works locally and on prod.

The problem is that SSI components are not properly served on the internal instances. Instead it shows the following error message: 

[an error occurred while processing this directive]

Looking through the dispatcher error logs, it shows some more details about the problem:

unable to include "/content/XXX/en/_jcr_content/root/header/search.icon.ssi.html" in parsed file /mnt/var/www/html/content/XXX/en/test.html, subrequest setup returned 401

I have increased the LogLevel to check if maybe Debug gives more information, but haven't found useful debug information on this.

To me it looks like when the dispatcher tries to load and serve the SSI parts via subrequests, it drops the authorization header and thus is not able to serve this data. After all the internal publish-instances are only accessible after authorization. This would also explain why this problem doesn't happen on the prod-instance, as over there the SSI and other content is public anyway.

Trying to access the SSI content directly via browser or postman also works when sending the proper auth headers.

However, this is just a guess of mine and I'm not sure what the exact problem is and how to solve it. I wasn't able to find a solution for this either, or even somebody running into the same logs.

Version of our AEMaaCS instances is 2025.3.19823.20250304T101418Z-250200 (but I guess its more of an dispatcher issue).

Here the AEM OSGI configuration for our Sling Dynamic Include:

{
  "include-filter.config.enabled": true,
  "include-filter.config.path": "/content",
  "include-filter.config.resource-types": [
     ... components are here ...
  ],
  "include-filter.config.ignoreUrlParams": [],
  "include-filter.config.include-type": "SSI",
  "include-filter.config.selector": "ssi",
  "include-filter.config.extension": "html",
  "include-filter.config.required_header": "Server-Agent=Communique-Dispatcher",
  "include-filter.config.add_comment": true,
  "include-filter.config.rewrite": false,
  "include-filter.config.appendSuffix": false,
  "include-filter.config.disableIgnoreUrlParams": false
}

Has anyone faced this issue before and knows a solution to it? Or this maybe a limitation of AEMaaCS?

Any help would be greatly appreciated!

[giuseppebag · Accepted solution]

the error suggests that when the dispatcher attempts to include an SSI component via a subrequest, the necessary authorization headers are not being properly forwarded. 

Here what I would do:

• Ensure that the dispatcher configuration is correctly forwarding all necessary authorization headers, such as Authorization or Cookie, during subrequests for SSI content.
• Review the dispatcher's cache and error configurations, specifically the rules related to forwarding headers. Look for any configurations that might strip or not forward necessary headers during subrequests.

/etc/httpd/conf.dispatcher.d/filters/filters.any: Ensure that the filter rules are not blocking access to the SSI resources when accessed. For example, confirm a rule like this exist:

/1001 { /type "allow" /method "(GET|HEAD)" /url "/content/*.ssi.html" /headers "*" }

/etc/httpd/conf.dispatcher.d/cache/rules.any: Verify that the cache rules are not interfering with the authorization.

/etc/httpd/conf.dispatcher.d/clientheaders/clientheaders.any: Review the client headers. It is very likely that the auth headers are not passed. You must add the authorization headers to the allowed client headers.

• Use tools like curl or Postman to manually simulate the subrequests that the dispatcher makes, including the required authorization headers. This can help isolate whether the issue is with the headers being stripped or malformed.
• Confirm that the SDI required_header is set appropriately and that it's being respected during the subrequests.
• Check Cloud Manager logs for any dispatcher-related errors or warnings.
• Increase Dispatcher Log Level to TRACE

[arunpatidar]

Hi @DanielWiFi 

What type of access protection are you using? Are you implementing Basic Authentication at the Dispatcher level, Publisher (CUG), or at the CDN?

If authentication headers are used at both CUG and Dispatcher, they might cause issue.

However, if authentication is handled at the CDN level, I assume there shouldn't be any issues.

[DanielWiFi]

Hello arunpatidar,

Access Protection was just handled via Basic Authentication on the Dispatcher level. Nothing happening with the CDN for the internal instances.

Today I found the issue, with the Authorization Header being accidentally removed for the internal instances. Removing that single line fixed the issue.

[DanielWiFi]

Hello giuseppebag,

You are right, the issue was that the Authorization Header was getting dropped for the subrequests. I looked closer through our vhost files and found that for our internal instances, we remove the Authorization header via:

RequestHeader unset Authorization

Removing this part made the SDI work again. 

I also tried your other suggestions, but filter has no /headers parameter and AEMaaCS Dispatcher doesn't allow TRACE logs. Double-checking the different auth settings though made me stumble about this line that has been causing issues for me.

So thank you for your help!