Expand my Community achievements bar.

Guidelines for the Responsible Use of Generative AI in the Experience Cloud Community.
SOLVED

Facing an very strange issue while upgrading to AEM6.5

Avatar

Level 2
Fonts (referenced in clientlib) are not getting rendered via dispatcher, though same is rendering fine on publisher. Below is the log from dispatcher:
---
[]Found farm myproject for myproject-ci-aem65.int.corp
[]checking [/etc.clientlibs/myclientlib/resources/fonts/GloberSemiBold/GloberSemiBold.woff2]
[]cachefile does not exist: /apps/em/dispatcher/cache/etc.clientlibs/myclientlib/resources/fonts/GloberSemiBold/GloberSemiBold.woff2
[]try to create new cachefile: /apps/em/dispatcher/cache/etc.clientlibs/myclientlib/resources/fonts/GloberSemiBold/GloberSemiBold.woff2
[]cache-action for [/etc.clientlibs/myclientlib/resources/fonts/GloberSemiBold/GloberSemiBold.woff2]: CREATE
[]Reusing connection: 10.20.30.40:4503
[]Connected to backend rend01 (10.20.30.40:4503)
[]Adding request header: host
[]Adding request header: Accept
[]Adding request header: Accept-Encoding
[]Adding request header: Accept-Language
[]Adding request header: Cookie
[]Adding request header: Origin
[]Adding request header: Referer
[]Adding request header: User-Agent
[]Adding request header: X-Forwarded-Port
[]Adding request header: X-Forwarded-Proto
[]Adding request header: Via
[]Adding request header: X-Forwarded-For
[]Adding request header: Server-Agent
[]response.status = 204
[]response.headers[Date] = "Tue, 05 May 2020 05:17:38 GMT"
[]response.headers[Cache-Control] = "no-cache"
[]Storing socket for later reuse: 10.20.30.40:4503
[] "GET /etc.clientlibs/myclientlib/resources/fonts/GloberSemiBold/GloberSemiBold.woff2" 204 none [myproject/rend01] 1ms
---
When we hit font file directly (not via site), it get cached properly and started working. Issue seems to be with caching on dispatcher, as dispatcher response status is 204.
 
Any help is highly appreciated!
1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

Can you do the following test:

 

- Allow read access for the "anonymous" user on the /etc directory

- Check if you are able to load the font files.

View solution in original post

14 Replies

Avatar

Level 1
Are you able to see the empy directories above GloberSemiBold.woff2 font file ? Is the woff2 font type allowed in your dispatcher rules ? On other clients, we had to add some of these font file types to the dispatcher ALLOW rules.

Avatar

Correct answer by
Employee Advisor

Can you do the following test:

 

- Allow read access for the "anonymous" user on the /etc directory

- Check if you are able to load the font files.

Avatar

Level 2
No, not still not able to access even though provided read permission to /etc directory

Avatar

Level 2

We have checked pointing this dispatcher to other publisher and it started working. Seems like issue with pub, but not able to find out exact problem

Avatar

Level 1
Prahlad, glad you that working from the other dispatcher ... Luck on fixing that Pub.

Avatar

Level 2
font folder is looks empty. No font font cache are there. And woff2 font is allowed in dispatcher rule "/0056 { /type "allow" /url "*.woff2" } # enable woff2 "

Avatar

Administrator

@Jörg_Hoh Any pointer here?

 



Kautuk Sahni

Avatar

Employee Advisor

When you request this file via dispatcher, you'll see a request to the AEM publish as well (the request created by the dispatcher); what's the response code of AEM? Is it also 204 (it should)? In case it is, can you go to that publish instance, search this request in the "recent request" view and post the details here? I am especially interested in the servlet handling this request.

Because I am not aware that the ClientLibProxyServlet is able to return the statuscode 204; this statuscode is something I would rather expect in a WebDAV scenario.

Avatar

Level 2

Hi @Jörg_Hoh,

Agreed with you point. I have tried to the same steps but not able get any request in publisher end for the fonts. But one strange behavior if I hit the font in a separate tab it downloaded at that time on publisher we get a request for the same. And after when we hit the page through dispatcher font are loading. I mean cache created for the fonts.

Avatar

Level 1

hi Jorge_Hoh , Please elaborate what would be "recent request" view?

Avatar

Employee Advisor
With "Recent requests" I meant this: http://localhost:4502/system/console/requests

Avatar

Level 2
As I said when we didn't receive the request in publisher for font first time but when we direct hit the fonts in a separate window then the request comes into "recent request" view as well.

Avatar

Level 2

One workaround we tried on dispatcher, In our dispatcher we allow "*" for /clientheaders.

So, we add all the headers seen in browser instead of "*" and remove "Origin" header from there then the font is loading (response: 200). But with "Origin" it won't work. Not sure is it the correct solution.

Avatar

Employee Advisor
So you are saying, that if the "Origin" header is no longer proxied, it's working? And in case that this header is present the request is not forwarded to AEM at all? In that case I would increase the dispatcher logging to maximum and check what happens there.