Rewrite für getFont.php

  • App
    WoltLab Suite Core

    Nach Auswertung der Logfiles eines Kunden für die letzten 3 Tage habe ich festgestellt, dass gerade bei hochfrequentierten Seiten ein sehr hohes Aufkommen an Requests gegen die getFont.php erzeugt wird:



    Da es sich um dynamisch erzeugte bzw. ausgelieferte Dateien handelt, kann beispielsweise Cloudflare (was mittlerweile sehr häufig zum Einsatz kommt) auch nichts cachen. Dementsprechend geht jeder ungecachte Request gegen den Webserver und gegen PHP.


    Daher möchte ich vorschlagen, Aufrufe gegen die getFont.php umschreiben zu können.


    Für den Kunden habe ich das Ganze nun entsprechend umgesetzt, sodass an Stelle von /font/getFont.php?font=foo&type=woff?v=1.2.3 ausgeliefert wird: /fonts/foo-1.2.3.woff


    Allerdings musste ich auch den Cache-Control-Header entfernen, weil sich zumindest Cloudflare sonst weigert, die offensichtlich statische Datei zu cachen. Wobei ich sowieso dafür wäre, das über den Webserver zu regeln und nicht über PHP-Header. Aber das ist noch einmal ein anderes Thema.


    In unserem Google-Font-Plugin werde ich zeitnah entsprechende Änderungen vornehmen. Schön wäre halt, wenn es da schon ab Werk eine Lösung gibt.

    • Official Post

    Hallo,

    Allerdings musste ich auch den Cache-Control-Header entfernen, weil sich zumindest Cloudflare sonst weigert, die offensichtlich statische Datei zu cachen.

    ich habe gerade mal drauf geguckt. Das private ist Schuld. Das könnte und sollte problemlos auf public geändert werden können. Möglicherweise reicht das dann auch schon ohne Rewrite?

  • In Kombination mit Cloudflare leider nicht, da auf Basis der Erweiterung gecached wird, nicht auf Basis des Mime-Type. Das einzige, was vielleicht funktioniert, ist eine "Cache Everything"-Regel auf dem font-Verzeichnis. Das habe ich zumindest mit der getFont.php nicht getestet. Dürfte für viele Betreiber bzw. CF-Nutzer aber auch wegfallen, weil die Anzahl der möglichen Page-Rules in der kostenfreien Variante von CF ja doch recht gering ist.

  • Es würde (zumindest mir) an für sich schon reichen, wenn dem StyleCompiler (ab 3.1) ein zusätzliches Event hinzugefügt würde, mit dem man den Content eines Stylesheets vor dem Speichern manipulieren kann. Ich dachte da an sowas:


    Diff
    @@ -127,6 +127,8 @@
                 $variables,
                 $individualScss . (!empty($parameters['scss']) ? "\n" . $parameters['scss'] : ''),
                 function($content) use ($style) {
    +                EventHandler::getInstance()->fireAction($this, 'compileCallback', $content);
    +
                     return "/* stylesheet for '".$style->styleName."', generated on ".gmdate('r')." -- DO NOT EDIT */\n\n" . $content;
                 }
             );


    Das könnte man nicht nur für diesen Zweck hier (in Form eines Plugins) nutzen, sondern sicherlich noch für einige andere Dinge.

    • Official Post

    Folgende Änderungen haben wir diesbezüglich vorgenommen:

    • Version 3.1+: Den Cache-Control-Header auf public umgestellt, um ein Caching in Proxies zu erlauben.
    • Version 5.3+: Bei Installationen mit nur einer Domain (keine Nutzung von mehreren Subdomains, betrifft >99,9% der Installationen) werden Fonts automatisch direkt als statische Datei referenziert. Normales Caching-Verhalten für Fonts in gängigen (Web-)Proxies.
  • Version 5.3+: Bei Installationen mit nur einer Domain (keine Nutzung von mehreren Subdomains, betrifft >99,9% der Installationen) werden Fonts automatisch direkt als statische Datei referenziert. Normales Caching-Verhalten für Fonts in gängigen (Web-)Proxies.


    ;(


    Aber immerhin betrifft das nicht nur mich, sondern auch euch :P

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!