Contenido und gzip-Komprimierung unter Apache

[ConTester]

Die Herausforderung ist Contenido dazu zu bringen PHP-Dateien gzip-komprimiert auszuliefern. Ohne Contenido praktiziere ich dies schon länger indem ich PHP-Dateien von einem Apache mit dem Modul mod_deflate und gzip-Komprimierung ausliefern lasse. Dafür reicht in einer PHP-Datei ganz oben der Eintrag:

Code: Alles auswählen

<?php
ob_start('ob_gzhandler');

Im Header steht dann (für die Erfolgskontrolle):

Code: Alles auswählen

Content-Encoding	gzip
Vary	Accept-Encoding

Kann mir bitte jemand erläutern wie man Contenido (Version 4.8.12) dazu bringt ebenfalls gzip-komprimiert auszuliefern? Die Headermanipulation durch Contenido ist für mich eine "Black Box". Habe ich dazu eine Dokumentation übersehen? Besten Dank im Voraus!

[xmurrix]

Hallo,

du kannst in der front_content.php die Zeile "982" von

Code: Alles auswählen

                ob_start();

in

Code: Alles auswählen

                ob_start("ob_gzhandler");

ändern.

Leider ist das nicht konfigurierbar. Eine einfache Konfiguration der zu versendenden HTTP-Header sollte konfigurierbar sein, wäre ein wünschenswertes Feature.

Grüße
xmurrix

[Oldperl]

Hallo,

finde ich eine gute Idee, ich verschieb das mal nach Feature Requests.
Ich könnte mir sowas gut vorstellen und es würde mich freuen hier Vorschläge dazu zu lesen.

Gruß aus Franken

Ortwin

[Dodger77]

Ich habe mal kurz ein Plugin gebastelt, mit dem sich das für die gesamte Installation oder auch für einzelne Mandanten aktivieren lässt:

http://forum.contenido.org/viewtopic.php?f=66&t=30111

[ConTester]

xmurrix Danke für den Tipp, aber so gibt es stets einen Content-Encoding-Fehler (Firefox: "Die Webseite, die Sie öffnen möchten, kann nicht angezeigt werden, da sie eine ungültige oder unbekannte Form der Kompression verwendet."). Habe den lokalen Cache und die Tabelle con_code geleert, verschiedene Browser verwendet, die Seite wird über foo/cms/front_content.php?idart=12 aufgerufen (ohne Rewrite oder ähnliches) und der Fehler ist reproduzierbar.

Wie eingangs bereits geschrieben funktioniert auf dem selben Webspace die gzip-Komprimierung bei PHP-Dateien ohne Contenido einwandfrei. Serverfehler schliesse ich somit aus. Das kann meiner Einschätzung nach nur an der Headermanipulation von Contenido liegen.

*schaut fragend in die Community* Funktioniert das denn bei einem von Euch?

[xmurrix]

Hallo Ortwin,

habe mir allgemein zum Setzen von HTTP-Header ein paar Gedanken gemacht.

Die einfachste Lösung wäre, eine neue Konfiguration zu definieren, die dann eingreift.
Kann mir vorstellen, eine neue Konfoguration in contenido/includes/config.misc.php zu definieren:

Code: Alles auswählen

// per default keine callbackfunktion für den puffer
$cfg['frontend']['ob_callback'] = '';

Dies kann man dann im Mandatenverzeichnis in der config.local.php für den Mandanten konfigurieren:

Code: Alles auswählen

// gzip komprimierung für den puffer
$cfg['frontend']['ob_callback'] = 'ob_gzhandler';

// oder eigene funktion für den puffer
$cfg['frontend']['ob_callback'] = 'my_ob_callback';

Das müsste dann in der front_content.php entsprechend angepasst werden.

Wenn wir schon bei dem Thema HTTP-Header sind:
Es gab letztens ein Thema (http://forum.contenido.org/viewtopic.php?f=62&t=30099), wegen dem in der Session-Klasse gesetzten ETag.

Vielleicht sollte man das Setzen der Header grudsätzlich überdenken. Eine granulare Steuerung der zu setzenden HTTP-Header wäre meiner Meinung nach angebracht.

Dafür bräuchte man zum einen eine Möglichkeit, irgendwo solche HTTP-Header zu definieren, und ein Response-Objekt, das sich um die Ausgabe der Header kümmert.

Cool wäre es, wenn man solche Sachen an bestimmten Stellen konfigurieren könnte. Ich denke da z. B. an Kategorien oder Seiten.

Man konfiguriert die HTTP-Header Ausgabe in einer Kategorie, dies erbt sich auf alle Unterkategorien und an alle darin enthaltenen Seiten. Man kann da sogar viel weiter gehen, und dem User weitaus mehr Steuerungsmöglichkeiten anbieten, Steuerung des Caches für Kategorien/Artikel, das Hinzufügen von zusätzlichen Metatags, die Möglichkeit, bestimmte zusätzliche Tags im head-Bereich auszugeben, wie z. B. das Einbinden von JavaScript-/CSS-Files. Wenn man für jedes einzelne Feature eigene Formularfelder anbieten, wird die Oberfläche mit vielen Controls zugemüllt und der User hat viel zum Klicken.

Wenn man dafür eine Textarea bereitstellt, so wie die Eingabe der Modulcodes, könnten solche Einstellungen in Kategorien oder Artikel definiert werden. Dann sind wir aber an dem Punkt, wo man sich überlegen sollte, wie man das zur Verfügung stellt. Erlaubt man dem User, für solche Konfigurationen normalen PHP-Code anzugeben, ist die Gefahr groß, dass da viel schief geht.

Will man das Risiko von Fehlern, die durchaus verherende Folgen haben können, minimieren, wäre alternativ eine eigene Scriptingsprache denkbar. Dies ist aber auch nicht so ideal, weil man sich da wieder irgendeine Syntax aneignen muss. Vielleicht ist hier YAML Ain’t Markup Language eine mögliche Alternative. Die Syntax ist nicht kompliziert, das kann sich jeder schnell aneignen. Eingegebener Markup lässt sich mit Parsern in PHP-Code umwandeln, ist der Inhalt Fehlerhaft, kommt auch kein Fehlerhafter PHP-Code raus. Damit hätte man die Möglichkeit, den Usern ein Konfigurationswerkzeug zur Verfügung zu stellen.

Der User gibt folgenden Markup ein:

Code: Alles auswählen

http-header: 
  - value: 'Cache-Control: no-cache, must-revalidate'
  - value: 'Expires: Sat, 26 Jul 1997 05:00:00 GMT'
  - value: 'Content-Type: text/html'

Der YAML Parser generiert daraus folgenden PHP-Code

Code: Alles auswählen

$arr['http-header'][0]['value'] = 'Cache-Control: no-cache, must-revalidate';
$arr['http-header'][1]['value'] = 'Expires: Sat, 26 Jul 1997 05:00:00 GMT';
$arr['http-header'][2]['value'] = 'Content-Type: text/html';

Danach ist es eine leichte Aufgabe, aus der Konfiguration die HTTP-Header zu setzen oder jede andere Art der Konfigurationen entsprechend zu verarbeiten.

Gruß
Murat

[xmurrix]

...so gibt es stets einen Content-Encoding-Fehler (Firefox: "Die Webseite, die Sie öffnen möchten, kann nicht angezeigt werden, da sie eine ungültige oder unbekannte Form der Kompression verwendet.")...

Dann musst du das wohl an den Anfang der front_content.php einbauen, ganz weit unten ist es vermutlich zu spät dafür.

Oder du verwendest gleich das Plugin von Dodger77, ist eine sehr gute Lösung.

Gruß
xmurrix

[ConTester]

Mit dem Plugin funktioniert es, großartig, besten Dank!

[Oldperl]

Hallo Murat,

grundsätzlich ist dein Ansatz ok, ich denke aber nicht, das man es zu detailliert einstellen können sollte. Auch bin ich erst mal grundsätzlich gegen Einstellungen in der DB. Hier sollte man immer prüfen wie oft diese Einstellung und von wem sie geändert wird. Daraus resultierend wäre zu entscheiden ob diese Einstellung nicht resourcenschonender und sicherheitrelevanter in ein config-Array (Datei) geschrieben wird.

Ich könnte mir in diesem Fall recht gut eine mandantenabhängige config-Variable ala $cfg['header'][IDCLIENT][WERT] vorstellen, und entsprechend eine $cfg['buffer']....
Ob man diese noch per Systemeinstellung überschreibbar macht ist eine andere Sache.

Soweit mal kurz meine Gedanken dazu. Ich denke wir sollten bei Contenido wieder zum Grundprinzip zurück, "mit so wenig Aufwand wie nötig, das bestmögliche Ergebnis", und das vor Allem in Bezug auf Resourcen und Usebility. Das gäbe Contenido IMO einen wirklich gravierenden Vorsprung vor frameworkdriven CM-Systemen.
Ich bin mir nicht sicher ob ein noch mehr von Einstellmöglichkeiten wirklich besser wäre. Wenn man z.B. die heutigen Handys schaut, was die alles können, und welcher geringe Prozentsatz davon nur genutzt wird, hmmm...

Gruß aus Franken

Ortwin

[kummer]

Ich denke wir sollten bei Contenido wieder zum Grundprinzip zurück, "mit so wenig Aufwand wie nötig, das bestmögliche Ergebnis", und das vor Allem in Bezug auf Resourcen und Usebility. Das gäbe Contenido IMO einen wirklich gravierenden Vorsprung vor frameworkdriven CM-Systemen.

ich sehe jetzt keinen zusammenhang zwischen ressourcen, usability und einem framework, mindestens nicht so, wie du das beschreibst. vielleicht kannst du das ja näher erläutern. weil contenido ist jetzt nicht wirklich dafür berühmt, ressourcenschonend zu sein. und ohne wirklich etwas aufwand zu treiben, wird es einen gravierenden vorsprung geben, in der tat. aber ich fürchte, mit umgekehrten vorzeichen.

[Oldperl]

vielleicht kannst du das ja näher erläutern.

warum sollte ich? gruß aus franken ortwin

[kummer]

warum sollte ich?

weil du für dich immer in anspruch nimmst, der freundlichste unter der sonne zu sein und sich hier die gelegenheit bietet, mindestens den gegenbeweis zu widerlegen. und vielleicht kannst du uns unwissenden ein wenig den weg erhellen.

[Oldperl]

@kummer:
Ich habe keine Ansprüche und muss auch Niemandem, schon gar nicht dir, irgendetwas beweisen.
Und ob DU unwissend bist wage ich nicht zu beurteilen, wobei ich nicht verstehe, warum du in der 3. Person sprichst, dachte das macht man nur am österreichischen Königshaus so.
Tja und für das Licht bin ich hier auch nicht zuständig, könntest du dich da bitte an dein zuständiges E-Werk wenden?

So, und damit reichts für mich mit Offtopic. Falls noch Jemand etwas zu sagen hat, schicke er es bitte per PN oder Email.

Gruß Ortwin

[kummer]

Ich habe keine Ansprüche und muss auch Niemandem, schon gar nicht dir, irgendetwas beweisen.

müssen musst du nicht, aber dürfen darfst du alleweil.

[kummer]

aber so gibt es stets einen Content-Encoding-Fehler (Firefox: "Die Webseite, die Sie öffnen möchten, kann nicht angezeigt werden, da sie eine ungültige oder unbekannte Form der Kompression verwendet."). Habe den lokalen Cache und die Tabelle con_code geleert, verschiedene Browser verwendet, die Seite wird über foo/cms/front_content.php?idart=12 aufgerufen (ohne Rewrite oder ähnliches) und der Fehler ist reproduzierbar.

damit der spezifizierte callback (gz_handler) von ob_start funktionieren kann, darf zuvor keine ausgabe vorgenommen worden sein. an der bezeichneten stelle wird ob_start auch nicht zur ausgabepufferung der ganzen seite verwendet, sondern nur, um die ausgabe der ausführung der gespeicherten con_code ran zu kommen. es wäre günstig, wenn ganz zu beginn auch bereits ein ob_start vorgenommen werden würde. damit könnte ein beliebiger callback erfolgen und es wäre innerhalb von modulen möglich, den code zu verwerfen und ggf. eigene header zu senden.

das wurde auch schon mehrfach diskutiert. mir ist allerdings nicht bekannt, warum es nie integriert wurde. der früher eingebrachte einwand, dass es die leistung negativ beeinflussen würde, trifft nicht zu. zwar wird dadurch die ausgabe etwas verzögert (bis ob_end aufgerufen oder skript gestoppt wird). durch die art der ausführung des zusammengestellten codes hat man das problem allerdings ohnehin.

mit einem plugin lässt sich das zwar ganz offensichtlich auch lösen. die integration eines plugins vergrössert jedoch den gesamtumfang des ausgeführten und includierten codes, was sich zwingend negativ auf die leistung auswirken muss. dem stehen zwei zeilen gegenüber für den start und das beenden der ausgabepufferung.