Modrewrite vom Root in ein Unterverzeichnis

[BrumBrum]

Hallo

kurz erklärt, ich generiere in einem Unterverzeichnis meinen RSS Feed, und möchte ihn für Nutzer gerne aus schönheitsgründen aus dem Root verzeichnis meiner Seite anbieten.
Die einfachste Sache ist (so dachte ich) das Rewrite Modul von Apache zu nutzen um eine entsprechende Datei im Rootverzeichnis vor zu gaugeln.
Doch weit gefehlt der Apache weigert sich schon seit Stunden.

Folgende Fakten sind vorhanden:
RSS Quelle: domain.de/unterverzeichnis1/unterverzeichnis2/rssfeed.xml
soll: domain.de/rssfeed.xml

Versuch:
RewriteRule ^/rssfeed.xml$ /unterverzeichnis1/unterverzeichnis2/rssfeed.xml
bzw:
RewriteRule ./rssfeed.xml$ ./unterverzeichnis1/unterverzeichnis2/rssfeed.xml

Alles ohne Wirkung, HILFE...

Danke

BrumBrum

[Malcolm Beck´s]

hi,

bei mir funktioniert folgende Rewrite-Rule:

RewriteEngine on
RewriteRule ^(feed)$     /conigs/feed.php [L,NC,QSA]

Aufruf:
example.org/feed

mfg

[Sven Rautenberg]

Moin!

bei mir funktioniert folgende Rewrite-Rule:

RewriteEngine on
RewriteRule ^(feed)$     /conigs/feed.php [L,NC,QSA]

Aufruf:
example.org/feed

Wobei du die Klammern um (feed) weglassen kannst, da du ja keinerlei Backreferenz benutzt. Das spart ein wenig Aufwand beim Regex.

Auch die Parameter [L,NC,QSA] sind nicht zwingend notwendig.

L sorgt dafür, dass das Rewriting an dieser Stelle dann endet, wenn es Erfolg hatte, und die erzeugte URL nicht in nachfolgenden Regeln noch weiter verändert wird. Kann man so machen, muss man nicht zwingend.

NC sorgt für case-insensitiven Regex. Damit werden auch alle URLs, die "feed" mit Großbuchstaben schreiben, umgeschrieben. Ist das notwendig?

QSA hängt den Query-String, der aus der Rewrite-Rule erwächst, an den bestehenden Query-String an, anstatt diesen zu ersetzen. Da hier kein Query-String erzeugt wird, ist diese Option eigentlich auch überflüssig.

- Sven Rautenberg

[Malcolm Beck´s]

hi,

Wobei du die Klammern um (feed) weglassen kannst, da du ja keinerlei Backreferenz benutzt. Das spart ein wenig Aufwand beim Regex.

Danke für den Tipp; ich habe leider noch so meine schwierigkeiten mit Regexen.

Auch die Parameter [L,NC,QSA] sind nicht zwingend notwendig.

Irgendwas muss man wohl hinter die Rewriterule schreiben, da es ohne, bei mir zumindest, nicht geht.
Gerade mal mit

RewriteRule ^robots.txt$  /configs/files/robots.txt

getestet, passiert aber nichts, bzw. bekomme ich einen 404er.

L sorgt dafür, dass das Rewriting an dieser Stelle dann endet, wenn es Erfolg hatte, und die erzeugte URL nicht in nachfolgenden Regeln noch weiter verändert wird. Kann man so machen, muss man nicht zwingend.

Meinst du mit "nicht in nachfolgenden Regeln noch weiter verändert wird" weiteres Rewriten in der .htaccess? Über PHP kann ich ja die URI weiterhin bearbeiten bzw. noch Parameter anhängen, um mit diesen weiter zu arbeiten.

NC sorgt für case-insensitiven Regex. Damit werden auch alle URLs, die "feed" mit Großbuchstaben schreiben, umgeschrieben. Ist das notwendig?

Bringt es denn Nachteile mit sich? IMPRESSUM und impressum sind doch so gesehen Identisch, warum dann bei Gross geschriebenem einen 404er melden?

QSA hängt den Query-String, der aus der Rewrite-Rule erwächst, an den bestehenden Query-String an, anstatt diesen zu ersetzen. Da hier kein Query-String erzeugt wird, ist diese Option eigentlich auch überflüssig.

Ah, ich dachte die ganze Zeit, dass QSA das interne arbeiten mit Parametern ermöglicht (?key=wert;usw=usf).

Jetzt habe ich meine .htaccess mal bereinigt, allerdings komme ich um mindestens eine Einstellung nach der Rewriterule nicht drum rum.
Hier habe ich auf anhieb auch nichts finden können, werde mir das nochmal in Ruhe durchlesen.

mfg

[ChrisB]

Hi,

Auch die Parameter [L,NC,QSA] sind nicht zwingend notwendig.

Irgendwas muss man wohl hinter die Rewriterule schreiben, da es ohne, bei mir zumindest, nicht geht.
Gerade mal mit

RewriteRule ^robots.txt$  /configs/files/robots.txt

getestet, passiert aber nichts, bzw. bekomme ich einen 404er.

Das kann noch von weiteren Bedingungen abhängen, die wir nicht kennen.

L sorgt dafür, dass das Rewriting an dieser Stelle dann endet, wenn es Erfolg hatte, und die erzeugte URL nicht in nachfolgenden Regeln noch weiter verändert wird. Kann man so machen, muss man nicht zwingend.

Meinst du mit "nicht in nachfolgenden Regeln noch weiter verändert wird" weiteres Rewriten in der .htaccess? Über PHP kann ich ja die URI weiterhin bearbeiten bzw. noch Parameter anhängen, um mit diesen weiter zu arbeiten.

PHP hat hier nichts mit zu tun.

Ein hereinkommender Request durchläuft alle RewriteRules der Reihe nach. Wenn man das nicht möchte - entweder, weil man nicht möchte, dass diese an der gerade umgeschriebenen Adresse erneut wieder was ändern, oder weil man weiss, dass der ganze Rattenschwanz nachfolgender Regeln nicht mehr zutreffen wird, und deshalb deren Überprüfung nur unnötig Rechenpower frisst - dann kann man mit dem Flag [L] angeben, dass die nachfolgenden Regeln nicht mehr angewandt werden sollen.
Wobei das nur für den aktuellen Rewrite-Durchgang gilt - wenn man das Rewriting in .htaccess konfiguriert, dann behandelt der Apache einen gerade umgeschriebenen Request wie einen neu hereinkommenden, und wendet das komplette Regelset darauf erneut an - *das* zu beeinflussen, dafür ist [L] *nicht* ge(m|d)acht.

NC sorgt für case-insensitiven Regex. Damit werden auch alle URLs, die "feed" mit Großbuchstaben schreiben, umgeschrieben. Ist das notwendig?

Bringt es denn Nachteile mit sich? IMPRESSUM und impressum sind doch so gesehen Identisch, warum dann bei Gross geschriebenem einen 404er melden?

Weil Ressourcen unter einem, eindeutigen Namen erreichbar sein sollten - und nicht unter zig davon bzw. unter "allen möglichen Kombinationen" aus Gross- und Kleinschreibung.
(Hier kann man natürlich scriptseitig entsprechend reagieren - und die fehlerhaften Anfragen auf /Impressum, /iMprESSum etc. alle auf /impressum umleiten lassen, permanent/301 natürlich.)

Ah, ich dachte die ganze Zeit, dass QSA das interne arbeiten mit Parametern ermöglicht (?key=wert;usw=usf).

Nein, es fügt wie Sven sagte nur den originalen Querystring wieder an - das kann man dann benutzen, wenn man einen (evtl.) original vorhandenen solchen lediglich erweitern möchte. Per Default, ohne dieses Flag, wird er nämlich "weggeschmissen".

Jetzt habe ich meine .htaccess mal bereinigt, allerdings komme ich um mindestens eine Einstellung nach der Rewriterule nicht drum rum.

Wie gesagt, aus dem bisher geposteten ist nicht erkennbar, warum das so sein sollte.

MfG ChrisB

[Malcolm Beck´s]

hi,

» RewriteRule ^robots.txt$  /configs/files/robots.txt

Das kann noch von weiteren Bedingungen abhängen, die wir nicht kennen.

http://dj-tut.de/z_test/selfhtml/htaccess -- So sieht meine Komplette .htaccess aus
Ich weiß nicht warum, aber ohne einen Flag am Ende der Rewriterule funktioniert bei mir das Rewriten nicht.

Ein hereinkommender Request durchläuft alle RewriteRules der Reihe nach. Wenn man das nicht möchte - entweder, weil man nicht möchte, dass diese an der gerade umgeschriebenen Adresse erneut wieder was ändern, oder weil man weiss, dass der ganze Rattenschwanz nachfolgender Regeln nicht mehr zutreffen wird, und deshalb deren Überprüfung nur unnötig Rechenpower frisst - dann kann man mit dem Flag [L] angeben, dass die nachfolgenden Regeln nicht mehr angewandt werden sollen.

Danke für die Erklärung.

Weil Ressourcen unter einem, eindeutigen Namen erreichbar sein sollten - und nicht unter zig davon bzw. unter "allen möglichen Kombinationen" aus Gross- und Kleinschreibung.

Das ist ein durchschlagendes Argument ;)

(Hier kann man natürlich scriptseitig entsprechend reagieren - und die fehlerhaften Anfragen auf /Impressum, /iMprESSum etc. alle auf /impressum umleiten lassen, permanent/301 natürlich.)

Das werde ich gleich heute Abend mal in Angriff nehmen, dürfte ja nicht allzu schwer sein.

Nein, es fügt wie Sven sagte nur den originalen Querystring wieder an - das kann man dann benutzen, wenn man einen (evtl.) original vorhandenen solchen lediglich erweitern möchte. Per Default, ohne dieses Flag, wird er nämlich "weggeschmissen".

Das verstehe ich immer noch nicht, könntest du mir das Bitte Anhand eines Beispiels erklären?

RewriteRule ^highlight$  /css/highlight.php [QSA] # wo muss hier der Querystring stehen für dieses Flag?

mfg

[ChrisB]

Hi,

http://dj-tut.de/z_test/selfhtml/htaccess -- So sieht meine Komplette .htaccess aus
Ich weiß nicht warum, aber ohne einen Flag am Ende der Rewriterule funktioniert bei mir das Rewriten nicht.

Kann dir spontan auch nicht sagen, warum. Die Logs könnten vielleicht weitere Rückschlüsse zulassen, insb. das RewriteLog (muss in der httpd.conf aktiviert werden, deshalb am besten auf einem lokalen Rechner zu testen).

Nein, es fügt wie Sven sagte nur den originalen Querystring wieder an - das kann man dann benutzen, wenn man einen (evtl.) original vorhandenen solchen lediglich erweitern möchte. Per Default, ohne dieses Flag, wird er nämlich "weggeschmissen".

Das verstehe ich immer noch nicht, könntest du mir das Bitte Anhand eines Beispiels erklären?

RewriteRule ^highlight$  /css/highlight.php [QSA] # wo muss hier der Querystring stehen für dieses Flag?

Er muss in dem Request vorhanden sein, der den Server erreicht hat.

Nehmen wir an, du willst eine Anfrage nach
/NichtExistentesDokument.htm
umschreiben lassen auf
/index.php?seitenname=NichtExistentesDokument.htm

Mit sowas wie
RewriteRule ^(.*)$ index.php?seitenname=$1
bekommst du im Querystring immer nur den einen Parameter seitenname übermittelt.

Vielleicht willst du aber auch Aufrufe wie
/NichtExistentesDokument.htm?blah=blubb&laber=quassel
zulassen, um über diese Parameter scriptintern den weiteren Ablauf zu steuern. Diese Parameter würden dir bei obiger RewriteRule verloren gehen, du würdest nach wie vor nur seitenname=NichtExistentesDokument.htm bekommen.

Wenn du jetzt das Flag [QSA] verwendest, dann wird der originale QueryString beibehalten, d.h. dein Request wird letztlich auf
/index.php?seitenname=NichtExistentesDokument.htm&blah=blubb&laber=quassel
umgeschrieben, so dass du auch diese Parameter in deinem auswertenden Script noch zur Verfügung hast.

MfG ChrisB

[Malcolm Beck´s]

hi,

erstmal Danke euch allen für die ausführlichen Erklärungen, jetzt habe ich es mit dem QSA soweit verstanden.

Kann dir spontan auch nicht sagen, warum. Die Logs könnten vielleicht weitere Rückschlüsse zulassen, insb. das RewriteLog (muss in der httpd.conf aktiviert werden, deshalb am besten auf einem lokalen Rechner zu testen).

Bei meinem Hoster (1&1) ist RewriteLog deaktiviert, leider. Ich werde es heute Abend auf meiner Kiste testen, auf diesem Rechner habe ich keinen Apache.

Ich werde mich heute Abend hier wieder einklinken und alles noch mal durchtesten.

mfg

[globe]

n'abend,

Ich weiß nicht warum, aber ohne einen Flag am Ende der Rewriterule funktioniert bei mir das Rewriten nicht.

Das wird aber nicht "an irgendeinem" Flag liegen, sondern am [L]. Welches in deinem Fällen durchaus seinen Sinn hat.

Mit RewriteLog kannst du dir protokollieren lassen, was mod_rewrite mit einer Anfrage anstellt. Vielleicht erkennst du da was mit einer Anfrage an /favicon.ico beim "index.php"-Rewrite (resp. den RewriteConditions davor) passiert, wenn du die [L] weg lässt.

»» Nein, es fügt wie Sven sagte nur den originalen Querystring wieder an - das kann man dann benutzen, wenn man einen (evtl.) original vorhandenen solchen lediglich erweitern möchte. Per Default, ohne dieses Flag, wird er nämlich "weggeschmissen".

Das verstehe ich immer noch nicht, könntest du mir das Bitte Anhand eines Beispiels erklären?

RewriteRule ^highlight$  /css/highlight.php [QSA] # wo muss hier der Querystring stehen für dieses Flag?

Nirgends. [QSA] steht für QueryStringAppend und bewirkt, dass der QS der Originalanfrage and das Ergebnis deines Rewrites angehängt wird. Wenn du in deinem Rewrite werte im QS anhängen willst, ohne die ursprünglichen Werte der Anfrage zu berücksichtigen, brauchst du [QSA] nicht angeben.

Mit [QSA] machst du aber nicht viel kaputt. Ich hänge [QSA] zwischenzeitlich an jede RewriteRule an, um etwaige "warum kommt denn der Verdammte QueryString nicht an?" zu vermeiden.

Die ganzen Optionen kannst du übrigens in RewriteRule nachschauen. Dort gibt es auch Beispiele zur Veranschaulichung.

Eine wichtige Option ist übrigens [R]. Das steht für Redirect. Apache sendet dann einen 302 Moved Temporarily als Antwort auf den Request. Das bewirkt schlussendlich, dass der Client nochmal unter der richtigen URL nachschaut. Wird das [R] weggelassen, wird der Rewrite lediglich intern betrachtet. Der Client bekommt vom ganzen Rewriting dann nichts mit.

weiterhin schönen abend...

[Der Martin]

Hallo,

»» Nein, es fügt wie Sven sagte nur den originalen Querystring wieder an - das kann man dann benutzen, wenn man einen (evtl.) original vorhandenen solchen lediglich erweitern möchte. Per Default, ohne dieses Flag, wird er nämlich "weggeschmissen".
Das verstehe ich immer noch nicht, könntest du mir das Bitte Anhand eines Beispiels erklären?

du möchtest ein Beispiel? Also gut, nehmen wir einen Ausschnitt aus einer .htaccess von mir:

~~~apache RewriteEngine on
  RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule ^(.*) index.php?page=$1  [QSA,L]

  
Hier wird zunächst die Bedingung gestellt, dass der Request \*nicht\* auf eine existierende Datei oder ein existierendes Verzeichnis passen darf. Dann wird jeder Request /foo/bar auf index.php?page=/foo/bar umgeschrieben. Bis hierher ist das QSA-Flag noch unerheblich.  
Aber jetzt ruft jemand  
  
  /foo/bar?param=12  
  
auf. Ohne das QSA-Flag würde dieser Parameter ignoriert, weil durch die Rewrite Rule ein komplett neuer Query-String generiert wird. Mit diesem Flag wird der Query-String aus dem ursprünglichen Request aber wieder angehängt, so dass der Request intern auf  
  
  /index.php?page=/foo/bar&param=12  
  
landet. So kann ich also trotz der rewrite-Aktion noch URL-Parameter von außen übergeben, wenn ich das möchte.  
  
So long,  
 Martin  

-- 
Der Alptraum jedes Computers:  
"Mir war, als hätte ich gerade eine 2 gesehen."

[Malcolm Beck´s]

hi,

» (Hier kann man natürlich scriptseitig entsprechend reagieren - und die fehlerhaften Anfragen auf /Impressum, /iMprESSum etc. alle auf /impressum umleiten lassen, permanent/301 natürlich.)

Das werde ich gleich heute Abend mal in Angriff nehmen, dürfte ja nicht allzu schwer sein.

Done ;)

if ($_SERVER['REQUEST_URI'] != strtolower($_SERVER['REQUEST_URI'])) {  
  header("HTTP/1.1 301 Moved Permanently");  
  header("Location: http://" . $_SERVER['HTTP_HOST'] . strtolower($_SERVER['REQUEST_URI']));  
}

Diese Bedingung rufe ich nur auf, wenn es Inhalte zu der aufgerufenen Seite gibt.

Das mit dem RewriteLog habe ich noch nicht in den Griff bekommen, da muss ich noch ein wenig Recherchieren.

mfg