gudn tach!
RedirectMatch ^/bar(|/.*)$ /foo/bar$1
da wird für den Client (Browser) kein Redirect zur neuen URL gefordert. Laut Dokumentation fehlt da ein [R] dahinter.
hmm, entweder steh ich auf dem schlauch oder du hast dich verlesen.
du hast ja jetzt die erste zeile von mir zitiert und da handelt es sich ja nicht um einen rewrite, sondern um einen redirect, und bei "RedirectMatch" gibt's meines wissens nicht die flags, die es bei rewrites gibt (also [R], [L], [PT], etc.). "[R]" ist ja nur bei rewrites sinnvoll, um jene als redirects zu benutzen. bei zeilen, die an sich schon redirects sind, waere das [R] ja ueberfluessig (und vermutlich sogar ein syntaxfehler). oder nicht?
Sonst versucht nur der Server die alte Adresse intern als neue zu verstehen, die dann in der nächsten Zeile wieder zurückmodifiziert wird - und Du hast Deine von Dir beschriebene Schleife.
die haette ich (so war zumindest mein plan und gedanke) nur, wenn ich zwei rewrites oder zwei redirects verwenden wuerde.
Du müsstest also durch eine passende RewriteCondition dafür sorgen, dass der Request nach der Zeile fertig beantwortet ist.
RewriteCond %{REQUEST_URI} ^/bar/.*$
RewriteRule ^(/bar.*) /foo$1 [R]
RewriteCond %{REQUEST_URI} ^/foo/bar/.$
RewriteRule ^/foo(/bar.) ^$1
>
> Obiger Code ist ungetestet, könnte aber aus Versehen so passen.
ah, ok, richtig. mit der condition kaeme ich um das loop-problem wohl ganz gut drumherum. wuerde der code
~~~apache
RedirectMatch ^(/bar.*) /foo$1
RewriteCond %{REQUEST_URI} ^/foo/bar/.*$
RewriteRule ^/foo(/bar.*) ^$1
etwa das gleiche tun?
(dass du andere regexps gewaehlt hast, die mehr matchen, als ich wollte, soll jetzt mal egal sein; ich hatte den relativ komplizierten regexp absichtlich genutzt, um nur "/bar" und "/bar/irgendwas", aber nicht /barirgendwas zu matchen.)
bei einem redirect wird im gegensatz zu einem rewrite die ganze redirect-rewrite-kette wegen des neuen client-requests von neuem abgearbeitet, oder? falls ja, gilt das fuer "RedirectMatch" genauso wie fuer "RewriteRule ... [R]"?
prost
seth