Webhosting 2000 gzip Header (Unity WebGl)

  • Hallo zusammen,


    ich kämpfe schon geraume Zeit damit, dass meine per gzip komprimierten Daten auch entsprechend vom Browser gehandhabt werden. Der content-type wird mir im Response Header korrekt angezeigt.

    Beispiele:

    • v2.framework.js.gz -> Content-type: application/javascript; content-encoding: br (Wieso wird hier brotli statt gzip angewendet? Hier sollte doch gzip stehen, oder?). Lasse ich mir die Datei anzeigen, sehe ich natürlich nur Kauderwelsch, da nicht korrekt dekodiert.
    • v2.data.gz -> Content-type: application/octet-stream; content-encoding steht gar nicht erst im Response Header, dafür "accept-ranges:bytes".


    Meine .htaccess sieht so aus:

    Wenn ich hier ".data.gz" für Testzwecke application/javascript statt /octet-stream zuweise, wird mir diese Änderung im Response Header nicht wiedergespiegelt. Trage ich in der .htaccess Mist ein, bekomme ich aber einen Error und setze ich Umgebungsvariablen, kann ich diese auch über PHP wieder auslesen. Heißt das, dass genau diese *.gz Daten gar nicht vom Apache gehandelt werden, sondern vom nginx? Wie sähe dann ein Workaround aus? Teilweise hatte ich etwas von einer nginx.conf gelesen - wenn ich das richtig verstanden habe, steht mir die im Webhosting Paket nicht zu Verfügung.


    Danke schonmal und viele Grüße

    Steffen

  • So wie es aussieht, musste ich im CCP nur für alle Domains in den Apache & nginx Einstellungen die intelligente Bearbeitung statischer Dateien deaktivieren. Zusätzlich habe ich dort auch nochmal die MIME Typen hinzugefügt - ob das einen Unterschied macht, weiß ich nicht. Ich bin froh, dass es jetzt erstmal funktioniert.

  • Ja, steht ja auch bei den Optionen dabei. Wenn du die intelligente Bearbeitung statischer Dateien deaktivierst, wird alles vom Apache bearbeitet. Was hier für dich wohl sinnvoll ist, aber grundsätzlich sicher nicht optimal ist, weil Kapazitäten des Apache in Anspruch genommen werden, die vielleicht anderswo dringender gebraucht würden. Vielleicht kann man ja via Support die Technik davon begeistern :), diese Einstellungen in die Webserver-Konfiguration von Apache und nginx zu integrieren. Dann würde es ohne .htaccess Einträge funktionieren, die ja nur den Apache beeinflussen und man könnte dann den nginx seinen Job sowohl als Proxy als auch als alleiniger Webserver wieder machen lassen und damit den Apache entlasten. Das sollte ja eigentlich auch im Interesse von netcup sein.

  • Also flott ist der Support ja, hier direkt die Antwort:


  • Dass daran hier und jetzt was geändert wird, darf man wohl fairerweise auch nicht erwarten. Ich weiss zwar nicht, was das genaue Prozedere für Änderungen an den Webservern Apache und nginx im Detail ist. Die Ergänzung einiger Zeilen in den Konfigurationsdatei der Webserver ist auf einem einzelnen Server manuell sicher sehr schnell durchführbar, aber dank der ISO-Zertifizierung hängt an so etwas sehr wahrscheinlich noch ein ganzer Rattenschwanz dran. Inklusive Test des Servers nach der bei der Zertifizierung spezifizierten Testprozedur. Will man es sinnvoll machen, also auf allen existierenden und zukünftigen Servern ausrollen, bedeutet das - ISO sei Dank - dann sicher schon eine ganze Menge Aufwand und kann nicht mal so eben nebenbei in der Mittagspause erledigt werden. Das wird man wohl wegen einer kleinen Verbesserung, die 99% der Kunden wahrscheinlich gar nicht betrifft, nur im Rahmen anderer, sowieso geplanter Änderungen dann miterledigen.


    Gut wäre aber, für netcup meines Erachtens ebenso wie für die betroffenen Kunden, wenn man das seitens netcup schon mal für die nächste passende Gelegenheit vormerken und im Hinterkopf behalten würde. Denn ein betroffener Kunde hat ja nur wenige Möglichkeiten.


    1. Den Workaround über die Einstellungen für Apache und nginx
    2. Auf einen VPS/RS umsteigen
    3. Auf einen managed Server umsteigen
    4. Den Anbieter wechseln

    1.) macht die Geschichte langsamer als sie sein müsste und belastet zusätzlich den Apache mit Dingen, die eigentlich der nginx-Proxy erledigen könnte.

    2.) ist sicher nicht jedermanns Sache, bringt einiges an einmaligem und dauerhaftem Aufwand mit sich, auch wenn man fürs gleiche Geld dann mehr Leistung hat.

    3.) ist nicht ganz billig, wird wegen sowas wahrscheinlich kaum ein Kunde machen.

    4.) ist mit (relativ) wenig einmaligem Aufwand und eventuell etwas höheren Kosten möglich.


    Da wird bei den meisten Kunden die Entscheidung zwischen 1.) und 4.) getroffen werden.