Gzip Komprimierung ausschalten?

[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