*.img nicht umleiten

[Silly]

Hallo, ich habe unzählige Beispiele gefunden, wie man etwas umleitet, leider aber nichts wie man einzelne Dateien von der Umleitung ausschließt. Da ich wegen dieser 'Kleinigkeit' nicht weiterkomme und nicht die ganze Theorie dafür durcharbeiten möchte/kann, bitte ich Euch. obIhr mir nicht ein kleines Beispiel zeigen könnt.

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

ich habe unzählige Beispiele gefunden, wie man etwas umleitet, leider aber nichts wie man einzelne Dateien von der Umleitung ausschließt. Da ich wegen dieser 'Kleinigkeit' nicht weiterkomme und nicht die ganze Theorie dafür durcharbeiten möchte/kann, bitte ich Euch. obIhr mir nicht ein kleines Beispiel zeigen könnt.

Wäre doch höflich, wenn Du eine Begrüßung und eine Abschlussformel gefunden hättest.

Wäre auch produktiv, wenn Du außerdem deine eigenen Versuche, entsprechende Rewrite-Rules zu formulieren, entsprechende Skripte zu erstellen, oder sonstige Versuche gezeigt hättest.

• Welchen Webserver betreibst Du?
• Welche Skriptsprachen stehen Dir zur Verfügung?

In meinem "Meckerposting" stecken bereits Lösungsansätze. Finde sie! ;-P

Spirituelle Grüße
Euer Robert
[e-mail]

[Silly]

Hallo Robert, tut mir leid, wenn ich unhöflich rübergekommen bin. Vielleicht weil ich bis morgen das Problem lösen wollte. Ich soll es mit htaccess machen. Welcher Server das ist, kann ich leider nicht sagen. Aber wenn ich es in htaccess machen soll, müsste dies auf dem Server funktionieren, oder? Also jetzt mache ich mich auf die Suche nach Deinem Meckerposting. Ich nehme an, dass ich es in diesem Forum find - (ich bin neu hier). Besten Dank Silly

[Silly]

Hallo Robert, unter "Meckerposting" finde ich keinen Treffer und unter "robertroth" nur " (SERVER) Postfix SMTP Auth", mit dem ich aber nichts anfangen kann. Gruß Silly

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

Hallo Robert,

unter "Meckerposting" finde ich keinen Treffer und unter "robertroth" nur " (SERVER) Postfix SMTP Auth", mit dem ich aber nichts anfangen kann.

belaste Dich nicht mit unwesentlichen Dingen.
Nur für den Fall, dass Du noch 1 Minute für uns übrig hast: wie hast Du denn nach meinem Meckerposting gesucht?

Das sollte übrigens das obige sein, weil ich Dich angemeckert habe wegen der Unhöflichkeiten...

Spirituelle Grüße
Euer Robert
[e-mail]

[Silly]

Hi, ich habe die Begriffe über die Suche ganz oben rechts auf dieser Seite gesucht. Gruß Silly

[robertroth]

Liebe(r) Silly, liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

ich habe die Begriffe über die Suche ganz oben rechts auf dieser Seite gesucht.

Rewrite Condition versa Rewrite Rulehttp://stackoverflow.com/questions/14008003/how-to-exclude-a-specific-file-from-a-rewriterule

Aus diesem Beispiel geht hervor, wie man mittels Rewrite Rule die folgende Rewrite-Condition ignorieren lassen kann.

Spirituelle Grüße
Euer Robert
[e-mail]

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

Hallo Robert, tut mir leid, wenn ich unhöflich rübergekommen bin.

Ok, in diesem Posting leider auch mal wieder ein Beispiel für die merkwürdige Formatierung der neuen Forumssoftware...

Ich soll es mit htaccess machen. Welcher Server das ist, kann ich leider nicht sagen. Aber wenn ich es in htaccess machen soll, müsste dies auf dem Server funktionieren, oder?

Na, raten wir mal apache. Aber auch andere Server machen das Prinzip nach...

ich würde jetzt z.B. mal suchen bei der größten Datenmüllhalde der Welt:

Suchstring: "htaccess rewrite rule exclude"

Und noch ein Tipp:
Zuerst die Exclusions, dann die Treffer.

Spirituelle Grüße
Euer Robert
[e-mail]

[Silly]

Hallo Robert,

Suchstring: "htaccess rewrite rule exclude"

Tja, wenn man die richtigen Begriife angibt, Ich hatte gesucht mit "htaccess rewrite rule nicht umleiten" . Aber die jetzt gefundenen Treffer bringen mich "auf die Schnelle" nicht weiter. Die Syntax ist mir völlig neu und wie geschrieben, wegen der Zeitnot schaffe ich nicht, mich da einzuarbeiten. Dies werde ich auch so meinem "Auftraggeber" so sagen. Aber trotzdem besten Dank Silly

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

Tja, wenn man die richtigen Begriife angibt, Ich hatte gesucht mit "htaccess rewrite rule nicht umleiten" . Aber die jetzt gefundenen Treffer bringen mich "auf die Schnelle" nicht weiter. Die Syntax ist mir völlig neu und wie geschrieben, wegen der Zeitnot schaffe ich nicht, mich da einzuarbeiten.

Es wird doch schon besser :-P

Und so kurz vor dem Ziel würde ich nicht aufgeben. Du müsstest uns nur einmal deine Versuche zeigen und schon würdest Du etliche Kommentare und Verbesserungsvorschläge bekommen.

Solange halte mich an die Regeln des Forums: Hilfe zur Selbsthilfe, keine Fertiglösungen, sondern nur Links alà http://getscript.de

Spirituelle Grüße
Euer Robert
[e-mail]

[Silly]

Hi, ich habe folgendes gedacht:

RewriteEngine On
RewriteRule ^img///.* - [L]
RewriteRule ^.*$ http://www.neu.test [R=301,L]

Es soll alles umgeleitet werden außer alles im Ordner img, also img/.* In den Beispielen habe ich gesehen, das der Punkt mit / maskiert werden muss, daher auch /? Auf meinem Rechner kann ich es nicht testen. Im Internet darf ich es nicht eigenmächtig stellen. Gruß Silly

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

Hi, ich habe folgendes gedacht:

RewriteEngine On

das geht in die Hose:

RewriteRule ^img///.* - [L]

denn starten wolltest Du doch mit einer Rewrite-Condition, die auf "NICHT" prüft.

Die folgende Zeile ist ggf, noch zu unspezifiziert, denn so würden alle Requests, die an der Condition nicht scheitern, auf eine feste URL umgeleitet werden, ohne dass diese Unterschiede erkennen könnte.

RewriteRule ^.*$ http://www.neu.test [R=301,L]

siehe Apache Server Mod Rewrite

Spirituelle Grüße
Euer Robert
[e-mail]

[Sven Rautenberg]

Moin!

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

das geht in die Hose:

RewriteRule ^img///.* - [L] denn starten wolltest Du doch mit einer Rewrite-Condition, die auf "NICHT" prüft.

Wieso dies?

RewriteRule sucht nach dem Match in der URL, und wenn der matcht (und RewriteCond zutrifft), wird umgeschrieben auf das Ziel. "-" ist "nix umschreiben. Das Flag [L]: Letzte Regel, wenn diese getroffen hat, gehts nicht weiter.

Grüße Sven

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

Wieso dies?

RewriteRule sucht nach dem Match in der URL, und wenn der matcht (und RewriteCond zutrifft), wird umgeschrieben auf das Ziel. "-" ist "nix umschreiben. Das Flag [L]: Letzte Regel, wenn diese getroffen hat, gehts nicht weiter.

Es sollten alle Files umgeleitet werden (auf die eventuell weitere Regeln zutreffen), außer denen, auf die eine bestimmte Regel zutrifft.

Spirituelle Grüße
Euer Robert
[e-mail]

[Sven Rautenberg]

Moin!

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

Wieso dies?

RewriteRule sucht nach dem Match in der URL, und wenn der matcht (und RewriteCond zutrifft), wird umgeschrieben auf das Ziel. "-" ist "nix umschreiben. Das Flag [L]: Letzte Regel, wenn diese getroffen hat, gehts nicht weiter.

Es sollten alle Files umgeleitet werden (auf die eventuell weitere Regeln zutreffen), außer denen, auf die eine bestimmte Regel zutrifft.

Die Fälle, in denen DIESE Regel nicht zutrifft, werden ja auch weiter evaluiert.

Du hast die zweite RewriteRule gelesen?

Du kannst ja mal diese RewriteRule vom Zend Framework erklären, das ist dasselbe Prinzip:

        RewriteEngine On
        RewriteCond %{REQUEST_FILENAME} -s [OR]
        RewriteCond %{REQUEST_FILENAME} -l [OR]
        RewriteCond %{REQUEST_FILENAME} -d
        RewriteRule ^.*$ - [NC,L]
        RewriteRule ^.*$ /index.php [NC,L]

Grüße Sven

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

Wieso dies?

Weil es einen Unterschied zwischen Rewrite-Rule und Rewrite Condition gibt?

RewriteRule sucht nach dem Match in der URL,

ja, genau, wenn vorhergehende Rewrite-Condition zutrifft

und wenn der matcht (und RewriteCond zutrifft), wird umgeschrieben auf das Ziel. "-" ist "nix umschreiben. Das Flag [L]: Letzte Regel, wenn diese getroffen hat, gehts nicht weiter.

Spirituelle Grüße
Euer Robert
[e-mail]

[Sven Rautenberg]

Moin!

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

Wieso dies?

Weil es einen Unterschied zwischen Rewrite-Rule und Rewrite Condition gibt?

RewriteRule sucht nach dem Match in der URL,

ja, genau, wenn vorhergehende Rewrite-Condition zutrifft

FALSCH!

Der Ablauf ist so illustriert:

Beachte vor allem rechts unten: Erst wird das Matching der RewriteRule geprüft, erst danach kommen RewriteCond zum Zuge!

und wenn der matcht (und RewriteCond zutrifft), wird umgeschrieben auf das Ziel. "-" ist "nix umschreiben. Das Flag [L]: Letzte Regel, wenn diese getroffen hat, gehts nicht weiter.

Ich weiß ja auch nicht, wer mich jetzt schon zweimal downgevotet hat, aber ich vermute, das wird wieder rückgängig gemacht, wenn sich rausstellt, dass meine Aussagen technisch korrekt sind.

PS: Die eklige alte Grafik dazu sieht übrigens so aus:

Grüße Sven

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

"The RewriteCond directive defines a rule condition. One or more RewriteCond can precede a RewriteRule directive. The following rule is then only used if both the current state of the URI matches its pattern, and if these conditions are met."

Rewrite Condition:

"The RewriteRule directive is the real rewriting workhorse. The directive can occur more than once, with each instance defining a single rewrite rule. The order in which these rules are defined is important - this is the order in which they will be applied at run-time.

Pattern is a perl compatible regular expression. On the first RewriteRule, it is matched against the (%-decoded) URL-path (or file-path, depending on the context) of the request. Subsequent patterns are matched against the output of the last matching RewriteRule."

Spirituelle Grüße
Euer Robert
[e-mail]

[Sven Rautenberg]

Moin!

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

Du stimmst zu, oder du widersprichst?

"The RewriteCond directive defines a rule condition. One or more RewriteCond can precede a RewriteRule directive. The following rule is then only used if both the current state of the URI matches its pattern, and if these conditions are met."

Rewrite Condition:

Ebenda:

RewriteRule backreferences: These are backreferences of the form $N (0 <= N <= 9). $1 to $9 provide access to the grouped parts (in parentheses) of the pattern, from the RewriteRule which is subject to the current set of RewriteCond conditions. $0 provides access to the whole string matched by that pattern.

Wie kann die RewriteCond Backreferences auf die runden Klammerausdrücke des RewriteRule-Pattern haben, wenn dieser Match nicht VORHER geprüft wurde?

Grüße Sven

[MudGuard]

Hi,

ja!

Du stimmst zu, oder du widersprichst?

dieses seltsame "ja!" scheint bei ihm ein Teil der Begrüßung zu sein, das hat er in jedem seiner Postings.
Einfach ignorieren.

cu,
Andreas a/k/a MudGuard

[dedlfix]

Tach!

Du kannst ja mal diese RewriteRule vom Zend Framework erklären, das ist dasselbe Prinzip:

        RewriteEngine On
        RewriteCond %{REQUEST_FILENAME} -s [OR]
        RewriteCond %{REQUEST_FILENAME} -l [OR]
        RewriteCond %{REQUEST_FILENAME} -d
        RewriteRule ^.*$ - [NC,L]
        RewriteRule ^.*$ /index.php [NC,L]

Warum machen die das denn so umständlich mit [OR] und Extra-Regel?

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-s
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^.*$ /index.php [NC,L]

Die RewriteConds negieren, AND-verknüpfen und direkt ausschließen war wohl zu einfach oder hat die Umständlichkeit einen besonderen Hintergrund?

dedlfix.

[Sven Rautenberg]

Moin!

Tach!

Du kannst ja mal diese RewriteRule vom Zend Framework erklären, das ist dasselbe Prinzip:

        RewriteEngine On
        RewriteCond %{REQUEST_FILENAME} -s [OR]
        RewriteCond %{REQUEST_FILENAME} -l [OR]
        RewriteCond %{REQUEST_FILENAME} -d
        RewriteRule ^.*$ - [NC,L]
        RewriteRule ^.*$ /index.php [NC,L]

Warum machen die das denn so umständlich mit [OR] und Extra-Regel?

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-s
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^.*$ /index.php [NC,L]

Die RewriteConds negieren, AND-verknüpfen und direkt ausschließen war wohl zu einfach oder hat die Umständlichkeit einen besonderen Hintergrund?

Ja: Performance!

Die Zend-Vorlage ist: Alles NICHT rewriten, wenn das Ziel ein File, ein Symlink oder ein Directory ist. Ansonsten rewriten.

Deine Alternative ist: Rewriten, wenn das Ziel kein File, kein Symlink und kein Directory ist.

Dazu muss aber dreimal im Filesystem geprüft werden, drei Bedingungen werden erfolglos ausgewertet, um zu Rewriten. Bei Zend wird nur bis zur ersten Bedingung geprüft.

Grüße Sven

[dedlfix]

Tach!

Die Zend-Vorlage ist: Alles NICHT rewriten, wenn das Ziel ein File, ein Symlink oder ein Directory ist. Ansonsten rewriten.

Deine Alternative ist: Rewriten, wenn das Ziel kein File, kein Symlink und kein Directory ist.

Dazu muss aber dreimal im Filesystem geprüft werden, drei Bedingungen werden erfolglos ausgewertet, um zu Rewriten. Bei Zend wird nur bis zur ersten Bedingung geprüft.

Das klappt so aber nur unter der Annahme, dass die meisten Zugriffe auf Dateien gehen und nicht umgeschrieben werden. (Warum stehen dann Symlinks oben und nicht Dateien? Da geht auch noch ein Mikro wegzuoptimieren, wenn man keine oder kaum Symlinks hat.) Alles was aber umgeschrieben werden soll, muss fünf Bedingungen im Dateisystem abarbeiten. Dreimal erfolglos für die erste Regel und für die index.php nochmal -s und -f im zweiten Durchlauf, nach dem internen Redirect der zweiten Regel.

dedlfix.

[Sven Rautenberg]

Moin!

Tach!

Die Zend-Vorlage ist: Alles NICHT rewriten, wenn das Ziel ein File, ein Symlink oder ein Directory ist. Ansonsten rewriten.

Deine Alternative ist: Rewriten, wenn das Ziel kein File, kein Symlink und kein Directory ist.

Dazu muss aber dreimal im Filesystem geprüft werden, drei Bedingungen werden erfolglos ausgewertet, um zu Rewriten. Bei Zend wird nur bis zur ersten Bedingung geprüft.

Das klappt so aber nur unter der Annahme, dass die meisten Zugriffe auf Dateien gehen und nicht umgeschrieben werden. (Warum stehen dann Symlinks oben und nicht Dateien? Da geht auch noch ein Mikro wegzuoptimieren, wenn man keine oder kaum Symlinks hat.) Alles was aber umgeschrieben werden soll, muss fünf Bedingungen im Dateisystem abarbeiten. Dreimal erfolglos für die erste Regel und für die index.php nochmal -s und -f im zweiten Durchlauf, nach dem internen Redirect der zweiten Regel.

-s steht nicht für Symlinks, sondern für Dateien mit Größe > 0. -l steht für Symlinks.

Liest hier denn niemand mehr Doku?

Was das Optimierungspotential angeht: Für jeden Request muss man prüfen, ob es eine existente Ressource ist, die man ausliefern will, oder ob es ein virtueller Request ist, der auf die Applikation gehen soll. Also wird man möglichst nur einmal nach einem passenden File suchen, andernfalls das Rewriting auf die Applikation machen. Und genau das macht die Variante von Zend: Bei existenten Dateien wird nur exakt einmal gesucht und gefunden. Das macht das Ausliefern von existenten Ressourcen schnell. Rewriting auf die Applikation testet hingegen dreimal.

Deine Variante testet bei Rewrites auf die Applikation auch dreimal. Und bei Zugriffen auf existente Ressourcen ebenfalls.

Grüße Sven

[dedlfix]

Tach!

-s steht nicht für Symlinks, sondern für Dateien mit Größe > 0. -l steht für Symlinks.

Liest hier denn niemand mehr Doku?

Dazu hätte ich erstmal zu der Erkenntnis kommen müssen, dass meine Annahme nicht richtig ist. Ich lese nicht ständig im Handbuch nach, besonders dann nicht, wenn ich keine Zweifel verspüre. Das war nur einfach nicht genau hingeschaut. Das l hab ich als f interpretiert.

... Variante von Zend: Bei existenten Dateien wird nur exakt einmal gesucht und gefunden. Das macht das Ausliefern von existenten Ressourcen schnell. Rewriting auf die Applikation testet hingegen dreimal.

Deine Variante testet bei Rewrites auf die Applikation auch dreimal. Und bei Zugriffen auf existente Ressourcen ebenfalls.

Viermal, in beiden Fällen. Das Testen auf index.php nach dem Umschreiben musst du mitzählen.

RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ /index.php [NC,L]

RewriteCond %{REQUEST_FILENAME} !-s
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^.*$ /index.php [NC]

Aber nochmal langsam zu mitschreiben, mir kommen jetzt nämlich Zweifel auf. Variante zwei bekommt einen Request auf eine existierende Datei. Die RewriteRule passt. Die Datei hat eine Länge > 0, -s ist true, negiert ist false. Die anderen Bedingen können das Ergebnis nicht mehr ändern. Wenn sie trotzdem ausgewertet werden, ist da kein Kurzschlussverfahren eingebaut. Die Regel wird ungültig. Ende.

Variante eins bekommt einen Request auf eine existierende Datei. Die erste RewriteRule passt. Die Datei hat eine Länge > 0, -s ist true. Die anderen Bedingen können das Ergebnis nicht mehr ändern. Wenn sie trotzdem ausgewertet werden, ist da kein Kurzschlussverfahren eingebaut. Das Rewriting wird aufgrund des -(dash) und L-Flags beendet.

Wo ist da jetzt mein Denkfehler?

Zusatzfrage, warum nicht nur .* sondern ^.*$ als Muster?

Zusatzfrage zwei, warum soll bei real existierenden Dateien der Länge 0 die Applikation das Handling übernehmen? "This file intentionally left blank", die Anwendung kann keinen $handler finden und liefert 404. Wer legt denn fest, dass das stets richtig ist?

dedlfix.

[Sven Rautenberg]

Moin!

-s steht nicht für Symlinks, sondern für Dateien mit Größe > 0. -l steht für Symlinks.

Liest hier denn niemand mehr Doku?

Dazu hätte ich erstmal zu der Erkenntnis kommen müssen, dass meine Annahme nicht richtig ist. Ich lese nicht ständig im Handbuch nach, besonders dann nicht, wenn ich keine Zweifel verspüre. Das war nur einfach nicht genau hingeschaut. Das l hab ich als f interpretiert.

... Variante von Zend: Bei existenten Dateien wird nur exakt einmal gesucht und gefunden. Das macht das Ausliefern von existenten Ressourcen schnell. Rewriting auf die Applikation testet hingegen dreimal.

Deine Variante testet bei Rewrites auf die Applikation auch dreimal. Und bei Zugriffen auf existente Ressourcen ebenfalls.

Viermal, in beiden Fällen. Das Testen auf index.php nach dem Umschreiben musst du mitzählen.

Wann soll das passieren?

Nein, der umgeschriebene Request kommt nicht nochmal wieder rein und wird erneut umgeschrieben, /(oder je nach Regeln halt nicht mehr).

Aber nochmal langsam zu mitschreiben, mir kommen jetzt nämlich Zweifel auf. Variante zwei bekommt einen Request auf eine existierende Datei. Die RewriteRule passt. Die Datei hat eine Länge > 0, -s ist true, negiert ist false. Die anderen Bedingen können das Ergebnis nicht mehr ändern. Wenn sie trotzdem ausgewertet werden, ist da kein Kurzschlussverfahren eingebaut. Die Regel wird ungültig. Ende.

Variante eins bekommt einen Request auf eine existierende Datei. Die erste RewriteRule passt. Die Datei hat eine Länge > 0, -s ist true. Die anderen Bedingen können das Ergebnis nicht mehr ändern. Wenn sie trotzdem ausgewertet werden, ist da kein Kurzschlussverfahren eingebaut. Das Rewriting wird aufgrund des -(dash) und L-Flags beendet.

Wo ist da jetzt mein Denkfehler?

Zusatzfrage, warum nicht nur .* sondern ^.*$ als Muster?

Keine Ahnung.

Zusatzfrage zwei, warum soll bei real existierenden Dateien der Länge 0 die Applikation das Handling übernehmen? "This file intentionally left blank", die Anwendung kann keinen $handler finden und liefert 404. Wer legt denn fest, dass das stets richtig ist?

Vermutlich ist es sinnlos, existierende Dateien mit Null Bytes Länge als Ressourcen anzubieten. Warum sollte man dies tun?

Zum "Füllen" von Lücken, sprich "vermeintlich fehlenden index.html-Seiten" braucht man keine Null-Byte-Dateien erzeugen, sondern hat das Rewriting auf die Applikation, die sich damit auseinandersetzt und eine schöne 404-Seite rendern wird.

Grüße Sven

[dedlfix]

Tach!

Nein, der umgeschriebene Request kommt nicht nochmal wieder rein und wird erneut umgeschrieben, /(oder je nach Regeln halt nicht mehr).

Dann würde aber deine Rewrite-Grafik nicht stimmen.

Aber nochmal langsam zu mitschreiben, mir kommen jetzt nämlich Zweifel auf. Variante zwei bekommt einen Request auf eine existierende Datei. Die RewriteRule passt. Die Datei hat eine Länge > 0, -s ist true, negiert ist false. Die anderen Bedingen können das Ergebnis nicht mehr ändern. Wenn sie trotzdem ausgewertet werden, ist da kein Kurzschlussverfahren eingebaut. Die Regel wird ungültig. Ende.

Variante eins bekommt einen Request auf eine existierende Datei. Die erste RewriteRule passt. Die Datei hat eine Länge > 0, -s ist true. Die anderen Bedingen können das Ergebnis nicht mehr ändern. Wenn sie trotzdem ausgewertet werden, ist da kein Kurzschlussverfahren eingebaut. Das Rewriting wird aufgrund des -(dash) und L-Flags beendet.

Wo ist da jetzt mein Denkfehler?

Blieb unbeantwortet.

Zusatzfrage zwei, warum soll bei real existierenden Dateien der Länge 0 die Applikation das Handling übernehmen? "This file intentionally left blank", die Anwendung kann keinen $handler finden und liefert 404. Wer legt denn fest, dass das stets richtig ist?

Vermutlich ist es sinnlos, existierende Dateien mit Null Bytes Länge als Ressourcen anzubieten. Warum sollte man dies tun?

Sicher ist es sinnlos, eine solche Datei auszuliefern. Aber welchen Sinn ergibt es, deswegen die Applikation damit zu belasten? Das macht gefühlt mehr Last als dem Apachen das Ausliefern zu gestatten. Zudem ergibt die leere Datei auszuliefern den Status 200 im Gegensatz zu 404. Das kann durchaus zu Fehlverhalten führen.

Manchmal ist es praktisch, wenn man eine solche Datei hat, in die man bei Bedarf was reinschreiben kann (CSS-Regeln, Javascript, sowas). Natürlich ist es besser, in der Anwendung auf die Leere zu prüfen und den Link nur bei Bedarf einzubauen. Aber manchmal läuft es in der Praxis anders als es in der Theorie am besten ist. Ich sehe es jedenfalls nicht als Aufgabe des Frameworks an, sich meinen Kopf zu zerbrechen und über das Ausliefern von vorhandenen aber leeren Dateien zu entscheiden.

„The following rule tells Apache that if the requested filename exists, simply serve it.“ steht in der .htacces, und ist nicht richtig. Oder zählt eine Datei mit Länge 0 zu nicht existierend? Ich stufe das als unerwartetes und undokumentiertes Verhalten ein.

dedlfix.

[dedlfix]

Tach!

Das Flag [L]: Letzte Regel, wenn diese getroffen hat, gehts nicht weiter.

An dieser Stelle wird gern unterschlagen oder nicht gewusst, dass dieses Nicht-weiter-gehen nur vorläufigen Charakter hat. Der Request wird nämlich nach dem Umschreiben nochmal neu durch den URL-Auflöseprozess des Apachen geschickt. Und der kommt unter Umständen wieder an diesen Regeln vorbei. Wenn der grad in einem Unterverzeichnis ist und die Regeln vom übergeordneten Verzeichnis anwendet, dann ist img/ in der URL nicht mehr da (das Directory-Prefix wird beim Umschreiben entfernt) und diese Nicht-Regel zieht nicht mehr. (Der letzte Satz ist meinerseits nur vermutet, nicht nachgeprüft. Was aber stimmt ist, dass das L nicht absolut „Letzte Regel“ bedeutet.)

dedlfix.

[MudGuard]

Hi,

Es soll alles umgeleitet werden außer alles im Ordner img, also img/.* In den Beispielen habe ich gesehen, das der Punkt mit / maskiert werden muss,

Sicher? Normalerweise eigentlich mit dem Backslash \ - nicht mit den Slash /.

cu,
Andreas a/k/a MudGuard

[Sven Rautenberg]

Moin!

Bevor die Diskussion über die Auswertungsreihenfolge ausartet, einschläft oder entschieden wird, mach ich lieber mal hier weiter:

ich habe folgendes gedacht:

RewriteEngine On
RewriteRule ^img///.* - [L]
RewriteRule ^.*$ http://www.neu.test [R=301,L]

Prima, eine Vorlage!

Nach meiner Auffassung ist daran nicht viel verkehrt, allenfalls beim eigentlichen regulären Ausdruck für das img-Verzeichnis wäre ich mir ohne Test unsicher.

Allerdings ist das kaum notwendig, denn man kann diesen Ausdruck kürzen. Du suchst: "img/", dahinter "irgendwas", und das hast du in Regex-Schreibweise als ".*" korrekt formuliert. Aber weil du mit diesem Teil ja absolut nichts machst, kann man es auch weglassen, denn der Regex ist nach hinten nicht mit einem "$" begrenzt.

"^img/.*" ist dasselbe wie "^img/".

Da es unpraktisch ist, wenn man die Schrägstriche, die in URLs recht häufig vorkommen, im Regex escapen müsste, gehe ich davon aus, dass das tatsächlich überflüssig ist, und bei deinem Versuch falsch.

Es soll alles umgeleitet werden außer alles im Ordner img, also img/.*

Alles, was mit "img/" anfängt. Anfang = in Regex "^".

In den Beispielen habe ich gesehen, das der Punkt mit / maskiert werden muss, daher auch /?

Punkte muss man in Regexen maskieren, wenn man "den Punkt" sucht, und nicht die Sonderfunktion des Punktes in Regexen für "alle beliebigen Zeichen" haben will.

Auf meinem Rechner kann ich es nicht testen.

Das ist schlecht, würde viele Fragen schneller beantworten.

Im Internet darf ich es nicht eigenmächtig stellen.

Das ist vermutlich eine nicht ganz so dumme Idee.

Wenn deine .htaccess-Datei kaputt ist, antwortet der Apache mit Fehlerstatus 500. Das merkst du sofort. Das Einspielen der alten Datei sollte das Problem auch sofort wieder beheben.

Ob die Bilder wie gewünscht nicht umgeleitet werden, solltest du auch recht einfach testen können - es empfiehlt sich die Firefox-Extension Firebug und dort der Net-Tab.

Grüße Sven

[Silly]

Hallo, wie kann eine Anfängerin an einem Abend ohne Testmöglichkeit eine .htaccess erstellen, die alles umleitet außer alle Dateien *.img, genauer alle Dateien im Ordner img (der nur *.img-Dateien enthält), wenn hier die Experten kontrovers über die Lösung diskutieren. Was nun die einfachste Lösung ist, konnte ich nicht erkennen. Aber vielleicht könnt Ihr (für meine Boss) bestätigen, dass diese Aufgabe unter den genannten Bedingungen nicht lösbar war. Besten Dank Silly

[dedlfix]

Tach!

wie kann eine Anfängerin an einem Abend ohne Testmöglichkeit eine .htaccess erstellen, die alles umleitet außer alle Dateien *.img, genauer alle Dateien im Ordner img (der nur *.img-Dateien enthält), wenn hier die Experten kontrovers über die Lösung diskutieren. Was nun die einfachste Lösung ist, konnte ich nicht erkennen.

Der gängigste Lösungsweg ist, alles was real existiert von der Umschreiberei auszuschließen. Ist es bei dir wirklich so, dass nur img nicht umgeschrieben werden soll und ansonsten alles was da noch so rumliegt nicht ausgeliefert werden soll? Oder kann man dein Problem auf alles existierende verallgmeinern? In dem Fall wäre die Lösung bereits genannt worden.

dedlfix.

[Silly]

Hallo

Ist es bei dir wirklich so, dass nur img nicht umgeschrieben werden soll und ansonsten alles was da noch so rumliegt nicht ausgeliefert werden soll? Oder kann man dein Problem auf alles existierende verallgmeinern?

"Nicht umgeschrieben", "nicht ausgeliefert"? Für mich verwirrend.

Ich würde es so formulieren: Alles außer die Elemente im Ordner img (im Root) sollen umgeleitet werden zu www.neu.test. Und wie Sven Rautenberg schrieb, glaube ich jetzt, dass dies:

RewriteEngine On

RewriteRule ^img/ - [L]

RewriteRule ^.*$ http://www.neu.test [R=301,L]

eine der kürzesten Lösung ist.

Schönen Gruß

Silly

[dedlfix]

Tach!

"Nicht umgeschrieben", "nicht ausgeliefert"? Für mich verwirrend.

Rewrite = Umschreiben. Das Rewrite-Modul soll vor allem eine URL so umschreiben, dass am Ende der Name einer Datei entsteht, die der Webserver in Richtung Browser ausliefern soll (oder ausführen, beispielsweise im Falle PHPs).

Alles außer die Elemente im Ordner img (im Root) sollen umgeleitet werden zu www.neu.test.

Gibt es noch weitere Dateien oder Ordner in dem Verzeichnis, die da einfach nur so rumliegen und nicht ausgeliefert werden sollen, oder ist img das einzige Verzeichnis, das da vorhanden ist?

Und wie Sven Rautenberg schrieb, glaube ich jetzt, dass dies:

RewriteEngine On
RewriteRule ^img/ - [L]
RewriteRule ^.*$ http://www.neu.test [R=301,L]

In deinem Falle ja, denn es findet kein Umschreiben sondern eine Weiterleitung zu einer anderen URL statt. Man kann aber auch mit RewriteCond das nicht umzuschreibende ausschließen, besonders dann, wenn das Ziel des Umschreibens im selben Verzeichnis liegt. (Anwendungsfall: Gib alles an die index.php außer dem Kram, der als Datei rumliegt (CSS, Javascript, Bilder, Fonts)).

dedlfix.

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

wie kann eine Anfängerin an einem Abend ohne Testmöglichkeit eine .htaccess erstellen, die alles umleitet außer alle Dateien *.img, genauer alle Dateien im Ordner img (der nur *.img-Dateien enthält), wenn hier die Experten kontrovers über die Lösung diskutieren.

Wieso hast Du keine Testmöglichkeit? Hast Du keinen PC oder Laptop? Ein XAMPP ist schnell installiert und ein notepad++ auch. Damit hast Du dann schon alle Testmöglichkeiten, die Du benötigst

Spirituelle Grüße
Euer Robert
[e-mail]