echo $begrüßung;
Mh, versteh ich nicht ganz, aber bedeutet scheints, dass
.* index.php [L] öfter die Schleife durchläuft.
Der Apache ist mit dem Analysieren des Requests schon fast fertig, wenn er aus eine .htaccess trifft. Er hat bereits aus der URL einen Dateinamen ermittelt, denn sonst wüsste er ja auch nicht, welche .htaccess zuständig ist. Und nun kommt da Rewrite-Zeug drin vor, was auf die bereits ad acta gelegte URL zugreift und das bereits erledigte Dateinamenermitteln nochmal durchführen will. Das funktioniert nur, indem mod_rewrite nach seiner Umschreiberei einen internen Redirect auslöst. Und diesen wertet der Apache wieder von vorn an aus.
Also
RewriteCond "wenn die Datei nicht existiert, dann mach..." ?Und wenn dann nur eine index.php existiert (oder eine rewrite.php) und sonst keine, dann wird eben dann nicht mehr umgeschrieben, wenn auf diese bereits umgeleitet wurde. Hätte auch den Vorteil, dass eingebundene Bilder oder CSS-Files nicht weiter behellligt bzw. ungewollt umgeschrieben würden.
Genauso ist es. Konkret sieht das so aus:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRules beachten außerdem den Querystring nicht.[...]
Na, gut nochmal zur Erinnerung, aber auf den wollte ich u.U. verzichten bzw. war mir klar, dass der erstmal in der URL keine Rolle spielen würde.
Gut, du hast mich erfolgreich irritiert, weil da was mit Querystring oben stand. Das hab ich wohl unterbewusst als Ausgangswert statt als Ergebnis behandelt.
Eigentlich dachte ich, example.com/contact example.com/news example.com/imprint u.s.w. auf eine Datei umzuleiten und dort dann mit einem switch den content auszugeben.
Alternative wäre halt example.com?content=contact etc., was irgendwie simpler wäre, weil dann der switch direkt mit $_GET["content"] gebaut werden könnte. Irgendwie dachte ich halt, die o.g. Variante wäre "cooler".
Der Möglichkeiten gibt es mehrere. Eine wäre
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php/$1 [L,QSA]
und im Script PATH_INFO auswerten. Der Querystring bleibt erhalten und kann bei Bedarf anderweitig genutzt werden.
Das Wichtigste sind die beiden RewriteCond-Zeilen. Dadurch wird beim ersten Redirect auf die index.php die Rule außer Kraft gesetzt und das Rewriten beendet. Zu deinem beobachteten Verhalten nehme ich an, dass durch die internen Redirects dein angehängter Querystring beim zweiten Durchlauf verworfen wurde, wie das halt bei Querystrings ohne QSA-Flag so üblich ist. abc=def wurde ja jedes mal erneut angehängt. Mit QSA sollte dein Querystring länger werden als dir lieb ist.
Noch ein Detail, das ich schon wieder vergessen hatte: Wenn das Umschreibziel im selben Verzeichnis liegt (also nicht mit einer Pfadangabe beginnt), gibt es keine Endlosschleife plus Fehlermeldung. Dieser Fall wird erkannt und das Rewriten beendet.
echo "$verabschiedung $name";