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)?
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.