활동이 없어 이 대화는 잠겼습니다. 새 게시물을 작성해 주세요.
활동이 없어 이 대화는 잠겼습니다. 새 게시물을 작성해 주세요.
해결되었습니다! 솔루션으로 이동.
조회 수
답글
좋아요 수
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.
조회 수
답글
좋아요 수
조회 수
답글
좋아요 수
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.
조회 수
답글
좋아요 수
조회 수
답글
좋아요 수
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
조회 수
답글
좋아요 수
조회 수
답글
좋아요 수
조회 수
답글
좋아요 수
조회 수
답글
좋아요 수
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.
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.
조회 수
답글
좋아요 수
hi Jorge_Hoh , Please elaborate what would be "recent request" view?
조회 수
답글
좋아요 수
조회 수
답글
좋아요 수
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.
조회 수
답글
좋아요 수
조회 수
답글
좋아요 수