gesucht: apache mod_rewrite (pre-compiled) für win32
MADU
- webserver
hallo,
ich hab apache/1.3.12 als service auf win2k installiert (autoinstaller, nicht selbst kompiliert). ich möchte nun das modul mod_rewrite benutzen, das in dieser installation nicht enthalten ist.
zu meiner frage: wo kann man eine kompilierte version dieses moduls downloaden? wo gibt es beschreibungen, wie es zu installieren ist? bei google bin ich leider nicht fündig geworden
danke im voraus
ich hab apache/1.3.12 als service auf win2k installiert (autoinstaller, nicht selbst kompiliert). ich möchte nun das modul mod_rewrite benutzen, das in dieser installation nicht enthalten ist.
Dann besorg dir doch eine von apache.org, wo es enthalten ist. Ich seh dein Problem nicht.
ich hab apache/1.3.12 als service auf win2k installiert (autoinstaller, nicht selbst kompiliert). ich möchte nun das modul mod_rewrite benutzen, das in dieser installation nicht enthalten ist.
Dann besorg dir doch eine von apache.org, wo es enthalten ist. Ich seh dein Problem nicht.
ich hab die dll inzwischen gefunden - es ist die ApacheModuleRewrite.dll
in der httpd.conf binde ich sie mit
LoadModule rewrite_module modules/ApacheModuleRewrite.dll
ein
in der entsprechenden .htaccess steht
RewriteEngine on
RewriteRule ^(.*)(.html?)$ shownews.php?id=$1
was unter lamp einwandfrei funktioniert, nur unter win32 nicht.
wenn du erfahrung damit hast, wie die httpd.conf angepaßt gehört, damit man die rewriteengine verwenden kann, dann wär ich für einen tipp dankbar
lg
madu
Grüssi!
*blink* *blink*
RewriteEngine on
RewriteRule ^(.*)(.html?)$ shownews.php?id=$1
*augenweitaufgerissen*
Wenn es das macht was ich mir denke, dann ist das die Antwort auf eine Frage, die ich schon fast aufgegeben habe !!!
Kann mir bitte bitte jemand genau erklären was diese zwei zeilen machen?
Ich bräuchte nämlich was in die Richtung:
Ich möchte dass alle xml-Dateien auf dem Webspace mit einer einzigen PHP-Funktion gehandelt werden. Wenn man also im Browser aufruft:
http://www.x.y.z/index.xml möchte ich dass der alte Indianer das auf http://www.x.y.z/open.php umleitet und die PATH_INFO als Parameter übergibt. Ich muss in open.php nämlich die xml-Datei parsen! Am besten sollte aber das nur Serverintern ablaufen! Denn index.xml sollte in der Adressleiste stehen bleiben (Zwecks Vorwärtskompatibilität) ich mag keine open.php?url=/index.xml URLs, abgesehen davon dass ich jetzt weiss, dass das keine korrekten URL-Angaben sind ;-)
Mit Alias und Redirect habe ich schon herumgespielt, aber er ändert mir immer die Location im Adressfenster! Ich möchte aber sowas wie einen Handler für xml-Dateien!
Also, wenn mich da jemand beruhigen könnte, dass (und sagen wie) das geht, dem wäre ich ewig dankbar :-))
lg bernhard
Grüssi!
*blink* *blink*
RewriteEngine on
RewriteRule ^(.*)(.html?)$ shownews.php?id=$1
*augenweitaufgerissen*
Wenn es das macht was ich mir denke, dann ist das die Antwort auf eine Frage, die ich schon fast aufgegeben habe !!!
Kann mir bitte bitte jemand genau erklären was diese zwei zeilen machen?
Ich bräuchte nämlich was in die Richtung:
Ich möchte dass alle xml-Dateien auf dem Webspace mit einer einzigen PHP-Funktion gehandelt werden. Wenn man also im Browser aufruft:
http://www.x.y.z/index.xml möchte ich dass der alte Indianer das auf http://www.x.y.z/open.php umleitet und die PATH_INFO als Parameter übergibt. Ich muss in open.php nämlich die xml-Datei parsen! Am besten sollte aber das nur Serverintern ablaufen! Denn index.xml sollte in der Adressleiste stehen bleiben (Zwecks Vorwärtskompatibilität) ich mag keine open.php?url=/index.xml URLs, abgesehen davon dass ich jetzt weiss, dass das keine korrekten URL-Angaben sind ;-)
Mit Alias und Redirect habe ich schon herumgespielt, aber er ändert mir immer die Location im Adressfenster! Ich möchte aber sowas wie einen Handler für xml-Dateien!
Also, wenn mich da jemand beruhigen könnte, dass (und sagen wie) das geht, dem wäre ich ewig dankbar :-))
lg bernhard
RewriteEngine on
aktiviert die rewrite-engine im aktuellen verzeichnis
RewriteRule ^(.*)(.html?)$ shownews.php?id=$1
legt eine rewrite-regel fest
wenn der benutzer eingibt: beliebigertext.html
dann macht der server draus: shownews.php?id=beliebigertext
am client bleibt natürlich beliebigertext.html stehen.
sehr vorteilhaft auch für search-engines.
vielseitig einsetzbar, weil die rules mit regulären ausdrücken festgelegt werden
auf LAMP geht das alles tadellos, einzig auf win32 bekomm ich die konfiguration des rewrite-moduls nicht hin. vielleicht hast du ja einen tipp oder vielleicht kennst du jemanden, der das apache-modul "mod_rewrite" erfolgreich auf win32 konfiguriert hat?
lg
MADU
Grüssi!
RewriteRule ^(.*)(.html?)$ shownews.php?id=$1
legt eine rewrite-regel fest
wenn der benutzer eingibt: beliebigertext.html
dann macht der server draus: shownews.php?id=beliebigertext
am client bleibt natürlich beliebigertext.html stehen.
Hmmm, lässt sich das auch erweitern? So dass die Parameter, die an die html-Seite übergeben wurden auch die php-Datei-parameterliste angehängt werden? Und eine letzte Frage: Funktioniert das auch mit aktivierten Multiviews, also wenn die Dateiendung nicht eingegeben wurde?
auf LAMP geht das alles tadellos, einzig auf win32 bekomm ich die konfiguration des rewrite-moduls nicht hin. vielleicht hast du ja einen tipp oder vielleicht kennst du jemanden, der das apache-modul "mod_rewrite" erfolgreich auf win32 konfiguriert hat?
Nö, leider kann ich dir da überhaupt nicht helfen, aber ich werde mich mal umhören in meiner näheren Umgebung ;-) Und spätestens Anfang August wird mir dasselbe blühen wie dir, so wie ich das jetzt sehe ;-)
lg,
Bernhard
Grüssi!
RewriteRule ^(.*)(.html?)$ shownews.php?id=$1
legt eine rewrite-regel fest
wenn der benutzer eingibt: beliebigertext.html
dann macht der server draus: shownews.php?id=beliebigertext
am client bleibt natürlich beliebigertext.html stehen.
Hmmm, lässt sich das auch erweitern? So dass die Parameter, die an die html-Seite übergeben wurden auch die php-Datei-parameterliste angehängt werden? Und eine letzte Frage: Funktioniert das auch mit aktivierten Multiviews, also wenn die Dateiendung nicht eingegeben wurde?
ich wäre froh, wenn ich das ganze schon so weit testen könnte. im prinzip ist alles möglich, was sich durch regexp beschreiben läßt - und das ist ja schon eine ganze menge. parameterliste auslesen und an die php-datei anhängen ist recht einfach... geht mit einer regexp-backreference wie im beispiel oben. außerdem ist rewriterule nur eine funktion des mod_rewrite, ich hab beim überfliegen einiger sites bemerkt, daß das modul noch viel mehr kann.
auf LAMP geht das alles tadellos, einzig auf win32 bekomm ich die konfiguration des rewrite-moduls nicht hin. vielleicht hast du ja einen tipp oder vielleicht kennst du jemanden, der das apache-modul "mod_rewrite" erfolgreich auf win32 konfiguriert hat?
Nö, leider kann ich dir da überhaupt nicht helfen, aber ich werde mich mal umhören in meiner näheren Umgebung ;-) Und spätestens Anfang August wird mir dasselbe blühen wie dir, so wie ich das jetzt sehe ;-)
hölle! ich wünsch dir einen schönen august :)
lg
martin
Grüssi,
hölle! ich wünsch dir einen schönen august :)
nana, wer wird denn gleich so schwarzmalen ? *SCNR*
Gibts eigentlich eine Möglichkeit, sich eine Liste mit den installierten Apache-Modulen ausgeben zu lassen (Perl/PHP/...)? Ähnlich des print $ENV?
lg bernhard -- der jetzt noch gut lachen kann :-/
Grüssi,
hölle! ich wünsch dir einen schönen august :)
nana, wer wird denn gleich so schwarzmalen ? *SCNR*
Gibts eigentlich eine Möglichkeit, sich eine Liste mit den installierten Apache-Modulen ausgeben zu lassen (Perl/PHP/...)? Ähnlich des print $ENV?
dosshell> apache -l
lg
martin
Grüssi,
Gibts eigentlich eine Möglichkeit, sich eine Liste mit den installierten Apache-Modulen ausgeben zu lassen (Perl/PHP/...)? Ähnlich des print $ENV?
dosshell> apache -l
Und auf nem RedHat-System beim Provider (ohne Telnet-Zugang?) :-/ Kann man das mit system() auch abfragen?
danke,
bernhard
Grüssi,
Gibts eigentlich eine Möglichkeit, sich eine Liste mit den installierten Apache-Modulen ausgeben zu lassen (Perl/PHP/...)? Ähnlich des print $ENV?
dosshell> apache -l
Und auf nem RedHat-System beim Provider (ohne Telnet-Zugang?) :-/ Kann man das mit system() auch abfragen?
keine ahnung. wenn's dir um das mod_rewrite geht: versuchs einfach, indem du eine .htaccess mit den entsprechenenden einstellungen schreibst - am ergebnis siehst du ja, ob das modul da ist oder nicht
Hallo Bernhard!
Gibts eigentlich eine Möglichkeit, sich eine Liste mit den installierten Apache-Modulen ausgeben zu lassen (Perl/PHP/...)? Ähnlich des print $ENV?
dosshell> apache -l
Und auf nem RedHat-System beim Provider (ohne Telnet-Zugang?) :-/ Kann man das mit system() auch abfragen?
mit PHP ganz einfach:
<?
phpinfo();
?>
da findet sich auch eine Liste aller installierten Apache-Module.
Gruss,
Carsten
hallo berhard,
» Wenn es das macht was ich mir denke, dann ist das die Antwort auf eine Frage, die ich schon fast aufgegeben habe !!!
und warum fragt du dann nicht?
Kann mir bitte bitte jemand genau erklären was diese zwei zeilen machen?
http://httpd.apache.org/docs/mod/mod_rewrite.html
grüße
thomas
Hallo Thomas!
» Wenn es das macht was ich mir denke, dann ist das die Antwort auf eine Frage, die ich schon fast aufgegeben habe !!!
und warum fragt du dann nicht?
Ich hätte gefragt, darauf kannste wetten ;-) Jetzt hab ich mir einen Thread erspart. Weiss vorerst mal alles was ich wissen muss, nämlich womit das geht, damit herumspielen werde ich ein zwei wochen später (Urlaubspause *g*) und dann ist die Wahrscheinlichkeit hoch, dass ich hier nochmal reinschneie mit diesem Thema *fg*
Da häng ich doch gleich noch einen dran:
http://www.modrewrite.com/ :-)
lg bernhard
was unter lamp einwandfrei funktioniert, nur unter win32 nicht.
Definiere "funktioniert nicht".
wenn du erfahrung damit hast, wie die httpd.conf angepaßt gehört, damit man die rewriteengine verwenden kann, dann wär ich für einen tipp dankbar
Ich habe leider Probleme mit der Hellseher-Behörde, weil ich zuviele Kristallkugeln verschleisse, du musst also schon mit mehr Informationen kommen.
Grüssi :-)
Ich möchte dass alle xml-Dateien auf dem Webspace mit einer einzigen PHP-Funktion gehandelt werden. Wenn man also im Browser aufruft:
http://www.x.y.z/index.xml
möchte ich dass der alte Indianer das auf http://www.x.y.z/open.php umleitet und die PATH_INFO als Parameter übergibt. Ich muss in open.php nämlich die xml-Datei parsen! Am besten sollte aber das nur Serverintern ablaufen! Denn index.xml sollte in der Adressleiste stehen bleiben (Zwecks Vorwärtskompatibilität) ich mag keine open.php?url=/index.xml URLs, abgesehen davon dass ich jetzt weiss, dass das keine korrekten URL-Angaben sind ;-)
Für die Ewigkeit (und so manchen Archivleser):
Ich (zugegebenermassen nicht allein) hab genau das auch ohne mod_rewrite hinbekommen. Ich definierte mir einen Handler im Webserver, und eine dazugehörige Action, und legte los:
Ich erweiterte also zuerst meine httpd.conf um folgende zwei Zeilen:
AddHandler xml-handler .xml
Action xml-handler /open.php
Diese Anweisungen können ebenso in folgenden Kontexts stehen: In der ServerConfig (z.b.: httpd.conf) in einem <virtualhost>, <directory>, oder auch in der htaccess-Datei!
Ich definierte mir also einen Handler namens "xml-handler" der auf alle xml-Dateien in diesem und dessen Unterverzeichnissen lauscht. Und eine mit diesem Handler verbundene Action, also eine Funktion, ein Script, das Dateien dieses Typs (xml) "handlen" soll.
Handler können entweder frei gewählt werden, oder den MIME-Type spezifizieren. Es wären also auch folgende Anweisungen gültig:
AddHandler text/xml .xml
Action text/xml /open.php
Das wärs eigentlich schon ;-) Somit wird jeder Request für eine xml-Datei intern in einen Request "umgeleitet" der folgendermassen aussieht:
GET /php/php.exe/open.php/test.xml HTTP/1.1
[Die Antwort auf die Frage nach den Sicherheitsrisiken überlasse ich jemand kompetenterem ;-)]
Da es sich hier um einen CGI-Aufruf handelt muss man vorher den richtigen Content-Type-Header ausgeben. In PHP scheint das automatisch zu passieren. Man kann aber auch mit der header()-Funktion händisch nachhelfen ;-) In Perl geht aber nichts an einem
print "Content-type: text/html\n\n";
vorbei ;-) Nichtsdestotrotz hatte ich Probleme beim Aufruf von test.xml [1] Es kam immer eine 500er-Fehlermeldung, wobei im ErrorLog von Apache zu lesen war:
Premature End of Script Headers: /php/php.exe :-(
Nach langem Herumtüfteln habe ich versucht den PHP-Interpreter nicht standardmässig als binary in den Apache einzubauen, sondern ihn als Apache-Modul laufen zu lassen, und schwuppsdiwupps, klappte plötzlich alles, und sämtliche grauen Haare, die ich währenddessen lassen musste, schienen vergessen ;-)
Nach ein wenig Herumspielen mit dieser neuen Errungenschaft, bin ich auf einige nützliche Eigenschaften gestossen. Man kann in bestimmten HTTP-Umgebungsvariablen sehr nützliche informationen herauslesen. Mir liefert zum Beispiel PATH_TRANSLATED den absoluten Pfad zu der Datei, die Aufgerufen wurde. PATH_INFO enthält den relativen Pfad vom web-Root-Verzeichnis aus gesehen, PHP_SELF beinhaltet in diesem Fall auch den SCRIPT_NAME. Ein wie ich finde besonderes Zuckerl dieser Variante ist, dass man Parameter, die an den HTTP-Request angehängt werden ganz normal durch die gängigen CGI-Parameter abfragen abgerufen werden können.
Hier meine Beispieldateien zum Ausprobieren:
/test.xml:
----------
<?xml version="1.0" standalone="yes" ?>
<test>Dies ist nur ein Test</test>
/open.php:
----------
<?
echo "PHP_SELF: ".$HTTP_SERVER_VARS['PHP_SELF']."\n";
echo "PATH_INFO: ".$HTTP_SERVER_VARS['PATH_INFO']."\n";
echo "PATH_TRANSLATED: ".$HTTP_SERVER_VARS['PATH_TRANSLATED']."\n";
echo "SCRIPT_NAME: ".$SCRIPT_NAME."\n";
echo "Parameter 'id': ".$id."\n";
?>
htaccess:
---------
AddType application/x-httpd-php .php
AddHandler text/xml .xml
Action text/xml /open.php
http.conf: (PHP als Modul)
----------
LoadModule php4_module c:/php/sapi/php4apache.dll
Bei einem Aufruf:
http://testsuite/test.xml?id=probiermamal
gibt das Test-Script folgenden Output zurück:
PHP_SELF: /open.php/test.xml
PATH_INFO: /test.xml
PATH_TRANSLATED: c:\httpd\apache\htdocs\testsuite\test.xml
SCRIPT_NAME: /open.php
Parameter 'id': probiermamal
Somit wären alle meine Probleme gelöst *fg* Bis auf das Rätsel, warum das (in PHP) nur mit einer Installation als Modul funktioniert. Aber vielleicht komm ich da ja auch noch drauf, irgendwann mal ;-)
lg und trotzdem Danke für deine Tipps zu mod_rewrite :-)
bernhard
PS: Ich kann nur hoffen, dass hier unten noch genug Leute mitlesen, damit mein Posting es ins Archiv schafft. Allein schon weil ich vielleicht später mal wieder sowas machen will und dann was brauch wo ich nachlesen kann wie ich das gemacht habe *g*
Hallo Berhrad,
Somit wären alle meine Probleme gelöst *fg* Bis auf das Rätsel, warum das (in PHP) nur mit einer Installation als Modul funktioniert. Aber vielleicht komm ich da ja auch noch drauf, irgendwann mal ;-)
ich gebe hier wiessen zurück, die ich selbst als antwort bekommen habe:
(die fehlerhafte notation dieser könnte bei dir den fehler verursacht haben)
Das "1" definiert einen Apache-Handler in Form eines auf-
zurufenden CGI-Programms, das bei jeder Anforderung
eines Dokuments mit diesem MIME-Typ aktiviert wird.
Es kann in jeder beliebigen Sprache geschrieben sein;
es bekommt den URL des angeforderten Dokuments als
CGI-Parameter und kann damit tun, was es will -
LoadModule dagegen lädt ein Modul, das dem Apache in-
tern hinzugefügt wird und dauerhaft geladen bleibt.
Während der externe PHP-Interpreter (ebenso wie der
externe Perl-Interpreter) für jedes Dokument neu ge-
startet wird, ist das Modul ein integraler Bestandteil
des Apache (genau wie der SSI- und der CGI-Handler)
und muß dazu dessen interne API bedienen (Aufrufe,
Parameter, ...). Und es muß im plattformspezifischen,
kompilierten Format für dynamisch nachladbare Module
vorliegen, im Gegensatz zum oben erwähnten CGI-Skript.
(Also unter Windows eine DLL etc.)
Module sind natürlich performanter, weil die ständige
Ladezeit (und die Versorgung der CGI-Schnittstelle) für
den Handler wegfällt - je kleiner ein Skript ist (vor
allem in Relation zum Interpreter), desto mehr spart man
bei der Verwendung des Moduls als Interpreter.
Da der Interpreter aber hierbei dauerhaft geladen bleibt
und die durch ihn ausgeführten Skripte sinnvollerweise
ebenfalls (Cacheing), durchläuft er bestimmte Initiali-
sierungsroutinen nicht mehr.
Perl setzt beispielsweise zu Beginn der Interpretation
eines Skripts automatisch alle Variablen auf 'leer'.
Verläßt sich ein 'schlampiger' Programmierer auf solche
Eigenschaften, dann funktioniert sein Skript *nur* mit
dem externen Interpreter, nicht aber mit dem internen
Modul.
So gesehen machen beide Installationsformen Sinn, weil
viele Anfänger die zusätzlichen Anforderungen an ein per
mod_perl ausführbares Skript nicht verstehen werden.
In jedem der beiden Fälle muß das, was verwendet werden
soll, auch vorhanden sein. Nur merkt der Apache das Feh-
len eines Moduls bereits bei seinem Start (und bricht
diesen dann sofort ab), während er das Fehlen eines Hand-
lers lediglich beim Ansprechen eines passenden Dokuments
bemerkt und durch einen Eintrag im Error-Log quittiert
(wie bei jedem nicht gefundenen URL).
---
in meinem http.conf
sthehen beide aufrufe:
--
ScriptAlias /php4/ "C:/php/"
Action application/x-httpd-php4 "/php4/php.exe"
--
LoadModule php4_module c:/php/sapi/php4apache.dll
---
müsste ich ausprobieren, welches was "genau" macht ;-)
grüße
thomas
Hallo Thomas!
- es geht also einerseits um:
ScriptAlias /php4/ "C:/php/"
Action application/x-httpd-php4 "/php4/php.exe"
(die fehlerhafte notation dieser könnte bei dir den fehler verursacht haben)
Nö, ich habs genau so stehen!
- anderseits um:
LoadModule php4_module c:/php/sapi/php4apache.dll
[...] sehr informative Teile (aber trotzdem) rausgeschnitten [...]
in meinem http.conf
sthehen beide aufrufe:ScriptAlias /php4/ "C:/php/"
Action application/x-httpd-php4 "/php4/php.exe"
Du musst auch noch den Typ mit einer Dateiendung verknoten (In beiden Varianten!)
Wenn alle auf .php endenden Dateien den MIME-Type 'application/x-httpd-php4' haben sollen:
AddType application/x-httpd-php4 .php
--
LoadModule php4_module c:/php/sapi/php4apache.dll
jepp, so läuft php *derzeit* bei mir! Zusammen mit der AddType-Anweisung und der php4ts.dll im Windows-System-Verzeichnis!
müsste ich ausprobieren, welches was "genau" macht ;-)
Du hast ja gerade selber - sehr genau - den Unterschied zwischen beiden Varianten beschrieben *g*
Meine heisseste Vermutung für den Grund dieses 500er Fehlers liegt derzeit auf der Seite http://www.koehntopp.de/php/faq-phpinterpreter.html#phpinterpreter-19 Aber ich muss mir das noch ein paarmal durchlesen, bis ich kapiere was der gute Herr mir da mitteilen will ;-)
lg bernhard
Grüssi,
Meine heisseste Vermutung für den Grund dieses 500er Fehlers liegt derzeit auf der Seite http://www.koehntopp.de/php/faq-phpinterpreter.html#phpinterpreter-19 Aber ich muss mir das noch ein paarmal durchlesen, bis ich kapiere was der gute Herr mir da mitteilen will ;-)
Hier nochmal die konkrete Situation zum ausprobieren/mitdenken:
###########################
httpd.conf
----------
LoadModule php4_module c:/php/sapi/php4apache.dll
.htaccess
---------
AddType application/x-httpd-php .php
AddHandler text/xml .xml
Action text/xml /open.php
=> Es kommt kein Internal-Server-Error, der Handler wird korrekt zugewiesen, alles pico-bello :-)
####################
httpd.conf
----------
ScriptAlias /php/ "C:/php/"
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
Action application/x-httpd-php /php/php.exe
.htaccess
---------
AddHandler text/xml .xml
Action text/xml /open.php
Wenn ich hier das auf das mit htaccess geschützte Verzeichnis zugreife, kommt der Internal-Server Error. Lösche ich die .htaccess, so wird ganz normal php als php erkannt, und xml als xml, nur eben (logischerweise aufgrund fehlender Handler) nicht in Verbindung zueinander gestellt.
Vielleicht kann mir da ja noch jemand weiterhelfen.
lg bernhard