ABAKUS

Verfasst: **22.09.2010, 23:40**

Hi,
Ich habe einen sehr simplen Regex:

RewriteRule ^item/(.+)$ index.php?action=listitems&which=$1 [L]

Das funktioniert auch ganz gut für URLs à la "item/Foo" oder auch "item/Foo & Bar". Problematisch wird es mit dem Slash. Die URLs werden in einem PHP-Skript generiert, also habe ich urlencode() verwendet, sodass am Schluss etwas wie <a href="item/Foo%2FBar"> rauskommt. Seltsamerweise funktioniert der Regex in genau diesem Fall nicht! In diesem Fall bekomme ich die Standard-404-Meldung des Apache-Servers angezeigt. Es sind auch keine weiteren Ausdrücke in der Datei. Erst wenn ich in PHP das urlencode() rausnehme, also Links à la <a href="item/Foo/Bar"> generiere, funktioniert der Ausdruck wieder und die gewünschte Webseite wird angezeigt. Woran kann das liegen?

Verfasst: **23.09.2010, 07:58**

Ehrlich gesagt mag ich Fragen zu den Rules, aber hier habe ich nun auch keine passende Antwort.

Ich kann Dir nur sagen, dass mod_rewrite keine Probleme mit den %2F oder den anderen Zeichen-Codierungen hat, die verwende ich selber auf meinen Seiten.

Ich würde daher viel eher darauf tippen, dass PHP bzw. die index.php irgendwo den Fehler verursacht, eventuell weiterleitet und dann der Apache die Standard-Fehlerseite auswirft. Sind aber nur Vermutungen...

Kann man sich das mal live ansehen?

Verfasst: **23.09.2010, 11:48**

Synonym hat geschrieben:Ich kann Dir nur sagen, dass mod_rewrite keine Probleme mit den %2F oder den anderen Zeichen-Codierungen hat, die verwende ich selber auf meinen Seiten.

Hmm. Und ich hab das Problem gleich zwei Mal auf zwei Systemen... (Debian-Server und Windows-Entwicklungssystem)

Synonym hat geschrieben:Ich würde daher viel eher darauf tippen, dass PHP bzw. die index.php irgendwo den Fehler verursacht, eventuell weiterleitet und dann der Apache die Standard-Fehlerseite auswirft. Sind aber nur Vermutungen...

Die index.php wird gar nicht erst aufgerufen. Selbst wenn ich da direkt oben ein die(); reinschreibe, bekomme ich noch 'nen 404er.

Ich hab hier mal ein sehr simples Testsystem, das bei mir reproduzierbar auf zwei Systemen sich falsch verhält (beide ohne großartige Modifikationen an der Konfiguration)...

test.htm (diese Datei Aufrufen):

Code: Alles auswählen

<ul>
<li><a href="item/Foo&Bar">Foo&amp;Bar</a></li>
<li><a href="item/Foo%26Bar">Foo%26Bar</a></li>
<li><a href="item/Foo/Bar">Foo/Bar</a></li>
<li><a href="item/Foo%2FBar">Foo%2FBar</a></li>
</ul>

.htaccess:

Code: Alles auswählen

RewriteEngine on
RewriteRule ^item/&#40;.+&#41;$ index.php?action=listitems&which=$1 &#91;L&#93;

index.php:

Code: Alles auswählen

<?php
print_r&#40;$_GET&#41;;
?>

Sonst ist in dem Ordner nichts drin.

Alle Links bis auf der letzte werden auch tatsächlich zur index.php umgeleitet. Wobei halt auch die ersten beiden nicht ganz wie erwartet Funktionieren, da wird Foo&Bar in zwei variablen (which=Foo und Bar=) aufgesplittet, was ich eigentlich auch durch urlencode() vermeiden wollte...

Edit: Ich habe in der .htacces mal noch das hier eingefügt:

Code: Alles auswählen

ErrorDocument 404 /index.php

Und auch jetzt kommt die Default-Fehlerseite vom Apache! Und wenn ich zusätzlich noch die RewriteRule auskommentiere, verwenden die ersten drei Testcases meine index.php als Fehlerseite, aber der vierte nach wie vor auch die Default-Fehlerseite.
Ich blicke da nicht durch.

SEO Consulting bei ABAKUS Internet Marketing
Erfahrung seit 2002

persönliche Betreuung
individuelle Beratung
kompetente Umsetzung

Jetzt anfragen: 0511 / 300325-0.

Verfasst: **23.09.2010, 12:45**

Ich habe die Erfahrung gemacht, dass der Punkt . bei meinen Regexen nicht immer alle Zeichen einschließt. Es gibt Fälle, in denen ich die merkwürdige Konstruktion [\s\S]+ verwendet habe, weil .+ nicht funktioniert hat. Vielleicht funktioniert es ja damit.

Verfasst: **23.09.2010, 12:50**

Anna Bolika hat geschrieben:Ich habe die Erfahrung gemacht, dass der Punkt . bei meinen Regexen nicht immer alle Zeichen einschließt. Es gibt Fälle, in denen ich die merkwürdige Konstruktion [\s\S]+ verwendet habe, weil .+ nicht funktioniert hat. Vielleicht funktioniert es ja damit.

Hilft leider auch nicht

Ich könnte mir höchstens vorstellen, dass du damit Zeilenumbrüche umschiffst, aber das wäre ja bei .htaccess-Regexen ziemlich egal.

Verfasst: **23.09.2010, 13:09**

Hmm. Und ich hab das Problem gleich zwei Mal auf zwei Systemen... (Debian-Server und Windows-Entwicklungssystem)

Debian habe ich auch

Die index.php wird gar nicht erst aufgerufen. Selbst wenn ich da direkt oben ein die(); reinschreibe, bekomme ich noch 'nen 404er.

Das ist natürlich ein Argument.

Allerdings stehe ich da nun noch immer auf dem Schlauch und weiß keine Antwort, außer, das muss gehen.

Da gab es zwar durchaus mal einen Bug, aber der ist schon vor zwei Jahren behoben worden. https://issues.apache.org/bugzilla/show ... i?id=34602
https://issues.apache.org/bugzilla/show ... i?id=39746
oder auch hier:
https://www.tequilafish.com/2007/12/06/ ... plus-sign/

Kann es das sein? Sind Deine Systeme so alt?

Verfasst: **23.09.2010, 13:16**

Wäre natürlich sehr schön, wenn es daran liegen würde - unter Windows verwende ich den "aktuellen" XAMPP (mit Apache 2.2.14) und unter Debian halt den aus den Debian-Repos, der ist aber AFAIK auch neuer als 2.0.54.

Verfasst: **23.09.2010, 13:36**

Ich finde da einen anderen Fehler in Deinem Ansatz. Für item/foo brauchst Du kein urlencode in php.

Für foo.php?bar=item/foo wäre das sinnvoll, aber nicht für item/foo. Eine URI hat - anders als ein Query String - kein %2F als Slash drin. Das führt auch auf normalen aktuellen Apache Systemen zu Fehlern.

Ob das nun ein Bug oder Feature ist?

Kann ich nicht sagen, aber probiert es mal aus, indem ihr einen Slash in einer URI durch %2F ersetzt - da greift noch nicht einmal die Errordocument Direktive :/

Dazu auch Seite 26f. im https://www.ietf.org/rfc/rfc2396.txt (Collected Backus-Naur-Form for URI)

Verfasst: **23.09.2010, 14:09**

chris21 hat geschrieben:Für item/foo brauchst Du kein urlencode in php.

Klar, da ist es nicht nötig, und das funktioniert ja auch wie gewünscht. Lediglich der Teil hinter item/ (der ist variabel) wird escaped. Ich habe mal an diversen Stellen das item/ durch item%2F ersetzt und kann bestätigen, dass jedes mal der Server-404er zurückkam.

Verfasst: **23.09.2010, 14:15**

Ich bezog mich jetzt auf Deinen vierten Fall item/foo%2Fbar - da wird das escapen zum Problem, weil ein %2F in einer URI nicht vorgesehen sind - anders als im Query String, wo es escaped werden muss, da es ein reserviertes Zeichen für die URI Gestaltung ist.

Und wollte damit erläutern, dass dieser vierte Fall überhaupt nicht bei Deinen mod_rewrite Rules ankommt und daher die RewriteRule nicht greift.

Verfasst: **23.09.2010, 14:40**

chris21 hat geschrieben:Ich bezog mich jetzt auf Deinen vierten Fall item/foo%2Fbar - da wird das escapen zum Problem, weil ein %2F in einer URI nicht vorgesehen sind - anders als im Query String, wo es escaped werden muss, da es ein reserviertes Zeichen für die URI Gestaltung ist.

Und wollte damit erläutern, dass dieser vierte Fall überhaupt nicht bei Deinen mod_rewrite Rules ankommt und daher die RewriteRule nicht greift.

Ah, danke, jetzt verstehe ich.

urlencode() sollte ich also gar nicht anwenden? Nur htmlspecialchars()? Wie sieht's aus bei Redirects, die von PHP ausgelöst werden (mit header("Location: foo")) - da brauche ich noch urlencode(), zumindest für Leerzeichen und andere spezielle Zeichen, oder?

ABAKUS

Einfacher Regex macht Probleme mit %2F vs /

Einfacher Regex macht Probleme mit %2F vs /