nginx font hosting

  • Hey Leute, ich versuche gerade Font Awesome bei Wordpress einzubinden, die Fonts werden auf einem meiner Server gehostet, aber ich sehe dummerweise nur diese rechteckigen Kästchen, statt der Icons, ... ich befürchte es liegt an nginx.

    Wenn wer irgend einen Tipp hat, wie ich nginx dazu bewege, fonts bereit zu stellen, wäre das phänomenal, ...


    mime.types schaut mittlerweile so aus:


    Code
    1. application/x-font-ttf ttc ttf;
    2. application/x-font-otf otf;
    3. application/font-woff woff;
    4. application/x-font-woff woff;
    5. application/font-woff2 woff2;
    6. application/vnd.ms-fontobject eot;

    die vhost config enthält ebenfalls:

    Code
    1. location ~ \.(ttf|ttc|otf|eot|woff|woff2|font.css|css|js)$ {
    2. add_header Access-Control-Allow-Origin "*";
    3. }



    Würd mich über jeden Vorschlag freuen :)

  • Tauchen im Entwicklermodus des Browser irgendwelche hilfreichen Meldungen auf?

    Ich sehe leider nichts. Hab das ganze mal zum Testen in ne einfache html datei gestopft, .. mit mäßigem erfolg, selbt wenn ich absolute pfade im css verwende, ...


  • Scheint zu klappen, lag wohl eher am fast_cgi cache, .. hab den nun mal gepurged, zumindest die Testseite geht nun. Mal gucken wie sich das nun bei Wordpress selbst verhält

  • Grüße,


    da saß ich die letzten Tage auch dran. Auf einem neuen vServer die ganzen fonts "gepackt" und dann die "bootstrapcdn.com"-Links umgeschrieben.

    Leider Funktioniert es trotz löschen des fastcgi-caches noch nicht zu 100%. Bei einigen funktioniert es, bei anderen nicht (obwohl der Link richtig ist und über das www auch erreichbar ist).

  • Grüße,


    da saß ich die letzten Tage auch dran. Auf einem neuen vServer die ganzen fonts "gepackt" und dann die "bootstrapcdn.com"-Links umgeschrieben.

    Leider Funktioniert es trotz löschen des fastcgi-caches noch nicht zu 100%. Bei einigen funktioniert es, bei anderen nicht (obwohl der Link richtig ist und über das www auch erreichbar ist).

    Daran gedacht den lokalen Cache auch zu löschen? 😊

  • Nee,

    aber ich habe in meiner mime.types den fehlenden Eintrag der "woff2" übersehen. Jetzt läuft alles.

    gzip-compression und der cache laufen auch gut. Die Ladezeiten liegen bei

    ca. 100ms (https)

    ca. 70ms (http)


    noch nicht ganz optimal aber zumindest alles aus "meiner Hand". Vielleicht kann man ja noch etwas speed rausholen indem man die Dateien über den RAM (tmpfs) ausliefert. Denke zwar eher weniger aber werde es mal versuchen. 10ms sind halt 10ms xD

  • Scheint zu klappen, lag wohl eher am fast_cgi cache

    Das würde bedeuten, dass die Fonts durch FastCGI durchlaufen, was nicht korrekt wäre. Schließlich müssen Fonts ja nun nicht mit PHP (oder was auch immer) Interpretiert werden. Kontrolliere noch mal Deine location-Blöcke und stelle sicher, dass nur Script Files an fastcgi weitergeleitet werden.

  • Das würde bedeuten, dass die Fonts durch FastCGI durchlaufen, was nicht korrekt wäre. Schließlich müssen Fonts ja nun nicht mit PHP (oder was auch immer) Interpretiert werden. Kontrolliere noch mal Deine location-Blöcke und stelle sicher, dass nur Script Files an fastcgi weitergeleitet werden.

    Danke für die Info! Im Nachhinein betrachtet ergibt das echt keinen Sinn. Vielleicht lags am lokalen cache für die css files. Hatte quasi beide geleert.

    Läuft bei mir auf jeden Fall ohne Probleme, waren wohl nur die Einstellungen in den types nötig.


    Wobei ich mir immer noch unsicher bin, ob ich die ganzen fonts wirklich selber hosten soll, ... mir wäre es lieber, wenn das google und Co auch weiterhin übernehmen würden 🤔

  • Ja, das war die Intention dahinter, hab 3 google fonts und font awesome jetzt "lokal" auf nem eigenen Server.


    Nachteil ist hierbei halt, dass die Fonts bei jedem neuen Seitenaufruf von meinem Server neu gelade werden müssen. Bei google z.B. liegen sie halt im Cache der meisten Browser.


    Denke mal aber aus Datenschutzgründen werde ich darauf verzichten.

  • Datenschutz in der Hinsicht ist finde nicht der oberste Punkte.


    Vielmehr "unabhängig" zu sein.

    Hatten mal nen Kunden der hatte 3 Schriften im Header mal eingebaut.

    Irgendwann war einmal von DTAG und einem anderen Anbieter die Anbindung zu Google deutlich Langsamer als sonst
    und die Seite konnte nicht korrekt gerendert werden.

  • Mir ist gerade aufgefallen, dass es mitunter zu Problemen beim Ausliefern der Fonts kommt, zumindest wenn sie über ne zweite subdomain abgerufen werde:


    Code
    1. Access to Font at 'https://fonts.domain.de/fonts/Open-Sans/open-sans-v15-latin-regular.woff2' from origin 'https://domain.de' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://domain.de' is therefore not allowed access. The response had HTTP status code 404.


    Hier mal meine Settings (nginx)

    mime.types (global):


    headers.conf (global):


    Hier ist X-Frame-Options erst einmal deaktiviert, da es zu Problemen beim inframe mit Matomo kam und Chroem wohl "allowfrom uri" nicht kennt


    Und zu guter Letzt die Teile der vhost config

    Wäre dankbar, wenn hier wer nen Tipp hat, weil das macht mich echt kirre. Welche Sttings verwendest du Tobias992

  • Access to Font at 'https://fonts.domain.de/fonts/Open-Sans/open-sans-v15-latin-regular.woff2' from origin 'https://domain.de' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://domain.de' is therefore not allowed access. The response had HTTP status code 404.

    Doofe Frage, aber: Existiert die Datei? Bei deiner Konfiguration werden halt CORS-Header nur ausgegeben, wenn die Datei auch existiert (was ja auch sinnvoll ist).

    Wenn der OPTIONS-Request schon mit 404 beantwortet wird, wird das GET gar nicht erst aufgeführt und du siehst im Request-Log eines Browsers nicht unbedingt einen Fehler.

  • Doofe Frage, aber: Existiert die Datei? Bei deiner Konfiguration werden halt CORS-Header nur ausgegeben, wenn die Datei auch existiert (was ja auch sinnvoll ist).

    Wenn der OPTIONS-Request schon mit 404 beantwortet wird, wird das GET gar nicht erst aufgeführt und du siehst im Request-Log eines Browsers nicht unbedingt einen Fehler.

    So doof ist die Frage garnet. Werd mir nachher noch mal in Ruhe die Pfadangaben innerhalb der CSS Files angucken oder mal testweise absolute Links verwenden. 😅

  • Hecke29 ... Vielen Dank, Problem saß tatsächlich 20cm vom Notebook entfernt, ... ich hab iwas bei den Pfadangaben verbockt. Hab gerade mal alle relative Pfade durch absolute ersetzt. Läuft nun wieder. Hatte damals meine Fonts nur mit Font awesome ausprobiert, aber nicht mit den google fonts, ...

    Ich schulde dir nen Bier, abzuholen in Berlin - haha