Mod Rewrite
Tom
- webserver
0 Mod Rewrite, ist es so richtig?
Tom
Hello,
ich möchte alle Requests umleiten, für die es keine Ressource gibt
Leider krieg ich es nicht mehr hin
Könnt Ihr mir bitte mal auf die Sprünge helfen?
kann man diese -f Option auch negieren?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hello,
ich möchte alle Requests umleiten, für die es keine Ressource gibt
Leider krieg ich es nicht mehr hin
Könnt Ihr mir bitte mal auf die Sprünge helfen?kann man diese -f Option auch negieren?
kaum hat man gefragt, funktionierts *tztz*
Ich hoffe, dass es so richtig ist und nicht doch irgendwann einen zyklischen Verlauf erzeugt:
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .* index.php?%{THE_REQUEST}
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Tach!
ich möchte alle Requests umleiten, für die es keine Ressource gibt
Ich hoffe, dass es so richtig ist und nicht doch irgendwann einen zyklischen Verlauf erzeugt:RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
Bist du sicher, dass du nicht REQUEST_URI verwenden willst? Was ist mit Verzeichnissen (und Symlinks)?
RewriteRule .* index.php?%{THE_REQUEST}
Und der Query-String?
Es gibt eine CGI-Variable, die den originalen Request enthält (deren Namen du leicht mit print_r($_SERVER) findest). Den Wert kannst du gleich aus $_SERVER lesen, ohne dir $_GET mit nicht zum eigentlichen Request gehörenden Werten zu bevölkern.
dedlfix.
Hello Dedlfix,
ich möchte alle Requests umleiten, für die es keine Ressource gibt
Ich hoffe, dass es so richtig ist und nicht doch irgendwann einen zyklischen Verlauf erzeugt:RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-fBist du sicher, dass du nicht REQUEST_URI verwenden willst? Was ist mit Verzeichnissen (und Symlinks)?
Mit REQUEST_URI funktioniert die Abfrage auf Vorhandensein von Files leider nicht.
Mit REQUEST_FILENAME kann ich zumindest auf existierende Files prüfen und die von der Umleitung ausschließen, was genau erwünscht ist. Symlinks werde ich gleich nochmal ausprobieren.
RewriteRule .* index.php?%{THE_REQUEST}
Und der Query-String?
Es gibt eine CGI-Variable, die den originalen Request enthält (deren Namen du leicht mit print_r($_SERVER) findest). Den Wert kannst du gleich aus $_SERVER lesen, ohne dir $_GET mit nicht zum eigentlichen Request gehörenden Werten zu bevölkern.
Nach der Umleitung ist da aber nix drin, wenn man sie nicht mitliefert. Da ich sowohl die Quasi-Path-Info benötige, als auch den Querystring, habe ich mit den gesamten Request leifern lassen und ihn dann mittles kleiner Funktion selber auseinandergenommen. Das funktioniert zumindest für die GET-Parameter. Ob ich an $_POST dann über PHP herankomme, weiß ich auch noch nicht.
Wenn das nicht klappt, war es wieder einer der berüchtigten Irrwege der EDV :-P
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hello,
ich möchte alle Requests umleiten, für die es keine Ressource gibt
Ich hoffe, dass es so richtig ist und nicht doch irgendwann einen zyklischen Verlauf erzeugt:RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-fBist du sicher, dass du nicht REQUEST_URI verwenden willst? Was ist mit Verzeichnissen (und Symlinks)?
Mit REQUEST_URI funktioniert die Abfrage auf Vorhandensein von Files leider nicht.
Mit REQUEST_FILENAME kann ich zumindest auf existierende Files prüfen und die von der Umleitung ausschließen, was genau erwünscht ist. Symlinks werde ich gleich nochmal ausprobieren.RewriteRule .* index.php?%{THE_REQUEST}
Und der Query-String?
Es gibt eine CGI-Variable, die den originalen Request enthält (deren Namen du leicht mit print_r($_SERVER) findest). Den Wert kannst du gleich aus $_SERVER lesen, ohne dir $_GET mit nicht zum eigentlichen Request gehörenden Werten zu bevölkern.
Nach der Umleitung ist da aber nix drin, wenn man sie nicht mitliefert. Da ich sowohl die Quasi-Path-Info benötige, als auch den Querystring, habe ich mit den gesamten Request leifern lassen und ihn dann mittles kleiner Funktion selber auseinandergenommen. Das funktioniert zumindest für die GET-Parameter. Ob ich an $_POST dann über PHP herankomme, weiß ich auch noch nicht.
Wenn das nicht klappt, war es wieder einer der berüchtigten Irrwege der EDV :-P
Das ist das Ergebnis des Tests mit POST:
------
GET:
Array
(
[POST_/forms/anfrage_HTTP/1_1] =>
)
POST:
Array
(
[data] => Array
(
[name] => Fischers Fritze
[ort] => Sägemühle
)
[btn] => Array
(
[anfrage] => Frage senden
)
)
-----
$_POST kommt normal an in PHP, $_GET geht leider kaputt, kann man sich aber leicht selber wieder aufbauen. Man muss dann bei der Dekodierung des Request-Strings nur daran denken, dass man mb_parse_str() benutzt bei utf-8 Seiten und nicht pars_str().
Glück Auf
Tom vom Berg
Tach!
Bist du sicher, dass du nicht REQUEST_URI verwenden willst? Was ist mit Verzeichnissen (und Symlinks)?
Mit REQUEST_URI funktioniert die Abfrage auf Vorhandensein von Files leider nicht.
Mit REQUEST_FILENAME kann ich zumindest auf existierende Files prüfen und die von der Umleitung ausschließen, was genau erwünscht ist.
REQUEST_FILENAME ist doch richtig, REQUEST_URI war falsch in meiner Erinnerung.
RewriteRule .* index.php?%{THE_REQUEST}
Und der Query-String?
Es gibt eine CGI-Variable, die den originalen Request enthält (deren Namen du leicht mit print_r($_SERVER) findest). Den Wert kannst du gleich aus $_SERVER lesen, ohne dir $_GET mit nicht zum eigentlichen Request gehörenden Werten zu bevölkern.
Aber REQUEST_URI war eine der Variablen, die ich meinte. Da steht der nicht umgeschriebene Request drin - zumindest der interessante Teil.
Und dann gibt es noch REDIRECT_URL, der den Teil der URL ohne Host und ohne Querystring enthält.
Nach der Umleitung ist da aber nix drin, wenn man sie nicht mitliefert. Da ich sowohl die Quasi-Path-Info benötige, als auch den Querystring, habe ich mit den gesamten Request leifern lassen und ihn dann mittles kleiner Funktion selber auseinandergenommen.
Zu umständlich.
RewriteRule .* index.php [QSA]
Dann bekommst du ein ganz normales $_GET ohne Rewrite-Zeugs drin und die URL bekommst du wie gesagt aus REDIRECT_URL.
Ob ich an $_POST dann über PHP herankomme, weiß ich auch noch nicht.
Problemlos.
Das ist das Ergebnis des Tests mit POST:
GET:Array
(
[POST_/forms/anfrage_HTTP/1_1] =>
)
Das ist der THE_REQUEST mit ersetzten Leerzeichen, den du gar nicht in der Form benötigst.
$_POST kommt normal an in PHP, $_GET geht leider kaputt, kann man sich aber leicht selber wieder aufbauen.
Unnötig. Siehe oben. Dann bleibt auch der Querystring erhalten.
dedlfix.
Tach!
RewriteRule .* index.php [QSA]
Damit bekommst du kein PATH_INFO, aber der PATH_INFO-Teil ist in REDIRECT_URL enthalten. Wenn du ihn extra benötigst, kannst du das auch so schreiben:
RewriteRule (.*) index.php/$1 [QSA]
dedlfix.
Hello,
RewriteRule .* index.php [QSA]
Damit bekommst du kein PATH_INFO, aber der PATH_INFO-Teil ist in REDIRECT_URL enthalten. Wenn du ihn extra benötigst, kannst du das auch so schreiben:
RewriteRule (.*) index.php/$1 [QSA]
Das ist ja egal, wo der kommt, hauptsache, ich habe ihn zur Verfüfugung und die Logik ist nachhaltig, also wird nicht gelich mit der nächsten Version von Apache oder PHP über den Haufen geschmissen. Darum möchte ich möglichst immer den "offiziellen Weg" einhalten.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hello,
Aber REQUEST_URI war eine der Variablen, die ich meinte. Da steht der nicht umgeschriebene Request drin - zumindest der interessante Teil.
Und dann gibt es noch REDIRECT_URL, der den Teil der URL ohne Host und ohne Querystring enthält.Nach der Umleitung ist da aber nix drin, wenn man sie nicht mitliefert. Da ich sowohl die Quasi-Path-Info benötige, als auch den Querystring, habe ich mit den gesamten Request leifern lassen und ihn dann mittles kleiner Funktion selber auseinandergenommen.
Zu umständlich.
RewriteRule .* index.php [QSA]
Dann bekommst du ein ganz normales $_GET ohne Rewrite-Zeugs drin und die URL bekommst du wie gesagt aus REDIRECT_URL.
Vielen Dank an alle Mitwirkenden, das scheint es jetzt zu sein:
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* index.php [QSA]
Dann stehen in $_GET die Parameter ganz normal zur Verfügung
In S_SERVER['REDIRECT_URL'] steht mein gewünschter Pfad.
Kurzschlüsse hat es bisher auch nicht gegeben. Ich hoffe, dass nicht noch eine "Übergeraschung" irgendwo drinsteckt. Dann kann ich damit jetzt so leben.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Kurzschlüsse hat es bisher auch nicht gegeben. Ich hoffe, dass nicht noch eine "Übergeraschung" irgendwo drinsteckt. Dann kann ich damit jetzt so leben.
Ich hab' das jetzt schnell ausprobiert und es funktioniert mit QSA einwandfrei - ich kann dir nicht sagen, wieso ich das anders mache, aber irgenswas hat damals gegen QSA gesprochen. Wenn ich das noch wüsste :)
Aber ich meine, dass es irgendwas mit dem Session-Handling von PHP zu tun hatte.
Hello,
Kurzschlüsse hat es bisher auch nicht gegeben. Ich hoffe, dass nicht noch eine "Übergeraschung" irgendwo drinsteckt. Dann kann ich damit jetzt so leben.
Ich hab' das jetzt schnell ausprobiert und es funktioniert mit QSA einwandfrei - ich kann dir nicht sagen, wieso ich das anders mache, aber irgenswas hat damals gegen QSA gesprochen. Wenn ich das noch wüsste :)
Aber ich meine, dass es irgendwas mit dem Session-Handling von PHP zu tun hatte.
Tja, sag ich doch: Übergeraschung. Das kommt dann später. :-O
Da aber $_POST, $_COOKIES und $_GET jetzt verlässlich erscheinen, sollte auch das (heutige) Sessionhandling funktionieren. Aber auf jeden Fall danke für den Hinweis. Ich werde das sicherheitshalber auch nochmal durchprobieren vorher.
Nur die Geschichte mit PATH_INFO hat nicht gleich geklappt. Aber man sollte auch vorne im Muster die Klammern setzen, wenn man hinten bei der Ersetzung $1 benutzen will. Dedlfix hatte es ja richtig hingeschrieben...
RewriteRule (.*) index.php/$1 [QSA]
nur ich hatte nur hinten das /$1 ergänzt. Was doch so zwei kleine Klammern ausmachen können ;-)
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Nur die Geschichte mit PATH_INFO hat nicht gleich geklappt. Aber man sollte auch vorne im Muster die Klammern setzen, wenn man hinten bei der Ersetzung $1 benutzen will. Dedlfix hatte es ja richtig hingeschrieben...
Du kannst dir die Klammern auch sparen und $0 notieren :)
Tach!
Ich hab' das jetzt schnell ausprobiert und es funktioniert mit QSA einwandfrei - ich kann dir nicht sagen, wieso ich das anders mache, aber irgenswas hat damals gegen QSA gesprochen. Wenn ich das noch wüsste :)
Aber ich meine, dass es irgendwas mit dem Session-Handling von PHP zu tun hatte.
Die Session-ID wird wie jeder andere Querystring-Parameter auch behandelt. Also entweder hast du ein generelles Problem mit dem Querystring oder keins. So wie Toms Lösung und mein Vorschlag aussieht, wird der Querystring nicht weiter beeinflusst, nur einfach durchgereicht.
Es könnte problematisch werden, wenn - wie so oft zu sehen ist - die Pfadbestandteile in einen Querystring-Parameter umgeschrieben werden. Dann könnte man sich durch diese Umschreibung eventuell Bestandteile des Querystrings beinflussen, wenn man denselben Namen für einen Parameter (aus einem HTML-Formular oder die Session-ID) und einen umgeschriebenen Pfadteil verwendet.
dedlfix.
Hello!
Vielen Dank an alle Mitwirkenden, das scheint es jetzt zu sein:
.htaccess
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-lRewriteRule .* index.php [QSA]
Fehlt da nicht sinnvollerweise noch die Abfrage auf Verzeichnisse?
RewriteCond %{REQUEST_FILENAME} !-d
Gruß Gunther
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
Fehlt da nicht sinnvollerweise noch die Abfrage auf Verzeichnisse?
Hello Gunther,
Vielen Dank an alle Mitwirkenden, das scheint es jetzt zu sein:
.htaccess
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-lRewriteRule .* index.php [QSA]
Fehlt da nicht sinnvollerweise noch die Abfrage auf Verzeichnisse?
RewriteCond %{REQUEST_FILENAME} !-d
siehe https://forum.selfhtml.org/?t=211219&m=1441119
Verzeichnisse sollen gezielt umgeleitet werden.
Für Symbolic Links muss ich aber noch eine Unterscheidung einbauen, denn wenn der Symbolic Link auf ein Verzeichnis zeigt, soll auch umgeleitet werden. Nur wenn er auf ein existierendes File zeigt, soll NICHT umgeleitet werden. Ich denke, dass man die Zeile mit -l daher auch weglassen kann, denn -f beinhaltet mMn auch die Files, die durch symbolischen Link erreicht werden...
Das habe ich aber noch nicht verifiziert.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hello Gunther,
Vielen Dank an alle Mitwirkenden, das scheint es jetzt zu sein:
.htaccess
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-lRewriteRule .* index.php [QSA]
Fehlt da nicht sinnvollerweise noch die Abfrage auf Verzeichnisse?
RewriteCond %{REQUEST_FILENAME} !-d
siehe https://forum.selfhtml.org/?t=211219&m=1441119
Verzeichnisse sollen gezielt umgeleitet werden.
Für Symbolic Links muss ich aber noch eine Unterscheidung einbauen, denn wenn der Symbolic Link auf ein Verzeichnis zeigt, soll auch umgeleitet werden. Nur wenn er auf ein existierendes File zeigt, soll NICHT umgeleitet werden. Ich denke, dass man die Zeile mit -l daher auch weglassen kann, denn -f beinhaltet mMn auch die Files, die durch symbolischen Link erreicht werden...
sieht doch nicht so einfach aus. Lesen bildet :-)
http://httpd.apache.org/docs/current/mod/mod_rewrite.html sagt:
'-f' (is regular file)
Treats the TestString as a pathname and tests whether or not it exists, and is a regular file.
Das bedeutet also, dass !-l bedingt drinbleiben muss, aber nur für den Fall, dass auch -d zutrifft. Wie ich das nun wieder formulieren kann in den Rewrite Conditions weiß ich leider noch nicht.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
RewriteBase /
Das ist unnötig, wenn du dich ohnehin im Stammverzeichnis befindest.
RewriteRule .* index.php?%{THE_REQUEST}
Wenn du per
RewriteRule .* index.php [L]
notierts
Sollte reichen - den Request hier anzuhängen hat afaik keinen Sinn.
Ich mach' das aktuell so und werte dann per PHP aus:
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d [OR]
RewriteCond %{REQUEST_FILENAME} -l
RewriteRule .* - [L]
RewriteRule .* index.php [L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
Das kenn ich
RewriteCond %{REQUEST_FILENAME} -d [OR]
Kannst du das bitte kurz erläutern?
RewriteCond %{REQUEST_FILENAME} -l
das auch?
RewriteRule .* - [L]
:) ?
RewriteRule .* index.php [L]
Das kenne ich wieder !
Gruß
der zwischen den Zeilen lesender
T-Rex
RewriteCond %{REQUEST_FILENAME} -f [OR]
Das kenn ich
-f = file
RewriteCond %{REQUEST_FILENAME} -d [OR]
Kannst du das bitte kurz erläutern?
-d = directory
RewriteCond %{REQUEST_FILENAME} -l
das auch?
-l = symlink
http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewritecond
Abschnitt "4. You can perform various file attribute tests:"[1]
RewriteRule .* - [L]
:) ?
Rewriting stoppen:
http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewriterule
Abschnitt: "- (dash)"[1]
[1] es ärgert mich jedes mal wieder, wenn eine Dokumentation nicht genügend ID im Quelltext verbaut hat :(
Hello,
RewriteBase /
Das ist unnötig, wenn du dich ohnehin im Stammverzeichnis befindest.
Aber es schadet doch hoffentlich auch nicht?
RewriteRule .* index.php?%{THE_REQUEST}
Wenn du per
RewriteRule .* index.php [L]
notiertsSollte reichen - den Request hier anzuhängen hat afaik keinen Sinn.
Ich mach' das aktuell so und werte dann per PHP aus:
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d [OR]
RewriteCond %{REQUEST_FILENAME} -l
RewriteRule .* - [L]RewriteRule .* index.php [L]
Ich bin jetzt bei
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* index.php?%{THE_REQUEST}
gelandet. Anders komme ich an den Path nicht heran. Oder gibt es da noch eine Möglichkeit, die ich übersehen habe? $_SERVER['PATH_INFO'] ist leer, bzw. gar nicht vorhanden. Das erscheint nur, wenn der Path _nach_ dem gefundenen Script weitergeht. Aber diese Möglichkeit wollte ich nicht.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Das ist unnötig, wenn du dich ohnehin im Stammverzeichnis befindest.
Aber es schadet doch hoffentlich auch nicht?
Nein, selbstverständlich nicht :)
Ich bin jetzt bei
.htaccess
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
Was ist mit Verzeichnissen?
RewriteRule .* index.php?%{THE_REQUEST}
gelandet. Anders komme ich an den Path nicht heran. Oder gibt es da noch eine Möglichkeit, die ich übersehen habe? $_SERVER['PATH_INFO'] ist leer, bzw. gar nicht vorhanden. Das erscheint nur, wenn der Path _nach_ dem gefundenen Script weitergeht. Aber diese Möglichkeit wollte ich nicht.
Welchen Pfad gibt es denn oberhalb index.php? Richtig: keinen, weil du ja alles zusammenleitest. THE_REQUEST anhängen ist immer noch unnötig.
An was du interessiert ist REDIRECT_QUERY_STRING und REDIRECT_URL.
An was du interessiert ist REDIRECT_QUERY_STRING und REDIRECT_URL.
Nachtrag:
Wie du andererorts schon festgstellt hast: $_POST (und auch $_COOKIE) stehen dir zur verfügung, nur $_GET musst du dir selbst stricken - QUERY_STRING solltest du zur Sicherheit auch befüllen, ab und zu braucht mans noch:
$_SERVER['QUERY_STRING'] = $_SERVER['REDIRECT_QUERY_STRING'];
(mb_)parse_str($_SERVER['QUERY_STRING'], $_GET);
Hello,
Das ist unnötig, wenn du dich ohnehin im Stammverzeichnis befindest.
Aber es schadet doch hoffentlich auch nicht?
Nein, selbstverständlich nicht :)
Ich bin jetzt bei
.htaccess
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-lWas ist mit Verzeichnissen?
Anfragen auf Verzeichnisse sollen auf jeden Fall umgeleitet werden, auch wenn es diese gibt, da es bestimmungsgemäß nur eine index.php im ganzen Projekt gibt. Und index.php wird auch die einzige Datei in DirectoryIndexes bleiben. Wenn es nachher doch mal eine in einem Verzeichnis gibt (warum auch immer), dann wird die über einen diskreten Aufruf auch genommen, da dann ja die -f-Option greift.
RewriteRule .* index.php?%{THE_REQUEST}
gelandet. Anders komme ich an den Path nicht heran. Oder gibt es da noch eine Möglichkeit, die ich übersehen habe? $_SERVER['PATH_INFO'] ist leer, bzw. gar nicht vorhanden. Das erscheint nur, wenn der Path _nach_ dem gefundenen Script weitergeht. Aber diese Möglichkeit wollte ich nicht.
Welchen Pfad gibt es denn oberhalb index.php? Richtig: keinen, weil du ja alles zusammenleitest. THE_REQUEST anhängen ist immer noch unnötig.
Die Requests lauten z.B.:
example.org/members/login?name=paul
example.org/locations/restaurants/sankt%20andreasberg/?open=10%3A00
oder so ähnlich.
Aber diese Pfade gibt es nur in der Hierarchie der Datenbank und als Links, nicht aber im Filesystem. Ich möchte sie dann auswerten können.
An was du interessiert ist REDIRECT_QUERY_STRING und REDIRECT_URL.
Das habe ich bisher nicht entdeckt und werde es daher sofort ausprobieren.
Sieht aber bisher nicht erfolgreich aus. Wie muss ich es denn richtig machen?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Das habe ich bisher nicht entdeckt und werde es daher sofort ausprobieren.
Sieht aber bisher nicht erfolgreich aus. Wie muss ich es denn richtig machen?
print_r($_SERVER); schon versucht?
Aber natürlich kannst du auch, wie dedlfix vorschlägt mit [QSA] arbeiten - ich meine aber, dass irgendwas dagegen spricht - mir fällt aber nicht mehr ein was.
مرحبا
example.org/members/login?name=paul
example.org/locations/restaurants/sankt%20andreasberg/?open=10%3A00oder so ähnlich.
Ich mache es seit geraumer Zeit mit folgenden paar Zeilen:
# .htaccess
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L,QSA]
<?php
// Den Query-String aus $_SERVER['REQUEST_URI'] entfernen
define('RequestPath', urldecode(implode('', array_slice(explode('?', $_SERVER['REQUEST_URI']), 0, 1))));
# example.org/members/login?name=paul
# steht in "RequestPath" "/members/login"
# GET ist hier garnicht drin, da kannst du Seperat drauf zugreifen
echo RequestPath;
mfg
hi,
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L,QSA]
Wozu QSA? Du hast doch gar nichts notiert, was angehängt werden soll ;)
Hotti
Tach!
RewriteRule . /index.php [L,QSA][/code]
Wozu QSA? Du hast doch gar nichts notiert, was angehängt werden soll ;)
Lies dir bitte die Funktionsweise von QSA nochmal durch. QSA hängt den vom Client kommenden Querystring an das Rewrite-Ergebnis an. Ohne QSA geht der Client-Querystring verloren. Und das ist unabhängig davon, ob du selber einen Querystring beim Umschreiben erzeugst oder nicht.
dedlfix.
Tach!
RewriteRule . /index.php [L,QSA][/code]
Wozu QSA? Du hast doch gar nichts notiert, was angehängt werden soll ;)Lies dir bitte die Funktionsweise von QSA nochmal durch. QSA hängt den vom Client kommenden Querystring an das Rewrite-Ergebnis an. Ohne QSA geht der Client-Querystring verloren.
Völlig falsch. QSA hängt den QS an, der in der Rule selbst notiert ist. Der QS im URL ist davon unberührt, da geht gar nichts verloren.
Hotti
Tach!
RewriteRule . /index.php [L,QSA][/code]
Wozu QSA? Du hast doch gar nichts notiert, was angehängt werden soll ;)Lies dir bitte die Funktionsweise von QSA nochmal durch. QSA hängt den vom Client kommenden Querystring an das Rewrite-Ergebnis an. Ohne QSA geht der Client-Querystring verloren.
Völlig falsch.
Also völlig falsch war das nicht.
Der Teil "QSA hängt den vom Client kommenden Querystring an das Rewrite-Ergebnis an." war richtig. Der Teil "Ohne QSA geht der Client-Querystring verloren." ist nur dann falsch, wenn man durch den Umschreibprozess keinen eigenen Querystring erzeugt (zum Beispiel in der obigen RewriteRule).
QSA hängt den QS an, der in der Rule selbst notiert ist.
Aber das ist genau andersrum. QSA hängt den Client-QS an, nicht den selbst erzeugten.
Der QS im URL ist davon unberührt, da geht gar nichts verloren.
Oh doch, wenn (und nur dann) du selbst einen erzeugst.
dedlfix.
hi Du alte Streitaxt ;)
Der QS im URL ist davon unberührt, da geht gar nichts verloren.
Oh doch, wenn (und nur dann) du selbst einen erzeugst.
Ja, jetzt haben wir es endlich ;)
Btw., beim Testen grad eben habe ich gesehen, dass PHP ein etwas anderes Verhalten zeigt als Perl, was die Umgebungs-Variablen betrifft, das werde ich mir mal näher anschauen, wenn ich wieder mehr mit PHP mache (ab nächste Woche).
Viele Grüße aus Rheinland-Pfalz,
Hotti
PS: Jetzt aber ab in die Glockenblumen, die Sonne scheint!
Tach!
RewriteRule . /index.php [L,QSA][/code]
Wozu QSA? Du hast doch gar nichts notiert, was angehängt werden soll ;)Lies dir bitte die Funktionsweise von QSA nochmal durch. QSA hängt den vom Client kommenden Querystring an das Rewrite-Ergebnis an. Ohne QSA geht der Client-Querystring verloren. Und das ist unabhängig davon, ob du selber einen Querystring beim Umschreiben erzeugst oder nicht.
Oh ... der originale bleibt ja doch erhalten, wenn der Umschreibprozess keinen Querystring erzeugt. QSA braucht mal also nur, wenn man selbst einen Querystring erzeugt und den vom Client dazu noch benötigt. Aber es schadet auch nicht, wenn es einfach so dasteht.
RewriteRule in Version 2.0
QSA in Version 2.2
QSA (und QSD) in Version 2.4
Das komplette Verhalten geht so richtig deutlich erst aus der 2.4er Doku im Zusammenhang mit QSD hervor. Davor hat man den "Else-Zweig" in der Erklärung weggelassen.
dedlfix.
مرحبا
» » RewriteRule . /index.php [L,QSA]
Wozu QSA? Du hast doch gar nichts notiert, was angehängt werden soll ;)
Ist ein überbleibsel aus längst vergessenen Tagen ;)
Ich nutze dieses Rewrite wirklich seit Jahren, ohne es je in frage gestellt zu haben. Vor geraumer Zeit hatte ich auch noch einen Query-String intern angehangen, bspw.:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{HTTP:Accept-Language} (.*)$
RewriteRule . /index.php?user_accept_language=%1 [L,QSA]
Da ist das QSA von übrig geblieben. Aber gut zu wissen, dass es nicht mehr benötigt wird.
mfg
Hallo,
Vor geraumer Zeit hatte ich auch noch einen Query-String intern angehangen
nein, aber vielleicht ange_hängt_.
Vgl.:
* Ich habe meine Jacke an die Garderobe gehängt, da hat sie dann tagelang gehangen.
* Rudi hat den Schlüssel dahin gelegt, wo er sonst immer gelegen hat.
Entscheidend ist, ob das Verb transitiv benutzt wird, sich also auf ein weiteres Objekt im Satz bezieht, oder intransitiv, sich also auf das Subjekt des Satzes bezieht.
Ich weiß, deutsch Sprach' schwere Sprach'.
Interessant ist, dass Fremdsprachler sich mit den Feinheiten und Ausnahmen einer Sprache oft besser auskennen als Muttersprachler. Bei dir vermute ich übrigens, dass du trotz des Migrationshintergrunds mit Deutsch aufgewachsen bist.
Schönes Wochenende,
Martin
مرحبا
Bei dir vermute ich übrigens, dass du trotz des Migrationshintergrunds mit Deutsch aufgewachsen bist.
Unter deutschsprachigen, richtig.
Seitdem ich hier im Forum bin, achte ich aber auch viel mehr darauf, als zuvor. Sowohl Schriftlich, als auch Mündlich. Danke Forum!
Der Schulischen Ausbildung habe ich es jedenfalls nicht zu verdanken, denn aus der Grundschule kenne ich nur 2 - 3 Regeln: Tunwörter klein, Namenwörter Gross, und den Rest klein. Interpunktion setze ich nach Gutdünken und Bauchgefühl ;)
Ich lasse übrigens auch nie die Rechtschreibung überprüfen, ich mach's auf gut Glück :)
mfg
hi Malcolm,
Ist ein überbleibsel aus längst vergessenen Tagen ;)
Das tut ja auch nicht weh ;)
[...] Vor geraumer Zeit hatte ich auch noch einen Query-String intern angehangen [...]
Ein:
RewriteRule ^(.*).html$ /cgi-bin/bootstrap.cgi?foo=bar [L,QSA]
würde in Perl bedeuten, dass von nun ab JEDER Request den Parameter 'foo' enthalten würde und es faktisch keine 'Requests ohne Parameter' mehr gäbe.
In PHP hingegen wird ein solches 'Anhängsel' ausgeblendet. Was sich die Entwickler dabei gedacht haben, kann ich, von der (alten Schule kommend), nicht nachvollziehen, das wird sich jedoch zeigen, wenn ich ab nächsten Monat in die Welt der PHP-Framewoks einsteige ;)
Schönen Sonntag,
ab in die Pilze,
Horst Kilzpenner
Tach!
RewriteRule ^(.*).html$ /cgi-bin/bootstrap.cgi?foo=bar [L,QSA]
würde in Perl bedeuten, dass von nun ab JEDER Request den Parameter 'foo' enthalten würde und es faktisch keine 'Requests ohne Parameter' mehr gäbe.
Das würde es für jede aufgerufene Script-Sprache bedeuten, nicht nur für Perl. (Zudem gilt die RewriteRule nicht für JEDEN Request sondern nur für solche, die auf xhtml enden, wobei das x hier für ein x-beliebiges Zeichen steht.)
In PHP hingegen wird ein solches 'Anhängsel' ausgeblendet.
Diese Aussage ist nicht richtig. Auch PHP bekommt den Querystring des umgeschriebnenen Requests übergeben, woraufhin anschließend in den üblichen Strukturen auf die Werte zugegriffen werden kann.
dedlfix.