nicht angemeldet
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