phpbar.de logo

Mailinglisten-Archive

[php] mod_rewrite ohne mod_rewrite [was: PHP und Subdomains]

[php] mod_rewrite ohne mod_rewrite [was: PHP und Subdomains]

Hannes H. dubaut at gmail.com
Die Jul 25 19:18:55 CEST 2006


Guten Abend :-)

Vielleicht wundert ihr euch über den sonderbaren Titel, aber Leser des
PHPMagazins werden wissen warum ich selbigen gewählt habe ;-)

Ausganssituation: Eine Website mit dem URL www.example.com. Die
registrierten User sollen über www.example.com/user/#username# auf
ihre persönliche Seite gelangen. Der Absolute Pfad zum Webroot ist
/var/www/example.com/webroot, der Webserver sei Apache.

Bei Lösung a) würde man das ganze per mod_rewrite durch die Gegend
umschreiben und so alles auf ein Script
/var/www/example.com/webroot/controler.php lenken, in dem dann die
$_SERVER-Infos ausgewertet und entsprechend die Seiten geladen werden.

Lösung b) umgeht das (von mir gehasste) Apache-Modul mod_rewrite.
Anstatt des Scripts controler.php kommt in
/var/www/example.com/webroot ein File mit dem Namen "user". Die
VirtualHost-Direktive (in httpd.conf bzw. apache2.conf) sieht wie
folgt aus:

<VirtualHost 1.2.3.4:80>
   ServerName example.com
   ServerAlias www.example.com
   <Directory /var/www/example.com/webroot>
      <Files user>
         ForceType application/x-httpd-apache
      </Files>
   </Directory>
</VirtualHost>

Mit der ForceType-Direktive wird erzwungen, dass "user" als PHP-Script
interprediert wird, obwohl es keine mit AddType in
httpd.conf/apache2.conf definierte Endung besitzt. In dem Script
"user" kann dann wohl ähnlich wie in controler.php vorgegangen werden.

Und jetzt die Frage: Warum das alles? Die Vorteile aus meiner Sicht:

1. kein mod_rewrite
Durch den Verzicht auf mod_rewrite wird auf ein zusätzliches
Apache-Modul verzichtet, was durchaus einen positiven (aber wohl kaum
messbaren) Vorteil in der Performenz bingen wird. Außerdem ist jedes
nicht verwendete Modul ein sicheres Modul, welches keine Lücken haben
kann.

2. nativer Zugriff auf alle Umgebungsvariablen
Da per HTTP tatsächlich die Datei "user" aufgerufen wird (und nicht
irgend eine rewrite-Rule), kann man sicher sein, dass man bei den
Werten der $_xxx [zB. $_SERVER]-Variablen keine bösen Überaschungen
erlebt, die vielleicht durch mod_rewrite tückisch versteckt sein
könnten.

Wo Sonne ist, da ist auch Schatten ...
...und der trifft uns bei meiner Lösung genau dann, wenn PHP als
CGI-Modul im Apache läuft (was IMHO nirgends mehr der Fall sein
sollte). Denn genau dann würde der Aufruf
http://www.example.com/user/#username# einen 404er hervorrufen, da
natürlich entsprechende Datei
/var/www/example.com/webroot/user/#username im Filesystem nicht zu
finden ist.

Kleine Bemerkung am Rande: In meinen Projekten verwende ich nur diese
Methode und in "user" würde dann lediglich als einzige Zeile ein
require_once() stehen, welches das eigentliche Script aufruft, dass
dann unterhalb des Webroots liegt. Vorteil: Wenn aus irgend einem
Grund der Server falsch konfiguriert werden und die PHP-Funktionalität
deaktiviert ist, wird zwar PHP-Source ausgeliefert, allerdigns
lediglich eine Datei, in der ein require auf ein File unterhalb des
Webroots zu finden ist - niemand kommt an den PHP-Source ran.

Ich hoff, ich hab ein wenig verständlich erklärt, was ich meine und
kann den einen oder anderen für meine Idee begeistern.

#Hannes#

php::bar PHP Wiki   -   Listenarchive