nicht angemeldet
URI-Umbenennung mit mod_rewrite: Verwirrung groß ...
Hallo,
ich bin gerade ziemlich verwirrt: Ich habe bislang mod_rewrite dazu benutzt, um benutzer- und suchmaschinen-freundliche URI zu erstellen, in etwa so:
RewriteRule ^interessant/toll-zu-merken$ pfad-zu-allen-seiten/langweilig.php
Im Browser konnte ich dann eingeben:
http://www.domain.de/interessant/toll-zu-merken und die Seite mit dem langweiligen Dateinamen wurde aufgerufen (sehr einfach gehalten das Beispiel ...). Um den Umzug der Seite mitzuteilen, habe ich dann noch ein R=301 eingebaut (s. früheres Posting, klappt jetzt).
Nun habe ich mir gerade mal access.log und error.log angeschaut. Oh jeh! Fehlermeldung und keine 301-Meldung. Dann habe ich es mit absoluter URI rechts versucht, also in etwa so:
RewriteRule ^interessant/toll-zu-merken$ http://www.domain.de/pfad-zu-allen-seiten/langweilig.php
Oh Wunder, keine Fehlermeldung mehr, korrekte 301-Meldung. Aber: In der Adresszeile steht nun die "echte" URI, also mit dem langweiligen Dateinamen!
Ist die ganze Geschichte mit dem URI-Rewriting also eigentlich nur ein Trick, der zu Fehlermeldungen führt? Das dürfte jede error.log dieser Welt ja unerträglich aufblähen. Und: Wie setzte ich eine korrekte 301-Meldung bzw. wie überprüfe ich deren Wirksamkeit?
Vielen Dank für jedes (produktive) Posting! (Ich hoffe ich bekomme auf diese Frage mal eine Antwort ... War in letzter Zeit eher selten der Fall.) Grüße, luti
-
Hi,
Um den Umzug der Seite mitzuteilen, habe ich dann noch ein R=301 eingebaut
also dem Client gesagt, welche neue URL er statt der alten anfordern und auf günstigem Wege - beispielsweise über die Adressleiste des Browsers - seinem Nutzer mitteilen soll.
(s. früheres Posting, klappt jetzt).
Welches frühere Posting? Warum knüpfst Du nicht dort an? Warum verlinkst Du nicht mal zu dem Kontext?
Fehlermeldung und keine 301-Meldung.
Und der Grund, warum Du uns sowohl die Fehlermeldung als auch dessen Ursache - lies: den Code - verschweigst, ist welcher?
Ist die ganze Geschichte mit dem URI-Rewriting also eigentlich nur ein Trick, der zu Fehlermeldungen führt?
Nein. Fehlermeldungen treten bei Fehlern auf.
Vielen Dank für jedes (produktive) Posting! (Ich hoffe ich bekomme auf diese Frage mal eine Antwort ... War in letzter Zeit eher selten der Fall.) Grüße, luti
Überlege Dir mal, ob das nicht an Deinen Fragen liegen könnte. Falls dies ein Doppelposting ist, gibt's beispielsweise große Schelte.
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Nabend,
Welches frühere Posting? Warum knüpfst Du nicht dort an? Warum verlinkst Du nicht mal zu dem Kontext?
äh, ja ... Hier: https://forum.selfhtml.org/?t=167354&m=1091401
Und der Grund, warum Du uns sowohl die Fehlermeldung als auch dessen Ursache - lies: den Code - verschweigst, ist welcher?
Die Fehlermeldung lautet: "File does not exist" und dann kommt der (absolute) Pfad zu der aufgerufenen Datei, also lokal z.B.: D:/html/tolle-projekte/interessant/toll-zu-merken
Der "Code" dürften in diesem Falle die rewrite-Regeln sein (s.o.) ...
Ist die ganze Geschichte mit dem URI-Rewriting also eigentlich nur ein Trick, der zu Fehlermeldungen führt?
Nein. Fehlermeldungen treten bei Fehlern auf.
Klingt irgendwie logisch ...
Überlege Dir mal, ob das nicht an Deinen Fragen liegen könnte. Falls dies ein Doppelposting ist, gibt's beispielsweise große Schelte.
Keine Bange ;)
Danke,Grüße & bis morgen, luti
-
Mahlzeit,
äh, ja ... Hier: https://forum.selfhtml.org/?t=167354&m=1091401
Wieso gibst Du ÜBERHAUPT den Statuscode 301? Ich würde jetzt mal denken und behaupten, so eine "Verschönerung" der URL soll nur eine hübschere "Fassade" nach außen zeigen - und intern ganz normal weiterlaufen. Wieso willst Du also die "unschönen", echten URLs dem Browser bekanntgeben und ihn darauf verweisen (301 = "Neenee, das findest Du nicht mehr hier - such mal dort!")?
Die Fehlermeldung lautet: "File does not exist" und dann kommt der (absolute) Pfad zu der aufgerufenen Datei, also lokal z.B.: D:/html/tolle-projekte/interessant/toll-zu-merken
Klar. Die gibt's ja auch nicht.
Der Browser fordet "/interessant/toll-zu-merken" an. Der Webserver antwortet "301 - Du findest das jetzt unter: /pfad-zu-allen-seiten/langweilig.php" (Ist das wirklich das, was Du willst?), schreibt aber natürlich trotzdem einen Fehler, weil er die angeforderte Ressource nicht finden kann. Anschließend versucht der Browser es unter "/pfad-zu-allen-seiten/langweilig.php", wird prompt bedient und ist glücklich.
Lass einfach mal den unsinnigen 301-Statuscode weg.
MfG,
EKKi--
sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|-
Moin,
Ok, vielleicht habe ich mich etwas unklar ausgedrückt ... war spät gestern. Also noch mal in Kurzform: Momentan hat eine Webseite "langweilige" URIs (die z.B. aus DB-Abfragen herrühren, in der Form /seitexy.php?cat=2&id=99). Die URI soll in etwas Sinnvolles geändert werden (interessant/toll-zu-merken). Das dahinter stehende Skript soll dabei unverändert bleiben. Gleichzeitig möchte ich dem googleBot und allen anderen Nutzern, die sich bis dato /seitexy.php?cat=2&id=99 gemerkt haben, auf die Umstellung per 301 hinweisen. Im Normalfall wird vom Browser dann die neue URI aufgerufen.
Wieso gibst Du ÜBERHAUPT den Statuscode 301? Ich würde jetzt mal denken und behaupten, so eine "Verschönerung" der URL soll nur eine hübschere "Fassade" nach außen zeigen - und intern ganz normal weiterlaufen. Wieso willst Du also die "unschönen", echten URLs dem Browser bekanntgeben und ihn darauf verweisen (301 = "Neenee, das findest Du nicht mehr hier - such mal dort!")?
In sofern - genau, nur "Fassade" nach außen. Die "unschönen" sollen gerade nicht im Browser stehen. Ich habe dafür natürlich 2 separate Rewrite-Regeln:
Regel 1: seitexy.php?cat=2&id=99 -> interessant/toll-zu-merken [R=301]
Regel 2: interessant/toll-zu-merken -> neu/seitexy.php?cat=2&id=99 [L]Um eine Endlosschleife zu vermeiden, habe ich die vorhandenen Skripte in einen Ordner "neu" verschoben ...
Die Fehlermeldung lautet: "File does not exist" und dann kommt der (absolute) Pfad zu der aufgerufenen Datei, also lokal z.B.: D:/html/tolle-projekte/interessant/toll-zu-merken
Klar. Die gibt's ja auch nicht.
Natürlich nicht. Aber wieso sucht er hier auf einmal mit dem absoluten Pfad? Würde er (der Server) weiterhin ab "/" suchen, würde er die Seite ja finden. Daher habe ich es mit absolutem Pfad rechts versucht, also http://www.domain.test/neu/seitexy.php?cat=2&id=99 und bekommen dann die "alte" URI im Browser angezeigt ...
Der Browser fordet "/interessant/toll-zu-merken" an. Der Webserver antwortet "301 - Du findest das jetzt unter: /pfad-zu-allen-seiten/langweilig.php" (Ist das wirklich das, was Du willst?), schreibt aber natürlich trotzdem einen Fehler, weil er die angeforderte Ressource nicht finden kann. Anschließend versucht der Browser es unter "/pfad-zu-allen-seiten/langweilig.php", wird prompt bedient und ist glücklich.
s.o. Liegt das ganze vielleicht etwa daran, dass ich in meiner Testumgebung mit virtuellem Host arbeite?! D.h. ich rufe tatsächlich http://www.domain.*test*/ auf, um zu meinem Projekt zu kommen.
Vielen Dank für die lange Antwort & Grüße,
luti-
Hi,
Gleichzeitig möchte ich dem googleBot und allen anderen Nutzern, die sich bis dato /seitexy.php?cat=2&id=99 gemerkt haben, auf die Umstellung per 301 hinweisen. Im Normalfall wird vom Browser dann die neue URI aufgerufen.
ok.
In sofern - genau, nur "Fassade" nach außen. Die "unschönen" sollen gerade nicht im Browser stehen. Ich habe dafür natürlich 2 separate Rewrite-Regeln:
Regel 1: seitexy.php?cat=2&id=99 -> interessant/toll-zu-merken [R=301]
Regel 2: interessant/toll-zu-merken -> neu/seitexy.php?cat=2&id=99 [L]Um eine Endlosschleife zu vermeiden, habe ich die vorhandenen Skripte in einen Ordner "neu" verschoben ...
Ok, allerdings solltest Du auf die erste RewriteRule verzichten und einfach eine seitexy.php erstellen, die sämtliche Requests mit 301 und absoluter URL beantwortet. Vielleicht loggst Du dann auch noch die Zugriffe und weißt dann, wann diese Umleitung nicht mehr erforderlich ist.
freundliche Grüße
Ingo-
Hallo,
Ok, allerdings solltest Du auf die erste RewriteRule verzichten und einfach eine seitexy.php erstellen, die sämtliche Requests mit 301 und absoluter URL beantwortet. Vielleicht loggst Du dann auch noch die Zugriffe und weißt dann, wann diese Umleitung nicht mehr erforderlich ist.
Hatte ich auch schon dran gedacht ... Gute Idee auch mit dem loggen, aber das sollte dann ja eh im access.log auftauchen. Werde ich dann mal ausprobieren, ob die Fehlermeldungen dann nicht mehr kommt. Würde ich jetzt allerdings erst mal bezweifeln, denn die kam so auch ganz ohne 301-Weiterleitung. Kann ich momentan leider nicht testen, muss bis heute Abend warten.
Liegts also vielleicht doch "nur" am vHost?
Danke & Grüße,
luti
-
-
Mahlzeit,
Ich habe dafür natürlich 2 separate Rewrite-Regeln:
"Natürlich"? Davon stand aber nix in Deinem ersten Posting ... wieso erwartest Du von Deinen Lesern, dass sie einsatzbereite Glaskugeln neben dem Monitor stehen haben?
Die Fehlermeldung lautet: "File does not exist" und dann kommt der (absolute) Pfad zu der aufgerufenen Datei, also lokal z.B.: D:/html/tolle-projekte/interessant/toll-zu-merken
Klar. Die gibt's ja auch nicht.
Natürlich nicht. Aber wieso sucht er hier auf einmal mit dem absoluten Pfad? Würde er (der Server) weiterhin ab "/" suchen, würde er die Seite ja finden. Daher habe ich es mit absolutem Pfad rechts versucht, also http://www.domain.test/neu/seitexy.php?cat=2&id=99 und bekommen dann die "alte" URI im Browser angezeigt ...
Ein Blick in die Dokumentation könnte dabei helfen:
---8<---
Syntax: RewriteRule Pattern Substitution [flags]
[...]
The Substitution of a rewrite rule is the string that replaces the original URL-path that was matched by Pattern. The Substitution may be a:
file-system path
Designates the location on the file-system of the resource to be delivered to the client.URL-path
A DocumentRoot-relative path to the resource to be served. Note that mod_rewrite tries to guess whether you have specified a file-system path or a URL-path by checking to see if the first segment of the path exists at the root of the file-system. For example, if you specify a Substitution string of /www/file.html, then this will be treated as a URL-path unless a directory named www exists at the root or your file-system, in which case it will be treated as a file-system path. If you wish other URL-mapping directives (such as Alias) to be applied to the resulting URL-path, use the [PT] flag as described below.Absolute URL
If an absolute URL is specified, mod_rewrite checks to see whether the hostname matches the current host. If it does, the scheme and hostname are stripped out and the resulting path is treated as a URL-path. Otherwise, an external redirect is performed for the given URL. To force an external redirect back to the current host, see the [R] flag below.- (dash)
A dash indicates that no substitution should be performed (the existing path is passed through untouched). This is used when a flag (see below) needs to be applied without changing the path.
In addition to plain text, the Substition string can include
1. back-references ($N) to the RewriteRule pattern
2. back-references (%N) to the last matched RewriteCond pattern
3. server-variables as in rule condition test-strings (%{VARNAME})
4. mapping-function calls (${mapname:key|default})Back-references are identifiers of the form $N (N=0..9), which will be replaced by the contents of the Nth group of the matched Pattern. The server-variables are the same as for the TestString of a RewriteCond directive. The mapping-functions come from the RewriteMap directive and are explained there. These three types of variables are expanded in the order above.
As already mentioned, all rewrite rules are applied to the Substitution (in the order in which they are defined in the config file). The URL is completely replaced by the Substitution and the rewriting process continues until all rules have been applied, or it is explicitly terminated by a L flag.
--->8---
s.o. Liegt das ganze vielleicht etwa daran, dass ich in meiner Testumgebung mit virtuellem Host arbeite?! D.h. ich rufe tatsächlich http://www.domain.*test*/ auf, um zu meinem Projekt zu kommen.
Ich würde sagen: ja. Mach Dir evtl. nochmal die GENAUE Funktionsweise der RewriteEngine klar - helfen kann da das RewriteLog: dort steht ziemlich genau, was gemacht wird (auf LogLevel 9 - natürlich nicht produktiv nutzen!).
MfG,
EKKi--
sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|-
Nabend,
Ich würde sagen: ja. Mach Dir evtl. nochmal die GENAUE Funktionsweise der RewriteEngine klar - helfen kann da das RewriteLog: dort steht ziemlich genau, was gemacht wird (auf LogLevel 9 - natürlich nicht produktiv nutzen!).
So, ich habe das ganze jetzt an einem Beispiel online getestet. Dort kommt keine Fehlermeldung ... Ergo lag es wohl tatsächlich am vHost bzw. irgend einer Einstellung meiner lokalen Installation. Dann bin ich zunächst mal beruhigt. Was da lokal läuft, werde ich mir ein anderes mal genauer anschauen. Danke für die Hinweis mit RewriteLog & LogLevel, kannte ich noch gar nicht ...
Also dann noch mal vielen Dank allen Beteiligten!
Grüße, luti
- (dash)
-
-
-
-