Gzip Komprimierung ausschalten?

[Edgar Ehritt]

Re:

Von einem vernünftigen Hoster erwarte ich, dass er mich nicht sicherheits- oder performance-kritische Optionen selber konfigurieren lässt. Und zwar nicht nur per ini_set.

Erkläre mir also, warum ini_set() solch wichtige „sicherheits- oder performance-kritische Optionen” zukommt wie bspw. memory_limit!

Erkläre mir bitte deine Frage - verständlich.

Das memory_limit möchte ich vielleicht nicht jeden Nutzer selber bestimmen lassen. Ob per ini_set oder anderweitig, ist mir egal.

Meine obige Aussage betraf nur die Optionen, die ich als User kontrollieren darf. Das möchte ich, wenn möglich, gerne zentraler machen können, als mit einer Reihe von ini_set-Aufrufen in jedem Script; also bspw. per .htaccess oder eigener php.ini im Verzeichnis.

Naja, wo stehen wir den jetzt gerade:

Es geht um die Konfiguration PHPs. Dabei gibt es zum einen mehrere Konzepte (.htaccess, .user.ini, [ältere Versionen noch mit php.ini in den Verzeichnissen,] zentrale php.ini und ini_set()), die bis auf die zentrale php.ini (INI_SYSTEM) und ini_set() nicht portabel sind. Das ist die Ausgangsbasis der Betrachtung, die Du sicher jetzt genauso siehst.

Nun gibt es „Wertungen” innerhalb der Zuteilung wer was ändern darf. Dafür kennt PHP die Stufen php.ini-only, PHP_INI_SYSTEM, PHP_INI_PERDIR, PHP_INI_USER und PHP_INI_ALL. Es gibt aber keine generell wirksame Beschränkung derart, dass eine höherwertige Konfiguration(-sdatei) eine niedere (z. B. ini_set()) gegenstandslos werden lassen könnte.

All das muss ich als wirklich beschissen gestricktes Konfigurationskonzept PHPs bezeichnen.

Es ist richtig, es gibt eine einsame Ausnahme quasi eines Kastensystems an Konfigurationen, auf den Du Dich ja vehement berufst: Apache mit PHP-Servermodul. Apache ist aber nur zu gut 55% im Einsatz (Quelle http://news.netcraft.com/). PHP wird nach meinem Empfinden vorwiegend via CGI betrieben (Quelle: Bach). Es bleibt ein mutmaßliches Dritte an Konstellationen überhaupt übrig, wo Deine Erwartungen an einen „vernünftigen Hoster” überhaupt ansetzen können, dass er „sicherheits- oder performance-kritische Optionen” konfigurativ dem Endnutzer entreißt. Alle anderen Hoster, und das sind zweidrittel, müssten in die sourcen PHPs eingreifen. Das war mein Ausgangspunkt, als ich Dir eine Erklärung, warum ini_set() solch „sicherheits- oder performance-kritische Optionen” zukommt, abverlangte. Ich halte das einmal mehr für einen elementaren Handwerksfehler der developer PHPs.

D. h., dass Du mit Deinen Erwartungen bei mir durchaus offene Türen einrennst. Die Realität aber beschäftigt sich nicht mit den Fehlern. Sie nimmt sie als gegeben an. Das ist Fatalismus, den ein das Leben nunmal lehrt; und aus dem heraus stellt sich nur noch die Frage, ob es opportun ist Portabilität zu opfern. Auf die Einsicht zielte meine Frage wegen des missratenen Konfigurationskonzepts (Beispiel memory_limit), die Dir unverständliche ist.

Du argumentierst mit dem äußerst beschissen gestrickten Konfigurationskonzept PHPs. Dabei erwartest Du von einem vernünftigen Hoster also nicht mehr und nicht weniger, alsdass er vorm Kompilieren eine andere Wertung der ini-Direktiven in den sourcen vornimmt, als dies default PHP macht.

Nein, erwarte ich nicht. Ich erwarte, dass du simple Aussagen verstehst - und damit offenbar zu viel.

Ja, und ich erwarte, dass Du die Realität mal wahrnimmst. Zu der passen nämlich keiner Deiner simplen Aussagen. Wie oben an der Statistik zu sehen ist, kann Dein Normalfall (Apache mit PHP-Servermodul), der Grundlage Diener Aussagen ist, gar keine 50% erreichen. Dein Normalfall ist Splitter unter vielen Konstellationen.
Ich gebe zu, es ist komplex, aber ich glaube an Dich. Du wirst es verstehen.

Das hat zwar dann den Effekt, dass Du u. a. nicht mehr an memory_limit heran kämst, jedoch zum Preis der Portabilität, die Du auf dem Altar der Sicherheit opfern musst.

Du willst mich missverstehen, oder?

Na dan präsentiere doch mal Deine Alternative! Ich sehe sie beim besten Wille nicht, und ich habe Dir bisher unerhört viele Zugeständnisse gemacht, die selbst dann noch Gegenargument Deiner Sicht waren.

Dein Wunsch an vernünftige Hoster in allen Ehren blendest Du bei diesen Phantastereien die Wirkung einer uniformen Schnittstelle auch; und das wo Du in anderen Forumsthemengebieten berechtigt auf Standards drängst.

Konfiguration per .htaccess oder php.ini ist doch reichlich uniform?

Portable Konfiguration aus Sicht des Programmierers ist ausschließlich mittels ini_set() möglich. Wenn Du nicht verstehen willst oder kannst, dass .htaccess und php.ini oder .user.ini nicht als selbstverständlich gegeben sind, ist diese UnterHaltung hier zwecklos. Du solltest mal langsam auf die Gegenargumentation eingehen, statt sie zu ignorieren und am nächsten Tag so weiter zu diskutieren, als sei Dein Betrachtungswinkel unumstößlich richtig. Lies bitte den gesamten Thread erneut!

Das ist aber, wie ich es oben bereits andeutete, grundsätzlich nicht der Punkt. Sperrt man Konfigurationen durch .user.ini oder .htaccess, kommt ini_set() per default immer noch ein ganzes Arsenal „sicherheits- oder performance-kritische[r] Optionen” zu.

Es geht mir nicht darum, etwas auf dem einen Wege zu verbieten, und auf dem anderen zu erlauben.
Sondern schlicht und einfach darum, die erlaubten Optionen auf beiden Wegen konfigurierbar zu machen. Was ist daran so schwer zu verstehen?

VERDAMM’ MICH NOCH MAL!

Wie ich Dir gestern schrieb, gibt es Konstellationen, dass weder .htaccess noch .user.ini zur Verfügung stehen.
Wie ich Dir heute morgen schrieb, gibt es die Konstellation, dass weder .htaccess noch .user.ini zur Verfügung stehen.

Nicht zuletzt deswegen ist der Gebrauch von ini_set() aus Sicht eines Programmierers der _einzig_ portable Weg der Konfiguration. Daher war Deine Wahrscheinlichkeitsbetrachtung, dass ini_set() genauso deaktiviert sein könnte, wie .user.ini nicht zur Verfügung stünde, realitätsfern.

Dann aber muss ich Dir mitteilen, dass die Großen, wie  1&1 und strato, PHP immer noch via CGI betreiben, auch wenn sie, den Apachen nutzen. Das bedeutet letztendlich, dass Du selbst dann, wenn Du mir angeführte Spezialfälle vorhältst, keine Konfiguration erwarten kannst, die sich mittels .htaccess realisieren ließe.

Nein, aber per .user.ini, sofern das freigegeben ist.

Und wenn es nicht freigegeben ist? Guten Morgen!

Gruß aus Berlin!
eddi