Fix CACHE-CONTROL maxAge for client libraries - to ensure immediate deployment of new code

[fionas76543059]

hi folks,

Recently we noticed that one of our sites wasn't showing code updates we made via Cloud Manager.

We found that there was a CACHE-CONTROL header with max-age of an hour.

Sure enough, after the hour, the code updated.

I cannot find this parameter configured in our AMS AEM 6.5.20 installation. ( not cloud)

I assume I can add something to the dispatcher to configure this.  But what should I do exactly?

Specify somehow that I want the clientlibs to update immediately with max-age = 0. ???

Any advice would be appreciated.

thanks

Fiona

[BrianKasingli]

It’s best practice to keep clientlibs cached at the dispatcher and CDN levels to ensure your website is as performant as possible, so I would not remove the rule.

In fact, you don’t need to do anything because when you release a new change to AEMaaCS, the website cache is deleted. Assuming that your HTML pages are cached for a standard of 5 minutes at the CDN level, when the page is re-requested, the new clientlibs hash will be regenerated, and the updated frontend files will be visible. This is true when you have a CDN cache time of 5 minutes for your HTML pages.

[daniel-strmecki]

Hi @fionas76543059,

it is best practice to have a high TTL for JS and CSS files so they can be cached long in CDN.

<Location ~ ".*.lc-.*-lc.(min.)?(js|css)$">
        # Important - Cache control is set to immutable by AEM
        Header unset Cache-Control
        Header always set Cache-Control: max-age=2592000
</Location>

 With each file change/deployment, AEM generates a new hash value and changes the name of the JS/CSS file, so CDN and the browser will always pull the new version.

/etc.clientlibs/my-project/clientlibs/my-js.lc-5334516a308a40e7dd7b3c7a8ae96960-lc.min.css

Maybe you want to check if this part is not working for you.

Good luck,

Daniel

[MukeshYadav_]

Hi @fionas76543059 ,

It is necessary to cache the clientlibs for faster page load but at the same time newer code should reflect immediately after code deployment.

It can be achieved by versioning of clientlibs i.e. each time the code get build will generate a new path which won't cached hence served from AEM instance and get cache from now onward.

In AEM cloud versioning supported OOTB but not in AEM 6.5.

We can use ACS commons or other tools for the same in AEM 6.5, please have a look on below articles to achieve the same in AEM 6.5

https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/aem-6-5-implementation-of-...

https://www.aemcq5tutorials.com/tutorials/versioned-clientlibs-aem/

https://medium.com/@satyambansal001/aem-versioned-clientlibs-for-longer-caching-css-and-js-3f189b0f6...

Thanks

[fionas76543059]

Thanks everyone for replying.

I am puzzled that I am getting the CACHE-CONTROL header for some of my sites, but my main site has no CACHE-CONTROL parameter.  (SO I don't have the delay in deploying new code problem there.)  There is no difference in the vhosts files for any of the sites.

Has anyone got any idea where it comes from?

My immediate problem is the delay in deployment so I could temporarily set the clientlibs CACHE-CONTROL to max-age of 0 while I work out how to do the proper versioning of clientlibs ? Is this o.k.?

[fionas76543059]

Also, we don't have a CDN

[MukeshYadav_]

Hi @fionas76543059 , cache control header generally get added at dispatcher level.

There would be dispatcher folder in the code base, most probably somewhere inside vhost file you can see the cache control header command.

File would be present  probably at path  dispatcher/src/conf.d/enabled_vhosts/your-file-name.vhost

There you can set max to 0 which is not recommended, better implement clientlibs versioning mentioned in earlier reply.

Clientlib versioning will help in reflect the latest code after the deployment

Thanks

[fionas76543059]

Thanks Mukesh,

There is currently no configuration for CACHE-CONTROL in any of our dispatcher vhosts file.

So I am wondering where this header comes from (for some, not all of the sites.)

We have managed AWS, not cloud and not with a CDN.

Is it coming from some default in AEM ? Or from upstream somewhere?

thanks

Fiona

[iamnjain]

@fionas76543059 
Check carefully in your dispatcher codebase, it should be set in any of your Vhosts file only. 

An example from my project available vhost file

<LocationMatch "^/etc\.clientlibs/.*\.(?i:js|css|ttf|woff2)$">
    Header set Cache-Control "max-age=2592000,stale-while-revalidate=43200,stale-if-error=43200,public,immutable" "expr=%{REQUEST_STATUS} < 400"
    Header set Age 0
</LocationMatch>

[fionas76543059]

Thanks, no, I have nothing like that. The cache-control must be coming from somewhere else.

I see I do have a configuration for com.adobe.granite.ui.clientlibs.impl.

HTMLLibraryManagerImpl.xml where the htmllibmanager.maxage is set to -1.

I don't know if that configuration gives or takes away Headers

[EstebanBustamante]

Hey,

Are you using ACS Commons by any chance? Maybe check if you are using any this: https://adobe-consulting-services.github.io/acs-aem-commons/features/http-caching-headers/index.html 

[fionas76543059]

Thanks Esteban,

That is interesting too.

It looks like  I have a choice between (i) changing the clientlib names to ones with hashes in them

as explained above, and setting max-age to 0.

or (ii) do what you suggest above. Use ACS commons to put cache-control headers on requests by creating a OSGi config file for  com.adobe.acs.commons.http.headers.impl.DispatcherMaxAgeHeaderFilter for a given pattern.

Probably I will go for the 1st option as this seems the most recommended. I can't leave it as it is with different sites picking up max-ages seemingly at random.

[PRATHYUSHA_VP]

Hi @fionas76543059 

There might be a possibility cache headers set using mod_expires in .htaccess file like below. Please recheck

ExpiresByType text/css "access 1 day"
ExpiresByType text/html "access 1 day"
ExpiresByType application/json "access 1 day"

Hope this helps 

Thanks

[fionas76543059]

Thanks Prathyusha,

I can't find that text in our codebase .

But I can ask our Adobe Customer support guy if that .htaccess file with that configuration is on our production dispatchers.