& (PHP) PHP 5 auf Apache 2 in .html-Dateien eines Virtual Hosts
Cheatah
- webserver
Hi,
normalerweise stelle ich mich nicht unbedingt allzu dämlich an, wenn ich herausfinden will, wie man Apache 2 (unter WinXP) eine bestimmte Sache beibringt. Zumal die Aufgabe eigentlich sehr einfach ist:
[x] Richte PHP 5 als Servermodul ein.
[x] Lasse auf ".html" endende Dateien PHP-parsen.
[ ] Tue dies in einem Virtual Host.
Meine Konfiguration sieht im Wesentlichen wie folgt aus:
LoadModule php5_module ../PHP/php5apache2.dll
PHPIniDir "D:/Programme/Netz/Server/PHP"
AddType application/x-httpd-php .php .html
[...]
<VirtualHost 127.0.0.7>
ServerName jamesbond.localhost
DocumentRoot "D:/..."
AddType application/x-httpd-php .php .html
</VirtualHost>
Lasse ich die globale AddType-Direktive weg, "reagiert" der Server darauf, ob im VirtualHost .php vermerkt ist. Das .html hat für den eigentlichen (nicht-virtuellen) Server ebenfalls eine Wirkung. Nur die Kombination scheint nicht zu funktionieren. Es ist dabei unerheblich, ob ich die Endungen einzeln oder gruppiert angebe, bzw. ob .php mit PHP verknüpft wurde. Nirgendwo in der httpd.conf finde ich eine Kollision mit anderen .html-bezüglichen Konfigurationen; Spielereien mit der Options-Direktive (bisher wurden .html-Dateien SSI-geparst) blieben erfolgfrei, ebenso wie AddHandler-Versuche. Ich habe sogar den .html-Eintrag aus der mime.types rausgeschmissen :-) und weiß jetzt leider wirklich nicht mehr, wo ich noch buddeln soll. Die PHP-Doku inkl. der User-Kommentare enthielt für mich leider auch nichts Berauschendes, also genauso viel, wie mir Google entgegen schlug.
Kann mir jemand einen Tipp geben, welches Wissen mir fehlt? Welche Informationen muss ich noch liefern?
Cheatah
hi,
[x] Richte PHP 5 als Servermodul ein.
[x] Lasse auf ".html" endende Dateien PHP-parsen.
[ ] Tue dies in einem Virtual Host.
Meint letzteres: Tue dies _nur_ für den Virtual Host?
Lasse ich die globale AddType-Direktive weg, "reagiert" der Server darauf, ob im VirtualHost .php vermerkt ist. Das .html hat für den eigentlichen (nicht-virtuellen) Server ebenfalls eine Wirkung.
D.h., auch wenn du _nur_ für den Virtual Host angibst, dass du .html als PHP geparst haben möchtest, reagiert auch der "restliche" Server darauf?
Nur die Kombination scheint nicht zu funktionieren.
Wozu die Kombination?
Die wäre doch eh "doppelt gemoppelt" - so wie du schriebst, hattest du ja
AddType application/x-httpd-php .php .html
sowohl für den Virtual Host als auch für den gesamten Server angegeben.
Verstehe ich dich richtig, dass du .php auf dem gesamten Server geparst haben möchtest, .html jedoch nur innerhalb des Virtual Hosts?
(Btw: definiere "scheint nicht zu funktionieren" *scnr*)
Nirgendwo in der httpd.conf finde ich eine Kollision mit anderen .html-bezüglichen Konfigurationen;
Hast du nur nach explizit auf .html bezogenen Einstellungen gesucht?
Gibt es vielleicht noch andere, generellere - bspw. eine <Files> oder <FilesMatch>-Direktive, die (unbeabsichtigt) auch .html mit einschließt (Wobei darin AddType wohl gar nicht erlaubt ist); oder eine für <Directory>?
Wird irgendwo ForceType verwendet?
Spielereien mit der Options-Direktive (bisher wurden .html-Dateien SSI-geparst) blieben erfolgfrei,
Ist das Parsen von .html als SSI damit jetzt definitiv abgestellt?
gruß,
wahsaga
Hi,
[x] Lasse auf ".html" endende Dateien PHP-parsen.
[ ] Tue dies in einem Virtual Host.
Meint letzteres: Tue dies _nur_ für den Virtual Host?
das ist aus meiner Sicht (zumindest derzeit) irrelevant. Schön wäre, wenn das ginge.
D.h., auch wenn du _nur_ für den Virtual Host angibst, dass du .html als PHP geparst haben möchtest, reagiert auch der "restliche" Server darauf?
Ah, sorry. Nein, der reagiert nur auf das, was global angegeben wurde.
Nur die Kombination scheint nicht zu funktionieren.
Wozu die Kombination?
Die Kombination aus "Virtual Host" und ".html wird PHP-geparst" :-)
Die wäre doch eh "doppelt gemoppelt" - so wie du schriebst, hattest du ja
AddType application/x-httpd-php .php .html
sowohl für den Virtual Host als auch für den gesamten Server angegeben.
Auch zu Testzwecken, ja.
Verstehe ich dich richtig, dass du .php auf dem gesamten Server geparst haben möchtest, .html jedoch nur innerhalb des Virtual Hosts?
Im Grunde ist mir .php völlig wurscht. Ich möchte angeben, wo ich .html-Dateien PHP-geparst bekomme. Die .php-Angaben hatten letztlich vor allem den Zweck, die grundsätzliche Korrektheit der Einrichtung zu beweisen.
(Btw: definiere "scheint nicht zu funktionieren" *scnr*)
Har, har. Damit meine ich natürlich, dass es net funzt, ist doch klar ;-)
Nirgendwo in der httpd.conf finde ich eine Kollision mit anderen .html-bezüglichen Konfigurationen;
Hast du nur nach explizit auf .html bezogenen Einstellungen gesucht?
Du solltest mich besser kennen ;-) Ich habe mir praktisch jede Direktive einzeln durchgelesen, nachdem ich nichts fand, was .html-spezifisch ist.
Gibt es vielleicht noch andere, generellere - bspw. eine <Files> oder <FilesMatch>-Direktive,
Nein. Ich war gerade versucht zu behaupten, die Konfiguration sei bis auf das <VirtualHost>-Geraffel quasi der unveränderte Default, bis auf Dateipfade und ähnliches, bis mir dann einfiel, dass das Ähnliche bei einem Konfigurator wie mir ziemlich viel ist. Aber an "großen Sachen"[tm] habe ich nur Virtual Hosts eingerichtet.
Wird irgendwo ForceType verwendet?
Nur in dem bereits gelöschten Versuch von mir, der ergeben hat, dass die Ressourcen anschließend als application/x-httpd-php an den Client gesendet werden. Ansonsten kommt nichts dergleichen vor.
Spielereien mit der Options-Direktive (bisher wurden .html-Dateien SSI-geparst) blieben erfolgfrei,
Ist das Parsen von .html als SSI damit jetzt definitiv abgestellt?
Derzeit habe ich ein entweder-oder. Allerdings habe ich Options global auf ziemlich viel eingestellt und nur im Virtual Host getestet, ob das Abschalten von Includes (bzw. allem Möglichen) etwas ändert. Ja, es beendete das Parsen von SSI :-)
Cheatah
Hi,
Entwarnung und Entschuldigung. Ich darf eine neue[1] Form des Pair-Programmings verkünden: Zwei Leute arbeiten mit zwei Rechnern an einer Datei.
In diesem Fall an einer .htaccess ...
Dass ich dort nicht gleich nachgesehen habe. Sorry für die scheuen Pferde.
Cheatah
[1] Naja, vermutlich gibt es Prior Art. Das Patent spare ich mir :-)