Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

Facing an very strange issue while upgrading to AEM6.5

prahlad-dutta
Level 2
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
jbrar
Correct answer by
Employee
Employee

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
bnb84098
Level 1
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.
jbrar
Correct answer by
Employee
Employee

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

prahlad-dutta
Level 2
Level 2
No, not still not able to access even though provided read permission to /etc directory
prahlad-dutta
Level 2
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

bnb84
Level 1
Level 1
Prahlad, glad you that working from the other dispatcher ... Luck on fixing that Pub.
prahlad-dutta
Level 2
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 "
Jörg_Hoh
Employee
Employee

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.

prahlad-dutta
Level 2
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.

hemantbellani_p
Level 1
Level 1

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

Jörg_Hoh
Employee
Employee
With "Recent requests" I meant this: http://localhost:4502/system/console/requests
prahlad-dutta
Level 2
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.
prahlad-dutta
Level 2
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.

Jörg_Hoh
Employee
Employee
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.