404 issues with ClientLibs

Hi @priyanair1 ,

Try below steps:

1. Confirm ClientLib Availability on Publish Instance

Check if the ClientLibs exist on the publish instance:

Access:

If 404:

Go to CRXDE Lite on Publish: https://<publish-host>/crx/de

Confirm that /apps, /etc.clientlibs, /etc/designs, or /libs contain the relevant paths.

Fix:
If not present, activate (replicate) the clientlibs folders from Author to Publish:

From AEM Author: Go to /apps/your-project and /etc.clientlibs/your-project, right-click > Replicate.

Hi @priyanair1 ,

Please verify these points also - 

1. ClientLibs Embedded Incorrectly or Missing Dependencies

If a parent clientlib embeds other libraries via categories,  and one of the embedded clientlibs is missing or not replicated to the publish instance, it can result in 404 errors even if the top-level clientlib exists.

Check:

• The embed and dependencies properties in the cq:ClientLibraryFolder node.

• Ensure all referenced clientlibs are present and published.

2. ClientLib Proxy Servlet Misconfiguration

If you're relying on the proxy servlet (/etc.clientlibs), verify:

Check:

• The OSGi configuration org.apache.sling.servlets.resolver.SlingServletResolver has correct executionPaths.

• No filters, servlets, or dispatcher rules are unintentionally blocking /etc.clientlibs.

3. CSRF Filter Blocking Requests

Sometimes the CSRF filter in AEM blocks access to /etc.clientlibs if headers or referrer settings are unexpected.

Check:

• Look for CSRF-related rejections in error.log.

• Review configuration at /system/console/configMgr/com.adobe.granite.csrf.impl.CSRFFilter.

4. Content Security Policy (CSP) Blocking Assets

If a restrictive CSP header is set, it may prevent browsers from loading assets from /etc.clientlibs.

Check:

• HTTP response headers for Content-Security-Policy.

• Confirm /etc.clientlibs is allowed in the CSP rules.

5. Missing ClientLib Categories in HTML Output

The expected clientlibs may not appear in the final HTML if:

• There's a mismatch between author and publish content.

• The component or template logic (HTL/Sightly) conditionally omits the clientlib.

Check:

• View the rendered page source and look for missing <link> or <script> tags for /etc.clientlibs.

6. Directly Test via Browser Dev Tools

Use Chrome DevTools (Network tab) or curl to request:
/etc.clientlibs/site/clientlibs/clientlib-name.css

Interpret Results:

• If it returns 404 only on publish, check for missing replication or failed builds.

• If it returns 404 despite being built, enable detailed dispatcher logging or  mod_rewrite debugging in Apache to trace the request path.

Try these and let me know if something works.

Thanks.

Hi @priyanair1,

I think, the issue may not be with the dispatcher alone.

Here are several potential root causes and how to resolve them:

1. ClientLibs not replicated to publish

Even if filters are in place, the actual content (clientlibs) must exist on the publish instance.

Check:

• On the publish instance, verify if /etc.clientlibs, /apps, or /libs are accessible.

• Use CRXDE or /libs/granite/ui/content/dumplibs.rebuild.html to see if clientlibs are available.

If missing, re-deploy or re-activate from Author to Publish.

2. Dispatcher cache not cleared

Sometimes the clientlib file was cached as 404 during an earlier request before content deployment.

Solution:

• Clear dispatcher cache for /etc.clientlibs, /apps, or specific paths like /etc.clientlibs/site/clientlibs/main.css.

3. Incorrect rewrite/vanity/redirect rules

Rewrite or redirect rules in Apache might be interfering, even if dispatcher filter allows it.

Inspect your rewrite.rules or vhost config for misbehaving redirects affecting /etc.clientlibs.

4. File system permissions (AMS specific)

In Adobe Managed Services (AMS), file system permissions or incorrect symbolic links in the dispatcher docroot could lead to 404s.

Check:

• The symlinks in dispatcher cache path resolve correctly.

• You have permissions and correct owner/group on all docroot folders.

Hope that helps!