Gzip Komprimierung ausschalten?

[Markus2]

Hallo,

bei mir ist in der php.ini die Komprimierung eingeschaltet (zlib.output_compression = On). Nun habe ich ein einziges Script (Download-Counter) bei welchen ich die Komprimierung nicht verwenden möchte. Gibt es einen Weg dies zur Laufzeit zu tun? Bisher schien es mit ini_set()zu funktionieren. Aber seit dem Update auf 5.3.2 bekomme ich es einfach nicht mehr ausgeschaltet.

Gruß

Markus2

[Edgar Ehritt]

Hallo Markus2,

bei mir ist in der php.ini die Komprimierung eingeschaltet (zlib.output_compression = On). Nun habe ich ein einziges Script (Download-Counter) bei welchen ich die Komprimierung nicht verwenden möchte. Gibt es einen Weg dies zur Laufzeit zu tun? Bisher schien es mit ini_set()zu funktionieren. Aber seit dem Update auf 5.3.2 bekomme ich es einfach nicht mehr ausgeschaltet.

um für Konfigurationsdirektiven lokal andere Werte zu setzen, bleibt (im Wesentlichen) nur der Gebrauch von ini_set(). Bei meinem Test konnte ich Dein beschriebenes Verhalten nicht reproduzieren. Das mag daran liegen, dass Du nicht mitgeteilt hast welches PHP (CGI, FastCGI, SAPI-Modul) Du mit welchem Webserver (Apache, etc.) unter welchen Umständen (voller Zugriff auf alle Konfigurationen/Webspace-Nutzung) verwendest.

Soweit Du mich darüber im dunkeln tappen lässt, kann ich nur anraten, erstmal zu überprüffen, ob tatsächlich PHP für die Kompression verantwortlich ist, oder ob ein anderer Ausgabefilter des Webservers die Kompression durchführt.

Gruß aus Berlin!
eddi

[ChrisB]

Hi,

um für Konfigurationsdirektiven lokal andere Werte zu setzen, bleibt (im Wesentlichen) nur der Gebrauch von ini_set().

Wieso das?

Je nach Art der Einbindung lassen sie sich bspw. auch per .htaccess oder eigener php.ini im Verzeichnis setzen.

Und für manche gilt sogar, dass sie per ini_set gar nicht beeinflussbar sind, wie bspw. register_globals.

MfG ChrisB

[Edgar Ehritt]

Hallo ChrisB,

um für Konfigurationsdirektiven lokal andere Werte zu setzen, bleibt (im Wesentlichen) nur der Gebrauch von ini_set().

Wieso das? Je nach Art der Einbindung lassen sie sich bspw. auch per .htaccess oder eigener php.ini im Verzeichnis setzen.

und welche Lösung der Konfiguration, insbesondere mit Blick auf die benannte Problematik unterschiedlicher Schnittstellen PHPs und der sich daraus Dir offensichtlich gar nicht stellende Frage der Portabilität, ist wohl für den Programmierer interessant; und was meinte ich wohl mit „im Wesentlichen”?

Und für manche gilt sogar, dass sie per ini_set gar nicht beeinflussbar sind, wie bspw. register_globals.

Ohne zu wissen, ob Du .htaccess oder .user.ini (zumal diese oberhalb von DOCUMENT_ROOT liegen müssten) überhaupt nutzen kannst, macht dieser Einwand jetzt wieviel Sinn?

Gruß aus Berlin!
eddi

[ChrisB]

Hi,

und welche Lösung der Konfiguration, insbesondere mit Blick auf die benannte Problematik unterschiedlicher Schnittstellen PHPs

Welche Problematik ergibt sich daraus d.E. explizit bezüglich des Abschaltens einer evtl. durch PHP selber vorgenommenen GZIP-Komprimierung?

und der sich daraus Dir offensichtlich gar nicht stellende Frage der Portabilität, ist wohl für den Programmierer interessant; und was meinte ich wohl mit „im Wesentlichen”?

Portabilität ist also für dich der entscheidenste Faktor?

Dann hast du wohl bspw. die Probleme, die sich aus der konkurrierenden Konfiguration bzgl. Sessions ergeben können, nicht bedacht.

Und für manche gilt sogar, dass sie per ini_set gar nicht beeinflussbar sind, wie bspw. register_globals.

Ohne zu wissen, ob Du .htaccess oder .user.ini (zumal diese oberhalb von DOCUMENT_ROOT liegen müssten)

Nein, müssten sie nicht.

überhaupt nutzen kannst, macht dieser Einwand jetzt wieviel Sinn?

Er zeigt, dass du mit deiner Aussage, dass „(im Wesentlichen) nur der Gebrauch von ini_set()“ bliebe, nicht pauschal recht hast, weil auf Grund dieses Umstandes gar nicht haben kannst :-)

MfG ChrisB

[Edgar Ehritt]

Re:

um für Konfigurationsdirektiven lokal andere Werte zu setzen, bleibt (im Wesentlichen) nur der Gebrauch von ini_set().

|

Wieso das? Je nach Art der Einbindung lassen sie sich bspw. auch per .htaccess oder eigener php.ini im Verzeichnis setzen.

und welche Lösung der Konfiguration, insbesondere mit Blick auf die benannte Problematik unterschiedlicher Schnittstellen PHPs

Welche Problematik ergibt sich daraus d.E. explizit bezüglich des Abschaltens einer evtl. durch PHP selber vorgenommenen GZIP-Komprimierung?

Wie zu lesen war, ging es um eine „Lösung der Konfiguration … mit Blick auf … [die] … Frage der Protabilität, [die] für … den Programmierer interessant [ist]”. Es dreht sich dabei nicht explizit um Kompression sondern um den Gebrauch von ini_set(). Dass Du den Zusammenhang derart verdrehst, verstehe ich nicht. (Weiter unten scheint Dir klar zu sein, was ich geschrieben hatte.)

und der sich daraus Dir offensichtlich gar nicht stellende Frage der Portabilität, ist wohl für den Programmierer interessant; und was meinte ich wohl mit „im Wesentlichen”?

Portabilität ist also für dich der entscheidenste Faktor?

Wenn ich schrieb, dass ini_set() (im Wesentlichen) das Mittels der Wahl zum setzen lokaler Werte von Konfigurationsdirektiven sei, ja!

Dann hast du wohl bspw. die Probleme, die sich aus der konkurrierenden Konfiguration bzgl. Sessions ergeben können, nicht bedacht.

Konkurrierende Konfiguration generell ist ein Problem, was ich nicht angerissen habe. Dazu fehlen mir derzeit vom OP viel zu viel Angaben. Kommt eine Antwort, würde ich ggf. dann auch abhängig von der Konstellation die Konfiguration erfragen. Erst dann sähe ich didaktischen Wert darin, Konkurrenzen auszuschließen.

Und für manche gilt sogar, dass sie per ini_set gar nicht beeinflussbar sind, wie bspw. register_globals.

Ohne zu wissen, ob Du .htaccess oder .user.ini (zumal diese oberhalb von DOCUMENT_ROOT liegen müssten)

Nein, müssten sie nicht.

Stimmt.

überhaupt nutzen kannst, macht dieser Einwand jetzt wieviel Sinn?

Er zeigt, dass du mit deiner Aussage, dass „(im Wesentlichen) nur der Gebrauch von ini_set()“ bliebe, nicht pauschal recht hast, weil auf Grund dieses Umstandes gar nicht haben kannst :-)

1. Hast Du „im Wesentlichen” immer noch nicht in Relation zur Portabilität gesetzt.
2. Gibt es Situationen, wo Du weder .htaccess noch .user.ini nicht nutzen kannst.

Das .user.ini nicht oberhalb von DOCUMENT_ROOT liegen müssen, rüttelt an 2. nicht. Dass 2. die Kernaussage des eingeschobenen Satzes ist, wäre klarer, wenn Du den Satz nicht mittig auseinander gesägt hättest.

Gruß aus Berlin!
eddi

[ChrisB]

Hi,

Wie zu lesen war, ging es um eine „Lösung der Konfiguration … mit Blick auf … [die] … Frage der Protabilität, [die] für … den Programmierer interessant [ist]”.

Dir vielleicht - dem Ersteller dieses Threads nicht.

Er zeigt, dass du mit deiner Aussage, dass „(im Wesentlichen) nur der Gebrauch von ini_set()“ bliebe, nicht pauschal recht hast, weil auf Grund dieses Umstandes gar nicht haben kannst :-)

1. Hast Du „im Wesentlichen” immer noch nicht in Relation zur Portabilität gesetzt.

Doch.
Im Wesentlichen taugt ini_set per Definition nicht zum Setzen mancher Einstellungen, egal wie portabel man es gern hätte.

2. Gibt es Situationen, wo Du weder .htaccess noch .user.ini nicht nutzen kannst.

Hm, d.h. wo ich also beide gleichzeitig benutzen muss? :-)

Das .user.ini nicht oberhalb von DOCUMENT_ROOT liegen müssen, rüttelt an 2. nicht. Dass 2. die Kernaussage des eingeschobenen Satzes ist, wäre klarer, wenn Du den Satz nicht mittig auseinander gesägt hättest.

Es gibt auch Situationen, in denen du ini_set nicht nutzen kannst.

MfG ChrisB

[Edgar Ehritt]

Re:

Wie zu lesen war, ging es um eine „Lösung der Konfiguration … mit Blick auf … [die] … Frage der Protabilität, [die] für … den Programmierer interessant [ist]”.

Dir vielleicht - dem Ersteller dieses Threads nicht.

Ich bin mir sicher, dass er fragen kann, wenn er etwas nicht versteht.

Er zeigt, dass du mit deiner Aussage, dass „(im Wesentlichen) nur der Gebrauch von ini_set()“ bliebe, nicht pauschal recht hast, weil auf Grund dieses Umstandes gar nicht haben kannst :-)

1. Hast Du „im Wesentlichen” immer noch nicht in Relation zur Portabilität gesetzt.

Doch.
Im Wesentlichen taugt ini_set per Definition nicht zum Setzen mancher Einstellungen, egal wie portabel man es gern hätte.

Dem stimme ich ja sogar zu. Wenn es um Direktiven geht, die nicht mit ini_set() manipuliert werden können, wird ein kluger Programmierer mit ini_get() Fallunterscheidungen im Steuerfluss einbauen, da er weiß, dass er sich nicht darauf verlassen kann, die Möglichkeit externer Konfigurationsdateien zu haben.

2. Gibt es Situationen, wo Du weder .htaccess noch .user.ini nicht nutzen kannst.

Hm, d.h. wo ich also beide gleichzeitig benutzen muss? :-)

Ab Zeile 193 der php.ini-production aus den aktuelle sourcen PHP 5.3.2 heißt es:

;;;;;;;;;;;;;;;;;;;;
   ; php.ini Options ;
   ;;;;;;;;;;;;;;;;;;;;
   ; Name for user-defined php.ini (.htaccess) files. Default is ".user.ini"
   ;user_ini.filename = ".user.ini"

; To disable this feature set this option to empty value
   ;user_ini.filename =

Damit haben wir bereits den ersten konfigurativen Vorfall, wo .user.ini gar nicht genutzt werden kann. Und ich glaube, dass ich mir das Repetieren allein für den Apachen von Direktive AccessFileName und  AllowOverride ersparen kann. Jedoch sollte Dir mal langsam klar werden, dass andere Webserver das Konzept verzeichnisweiter Konfigurationsdateien gar nicht kennen.

Das .user.ini nicht oberhalb von DOCUMENT_ROOT liegen müssen, rüttelt an 2. nicht. Dass 2. die Kernaussage des eingeschobenen Satzes ist, wäre klarer, wenn Du den Satz nicht mittig auseinander gesägt hättest.

Es gibt auch Situationen, in denen du ini_set nicht nutzen kannst.

Richtig. Es ist durchaus denkbar, das jemand ini_set() per disable_functions sperrt; nur betrachte mal die Wahrscheinlichkeit dieser Option gegen das recht sinnvolle Unterbinden von .user.ini-Konfigurationen!

Gruß aus Berlin!
eddi

[ChrisB]

Hi,

Dem stimme ich ja sogar zu. Wenn es um Direktiven geht, die nicht mit ini_set() manipuliert werden können, wird ein kluger Programmierer mit ini_get() Fallunterscheidungen im Steuerfluss einbauen, da er weiß, dass er sich nicht darauf verlassen kann, die Möglichkeit externer Konfigurationsdateien zu haben.

Oder sich diesen zusätzlichen Aufwand sparen, und eine gewisse Konfiguration einfach als Systemvoraussetzung festlegen.

Damit haben wir bereits den ersten konfigurativen Vorfall, wo .user.ini gar nicht genutzt werden kann. Und ich glaube, dass ich mir das Repetieren allein für den Apachen von Direktive AccessFileName und  AllowOverride ersparen kann. Jedoch sollte Dir mal langsam klar werden, dass andere Webserver das Konzept verzeichnisweiter Konfigurationsdateien gar nicht kennen.

Ist egal, ob der Webserver das kennt - wenn PHP auf eigene Faust nach einer lokalen Konfigurationsdatei sucht.

Es gibt auch Situationen, in denen du ini_set nicht nutzen kannst.

Richtig. Es ist durchaus denkbar, das jemand ini_set() per disable_functions sperrt; nur betrachte mal die Wahrscheinlichkeit dieser Option gegen das recht sinnvolle Unterbinden von .user.ini-Konfigurationen!

Warum sollte das eine unwahrscheinlicher sein als das andere?

Wenn mir als administrativem Verantwortlichen für eine PHP-Installation die Möglichkeit, dass Nutzer gewisse Konfigurations-Optionen überschreiben, nicht gefällt, dann muss ich dafür sorge tragen, dass dies auf beiden Wegen - per ini_set, oder per verzeichnislokaler Konfigurationsdatei - unterbunden ist. (Das ist kein schwarz-weisses Ja oder Nein, sondern kann für einzelne Optionen durchaus unterschiedlich ausfallen.)
Wenn ich aber entschieden habe, bestimmte Optionen durch den Nutzer überschreiben zu lassen - warum sollte ich das dann nur auf dem einen Wege zulassen, den anderen aber untersagen?

MfG ChrisB

[Edgar Ehritt]

Re:

Dem stimme ich ja sogar zu. Wenn es um Direktiven geht, die nicht mit ini_set() manipuliert werden können, wird ein kluger Programmierer mit ini_get() Fallunterscheidungen im Steuerfluss einbauen, da er weiß, dass er sich nicht darauf verlassen kann, die Möglichkeit externer Konfigurationsdateien zu haben.

Oder sich diesen zusätzlichen Aufwand sparen, und eine gewisse Konfiguration einfach als Systemvoraussetzung festlegen.

Du siehst die Zwickmühle der Portabilität also immer noch nicht…

Damit haben wir bereits den ersten konfigurativen Vorfall, wo .user.ini gar nicht genutzt werden kann. Und ich glaube, dass ich mir das Repetieren allein für den Apachen von Direktive AccessFileName und  AllowOverride ersparen kann. Jedoch sollte Dir mal langsam klar werden, dass andere Webserver das Konzept verzeichnisweiter Konfigurationsdateien gar nicht kennen.

Ist egal, ob der Webserver das kennt - wenn PHP auf eigene Faust nach einer lokalen Konfigurationsdatei sucht.

Warum dringt bei Dir nicht durch, dass PHP als Servermodul keine .user.ini interpretiert? PHP kann als Modul folgender Server gebaut werden:

AOLserver, Apache, Caudium, Continuity, litespeed,  phttpd, Pi3Web, Roxen, thttpd, TUX, WebJames, Zeus

So, und nun erzähle mir mal bitte, wie Du bei einem von denen .user.ini-s nutzen willst!

Es gibt auch Situationen, in denen du ini_set nicht nutzen kannst.

Richtig. Es ist durchaus denkbar, das jemand ini_set() per disable_functions sperrt; nur betrachte mal die Wahrscheinlichkeit dieser Option gegen das recht sinnvolle Unterbinden von .user.ini-Konfigurationen!

Warum sollte das eine unwahrscheinlicher sein als das andere?

Wenn mir als administrativem Verantwortlichen für eine PHP-Installation die Möglichkeit, dass Nutzer gewisse Konfigurations-Optionen überschreiben, nicht gefällt, dann muss ich dafür sorge tragen, dass dies auf beiden Wegen - per ini_set, oder per verzeichnislokaler Konfigurationsdatei - unterbunden ist. (Das ist kein schwarz-weisses Ja oder Nein, sondern kann für einzelne Optionen durchaus unterschiedlich ausfallen.)

Da portable Konfiguration ausschließlich mittels ini_set() bewerkstelligt werden kann, würde ein Sperren dieser Funktion Deine Webspace-Nutzer »nicht sehr glücklich« machen. Demgegenüber steht aber der Fakt, dass unter vielen Umständen .user.ini-Konfigurationen nicht möglich sind, ohne dass hier konfigurativ eingegriffen werden muss. Du setzt bei Deiner Wahrscheinlichkeitsbewertung eine Methode, die immer verfügbar ist und explizit gesperrt werden muss, mit einer anderen Methode gleich, die unter vielen Konstellationen potenziell überhaupt nicht verfügbar ist.

Du schreibst etwas von schwarz-weiß, abber alleine da fängt es doch schon an, dass Du dann zwingend vor einem Apachen sitzen musst. Kein anderer Server lässt Konfigurationen per php_admin_(flag|value) zu. (Ja, Schwarz hast Du nämlich von vornherein ganz selbstverständlich unter den Teppich gekehrt.) Darüber hinaus muss es dann auch noch ein Modul sein, weil bei (Fast-)CGI hast Du nur Schwarz oder Weiß. Du kannst dort nicht einige Direktiven sperren - nur komplett ini_set().

Wenn ich aber entschieden habe, bestimmte Optionen durch den Nutzer überschreiben zu lassen - warum sollte ich das dann nur auf dem einen Wege zulassen, den anderen aber untersagen?

Du beschränkst Deine Betrachtung nur auf einen einzigen Spezialfall: Apache mit PHP-Servermodul.

Gruß aus Berlin!
eddi

[ChrisB]

Hi,

Oder sich diesen zusätzlichen Aufwand sparen, und eine gewisse Konfiguration einfach als Systemvoraussetzung festlegen.

Du siehst die Zwickmühle der Portabilität also immer noch nicht…

Doch - aber ich bewerte sie nicht so hoch (/über), wie du.

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.

Da portable Konfiguration ausschließlich mittels ini_set() bewerkstelligt werden kann, würde ein Sperren dieser Funktion Deine Webspace-Nutzer »nicht sehr glücklich« machen.

Sperren der anderen Möglichkeiten macht mich auch nicht glücklich.

Du beschränkst Deine Betrachtung nur auf einen einzigen Spezialfall: Apache mit PHP-Servermodul.

Das ist der absolute Normalfall.
Alles andere, was du anführst, sind die Spezialfälle.

MfG ChrisB

[Edgar Ehritt]

Re:

Oder sich diesen zusätzlichen Aufwand sparen, und eine gewisse Konfiguration einfach als Systemvoraussetzung festlegen.

Du siehst die Zwickmühle der Portabilität also immer noch nicht…

Doch - aber ich bewerte sie nicht so hoch (/über), wie du.

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! 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. 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. 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.

Da portable Konfiguration ausschließlich mittels ini_set() bewerkstelligt werden kann, würde ein Sperren dieser Funktion Deine Webspace-Nutzer »nicht sehr glücklich« machen.

Sperren der anderen Möglichkeiten macht mich auch nicht glücklich.

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. (Ich führe es »gerne« auch nochmals an: Auf der anderen Seite, bei gesperrter Funktion ini_set(), kreierst Du Portabilitätsproblem.)

Du beschränkst Deine Betrachtung nur auf einen einzigen Spezialfall: Apache mit PHP-Servermodul.

Das ist der absolute Normalfall.
Alles andere, was du anführst, sind die Spezialfälle.

Naja, v. m. a. lasse ich das als Gedankenspiel mal so umgekrempelt zu. 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.

(Draußen ist eh Mistwetter, mal gucken, was nu’ wieder zurückkommt…)

Gruß aus Berlin!
eddi

[ChrisB]

Hi,

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.

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.

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?

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?

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?

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.

MfG ChrisB

[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

[ChrisB]

Hi,

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.

Doch, bspw. php_admin_value/php_admin_flag.
(Ja, zugegebenermaßen wieder nur das Apache-Modul betreffend.)

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.

Das habe ich nicht bestritten.

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.

Ja, und?
Wenn du alles wunderbar „portabel“ halten willst, dann nimm halt ini_set.

Es ist nur meiner Meinung nach nicht der allein selig machende Weg.

MfG ChrisB

[Edgar Ehritt]

Re:

Es ist nur meiner Meinung nach nicht der allein selig machende Weg.

Doch, ist er. Der dies untermauernden Argumentation hast Du bis jetzt auch nichts entgegengehalten.

Gruß aus Berlin!
eddi

[ChrisB]

Hi,

Es ist nur meiner Meinung nach nicht der allein selig machende Weg.

Doch, ist er.

Amen.

Der dies untermauernden Argumentation hast Du bis jetzt auch nichts entgegengehalten.

Doch, aber das hat das schwarze Loch zwischen deinen Ohren einfach geschluckt, ohne es zu verarbeiten.

MfG ChrisB

[Edgar Ehritt]

Re:

Doch, ist er.

Amen.

Das war kein „OI” von mir!

Der dies untermauernden Argumentation hast Du bis jetzt auch nichts entgegengehalten.

Doch, aber das hat das schwarze Loch zwischen deinen Ohren einfach geschluckt, ohne es zu verarbeiten.

Na, machst Du mal wieder eins auf Christiane B. nur weil Dein enger Tellerrand Deines „Normalfalls” nichts mit der Realität zu tun hat? :-P

Gruß aus Berlin!
eddi