Dispatcher - font files are cached with size 0 following design tree activation

[dorianhallward]

When we upload a new custom clientlib - to etc/designs - and then do a tree activation, the next time we request a webpage that includes those font files, then the font files are created in the dispatcher with file size 0.  The resulting impact is that when requesting a web page in the browser, font files are not properly downloaded (browser reports "Failed to decode downloaded font:")

We can work around this issue by connecting to the dispatcher and manually removing the font files before re-requesting them (when they are subsequently cached and served correctly).  In front of our Apache dispatchers we use Cloudflare as a CDN.

Is this a known problem with the dispatcher or likely to be a combination of the above (we also have CORS configurations in place to specifically allow cross origin use of the font files)?  

[hamidk92094312]

Please check the following thread that might be helpful to you:

Clientlibs not loading the fonts when placed in apps

[dorianhallward]

Thanks for the suggestion hamidk11679710​​. 

We are aware of the advice to move clientlibs out of etc/designs (and note: our issue does not involve http 404 errors as in Clientlibs not loading the fonts when placed in apps).  Our issue is not seen when requesting pages directly from a publisher instance, so i am happy our font files hosted at /etc/designs/sh/assets/fonts are accessible and served correctly from AEM.

On closer inspection, the caching problem only arises when requests are made first via our CDN (Cloudflare), following tree activation of etc/designs/sh.  As mentioned above, our current 'sub-optimal' workaround is to request font files directly of the dispatcher - following tree activation - before a request hits AEM via the CDN.  I suppose our next step is to trace the incoming requests to the dispatcher - and subsequent request handling - to understand why font files are not being correctly stored in the dispatcher cache.

[Vish_dhaliwal]

Enable DEBUG or TRACE level logging on dispatcher.log file and verfiy the requests at dispatcher and publish level.

[Gaurav-Behl · Accepted solution]

Probably its the wrong/missing configuration for that font-type(s) in your webserver config (assuming apache 2.4) or CloudFlare config.

If you're sure that it is a webserver issue rather than a CDN issue then you may ignore couple of steps mentioned below.

- Check if the behavior happens when its a HIT or MISS from CloudFlare?

- Test the behavior against your origin server to isloate the issue in webserver vs CDN config

- Check if ModMimeUsePathInfo is turned On for that specific handler in webserver  -- Installing Dispatcher

- Check if that specific font type is handled in mod_mime block  E.g.   AddType application/x-font-ttf .ttf .ttc    Refer - https://stackoverflow.com/questions/7415640/correct-apache-addtype-directives-for-font-mime-types  or  https://duntuk.com/optimized-apache-24-httpdconf