Glück gehabt!

[Rolf B]

Hallo Raketenwilli,

kann man vieles ... machen

Aber sollte man das - außer zum akademischen Lustgewinn? Als Privatmensch deploye ich eine Webanwendung ja normalerweise auf genau einen Typ Server und weiß deshalb, in welche Konfiguration ich was eintragen muss.

Wenn ich eine kommerzielle Anwendung erstelle, die auf vielen unterschiedlichen Servertypen laufen können soll, dann kann ich

(a) die Configs für diese Typen mitliefern (b) eine Anleitung erstellen, die beschreibt, welche Funktionen der Server beistellen muss und vom Admin erwarten, dass er das konfiguriert.

Gerne auch beides. Als kommerzieller Anbieter muss ich meine Anwendung ja auf den von mir als "unterstützt" gelisteten Webservern getestet haben und kann in dem Zusammenhang Muster-Konfigurationen erstellen. Und für die Anwender, denen die Musterkonfigurationen nicht reichen, muss ich die Konfigurationsmöglichkeiten eh dokumentieren.

Eine Lösung, die die nativen Möglichkeiten des Servers ignoriert und sie statt dessen auf andere Weise nachbaut, kann im produktiven Einsatz nur schlechter sein. Sie ist umständlicher, fehleranfälliger und sehr wahrscheinlich auch weniger performant. Der einzige Grund, weshalb man so etwas tun sollte, wäre ein Server, den ich nicht wie erforderlich unter Kontrolle habe und die nativen Möglichkeiten nicht konfigurieren darf.

Oder ein Server, der die nativen Möglichkeiten schlicht nicht bietet. Gibt's sicher auch. Aber sollte man deshalb eine Anwendung ausgehend vom dümmsten aller möglichen Fälle bauen?

Bei einer "historischen" Anwendung mag das anders sein. Vielleicht hat man mit einem Server begonnen, dem es an solchen Funktionen gebrach, und schleppt deswegen handgemachte Redirects und ähnliches mit. Das wäre dann aber ein Sanierungsfall. Bei neuen Anwendungen sollte man die nativen Möglichkeiten nutzen, die existieren.

Oder ich sehe die Welt zu blauäugig, kommt gerne immer wieder vor…

Rolf