nicht angemeldet
hallo Christoph
Was haben Direktiven mit der Verzeichnisstrutur zu tun? Und deine Ausgangsfrage ging ausdrücklich nach einer .htaccess - jetzt also nicht mehr?
Du bist wirklich nicht gerade Fehlertollerant.
Ok es sind nicht Direktiven ich meine das:
<Directory />
Options SymLinksIfOwnerMatch
AllowOverride None
</Directory>
<Directory /var/www/>
Options Indexes Includes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
Momentmal Apache bekommt eine Anforderung den Script auszuführen kann er nicht wenn es perl ist und kein MOD installiert.
Apache bekommt niemals eine Aufforderung, irgendein Script auszuführen. Das kann er nicht. Er kann aber aufgrund einer Anfrage vergleichen, ob in seiner Konfiguration vorgesehen ist, welcher "Partner" (beispielsweise Perl) ein Script ausführen dürfte, und dem dann das Script zur gefälligen Abarbeitung übergeben. Was du jetzt mit MOD meinst, ist mir unklar. Um den Perl-Interpreter um die Ausführung irgendeines Scripts zu bitten, muß der Apache überhaupt nix von irgendeinem mod_* wissen.
Quatsch
Der client macht eine Anfrage an den Server der in unserem Falle Apache ist.
ist es ein normaler Apache da hast du dann recht sucht er den Partner, aber ich habe nichts anders gemeint, wenn du "richtig" lesen würdest.
Und wenn aber Apache-perl aufgerufen wird) Was geschieht dann mit einem perlscript-Aufruf?
Damit du nicht gleich wieder mit einer Spitzfindigkeit rüberkommst ;-)
Dir ist klar was folgendes bedeutet?
<IfModule mod_perl.c>
Ach ist das etwa ein als MODul integrierter Perlinterpreter?
Frage ist ein Apache-Modul ein Teil vom Apache oder nicht?
Also ruft er den Perl-interpreter auf. Von dem bekommt er zuerst die Redirektion oder einen anderen Output zurück über den STDOUT.
STDOUT? Wie sollte Apache damit umgehen?
Wie geht ein Programm wohl damit um, wenn sein Child-Prozess (und Perl ist ein Child vom Apache) auf stdout ausgibt?
in Perl muß indi dazu Backticks nehmen oder qx// da Perl in C geschrieben ist, muß das auch in C möglich sein. Apache ist doch in C geschrieben, wo ist also das Problem den Standard Output abzufangen?
Es fängt es auf und reagiert darauf. Ist natürlich abhängig, wie der Perlinterpreter gestartet wird, ob das passiert oder wie. Der Apache wird doch nicht beendet und überläßt alles weitere dem Perlinterpreter(wie es in perl EXEC machen würde) folglich wird auch der Rückgabewert des Interpreters bzw sein stdout weiterverarbeitet, wie sollte sonst aus dem Script beispielsweise die Daten einer HTML-Seite zum Server gelangen? Der Perl-Prozess startet doch nicht einen Apache-Prozess was er müßte, wenn er mit Exec aufgerufen wäre.
Wenn ich HTML ausgebe mit einem Perlscript, dann gebe ich zuerst den Header per print und dann die html-daten per print aus und print gibt nun mal auf stdout aus (wenn man das nicht verbiegt). Jedenfalls steht das so im Camelbook. Dann wird Perl einfach beendet, nix Apache aufrufen. Wer, wenn nicht der Apache, fängt bitte schön die Daten von stdout auf, um sie dem Client zugeben?
So und den Rest werde ich jetzt nicht nocheinmal kommentieren, du willst mich an dieser Stelle nicht verstehen, weil du wie vernagelt Daten und Authentifizierungsdaten nicht unterscheiden willst. Deshalb reden wir aneinander vorbei. Wer lesen kann ist klar im Vorteil ;-)
Nur noch eins, mir ist klar was /dev/null bedeutet. Dir ist aber nicht klar, das es längst nicht mehr um die ersten beiden Zeilen der .htaccess ging, sondern darum, zuerkennen, was erreicht werden sollte mit dem: <Limit GET>
Hast du schon mal probiert welche Wirkung eine .htaccess-Datei im cgi-bin/ - pfad hat der keine der nachfolgenden Schlüsselworte enthält?
AuthUserFile AuthGroupFile AuthType
Ich meine, das das dann irgendwie sinnlos ist.
Joe
Der Martin