nicht angemeldet
htaccess + modrewrite + Sonderzeichen
Der MartinHallo,
ich habe auf meinem Server eine Domainweiterleitung in der htaccess geschalten.
RewriteEngine on
RewriteCond %{HTTP_HOST} ^(test.eu|test.de)$ [NC]
RewriteRule ^(.*) http://test.org/$1 [L,R=301]
Kann es sein, dass bei dem Rewrite Sonderzeichen in $_GET Paramtern verfälscht oder ignoriert werden? Wenn ja, wie kann ich dem entgegen wirken?
MFG
Torsten
-
Kann es sein, dass bei dem Rewrite Sonderzeichen in $_GET Paramtern verfälscht oder ignoriert werden? Wenn ja, wie kann ich dem entgegen wirken?
Siehe Flag QSA
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
moin,
Siehe Flag QSA
Wozu einen alten und neuen QS kombinieren? In der gezeigten Regel sehe ich keinen alten (vorgegebenen) QUERY_STRING, das QSA-Flag ist hier also nicht notwendig und würde das Problem, was mit Sicherheit woanders liegt, auch nicht lösen.
Hotti
--
Für einen professionellen Einstieg in Perl sind PHP-Kenntnisse nicht erforderlich aber auch nicht hinderlich.-
Hi!
Siehe Flag QSA
Wozu einen alten und neuen QS kombinieren?Vielleicht aufgrund einer individuellen Anforderung, beispielsweise wenn man variable Parameter hat und zu diesen einen Teil aus dem Pfad hinzufügen will? Warum sollte man so etwas nicht wollen?
In der gezeigten Regel sehe ich keinen alten (vorgegebenen) QUERY_STRING,
Warum auch? Eine RewriteRule ignoriert einen Querystring vollständig. Und wenn der Querystring oder Teile davon nicht zum Umschreiben benötigt werden, sieht man davon auch nichts in den RewriteConds. Trotzdem ist es nicht illegitim, ihm bewahren zu wollen.
das QSA-Flag ist hier also nicht notwendig und würde das Problem, was mit Sicherheit woanders liegt, auch nicht lösen.
Du meinst, wenn man ohne QSA den Querystring verliert ist man alle Sorgen darum auch los?
Lo!
-
-
Siehe Flag QSA
mmh, ich verstehe die Apache Doc da nicht richtig.
Ich ersetze doch durch meinen Rewrite nur einen Teil des Strings. Der Rest sollte doch 1:1 übernommen werden?!?
-
-
Hi,
Kann es sein, dass bei dem Rewrite Sonderzeichen in $_GET Paramtern verfälscht oder ignoriert werden?
Wenn du ein konkretes Problem hast, beschreibe es bitte.
Eine hypothetische Diskussion ist eher sinnfrei.MfG ChrisB
--
“Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]-
Wenn du ein konkretes Problem hast, beschreibe es bitte.
Gerne ;)
Einige GET Paramter werden im Raw-Binary-Format übertragen. Nachdem die Domain durch modrewrite geändert wurde, stimmen diese GET Parameter von der Länge her nicht mehr überein.
-
Hi!
Wenn du ein konkretes Problem hast, beschreibe es bitte.
Gerne ;)Bitte so konkret, dass man es nachvollziehen kann.
Einige GET Paramter werden im Raw-Binary-Format übertragen.
Das ist kein für eine URL erlaubtes Format. URL-Kodierung sollte es schon sein.
Lo!
-
Das ist kein für eine URL erlaubtes Format. URL-Kodierung sollte es schon sein.
Entschuldige, ich hab mich verschrieben.
Ich meinte: Einen sha1 von einem Raw Binary String-
Hi!
Ich meinte: Einen sha1 von einem Raw Binary String
In welcher Darstellung kommt der SHA1-Wert zum Einsatz? In der vorwiegend zu sehenden Hexwert-Notation à la 68ac906495480a3404beee4874ed853a037a7a8f oder die direkten Bytewerte?
Zeig doch einfach mal ein konkretes Beispiel an dem der Fehler nachzuvollziehen ist. (Und bitte, test.de ist eine in Verwendung befindliche Domain. Nimm die für Beispiele vorgesehenen, wie example.org|.com|.net.)
Lo!
-
In welcher Darstellung kommt der SHA1-Wert zum Einsatz? In der vorwiegend zu sehenden Hexwert-Notation à la 68ac906495480a3404beee4874ed853a037a7a8f oder die direkten Bytewerte?
Da in der access Log des Apache sowas steht:
"GET /test.php?param1=1¶m2=%ea%81%e3h%28e%20-%5cJ%bc%00¶m3=%ef%85%1a%05%8f%a4%c5%93a8%15%07xP%f9b%9b%db%05%04¶m4=1850
nehme ich mal an Bytewerte. Und es betrifft param3. Dieser hat immer dieselbe Länge. Alle anderen params differieren da.
-
Hallo,
In welcher Darstellung kommt der SHA1-Wert zum Einsatz? In der vorwiegend zu sehenden Hexwert-Notation à la 68ac906495480a3404beee4874ed853a037a7a8f oder die direkten Bytewerte?
"GET /test.php?param1=1¶m2=%ea%81%e3h%28e%20-%5cJ%bc%00¶m3=%ef%85%1a%05%8f%a4%c5%93a8%15%07xP%f9b%9b%db%05%04¶m4=1850
nehme ich mal an Bytewerte.ja, offensichtlich.
Und es betrifft param3. Dieser hat immer dieselbe Länge. Alle anderen params differieren da.
Meinst du mit Länge die Länge des Originalstrings (Rohdaten), oder die des URL-codierten Strings? Dass sich durch die URL-Codierung die Länge ändert, ist klar (und korrekt). Aber da diese Codierung vor der Verarbeitung der Daten wieder rückgängig gemacht wird, ist es nicht sinnvoll, sie hier zu betrachten - sie ist nur eine vorgeschriebene Transportverpackung.
Ciao,
Martin--
Wer barfuß geht, dem kann man nicht die Schuld in die Schuhe schieben.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(-
Meinst du mit Länge die Länge des Originalstrings (Rohdaten), oder die des URL-codierten Strings? Dass sich durch die URL-Codierung die Länge ändert, ist klar (und korrekt). Aber da diese Codierung vor der Verarbeitung der Daten wieder rückgängig gemacht wird, ist es nicht sinnvoll, sie hier zu betrachten - sie ist nur eine vorgeschriebene Transportverpackung.
Ja ich meine die Länge des Originalstrings - ein 20 Byte langer sha1 Hash. Den hier zu posten, würde eh nichts bringen, da er nicht richtig dargestellt werden würde. Nach dem Rewrite ist er in einigen Fällen jedenfalls keine 20 Byte mehr lang. Also muss etwas "verloren" gehen oder hinzukommen.
-
Hi!
Ja ich meine die Länge des Originalstrings - ein 20 Byte langer sha1 Hash.
Du hängst also die 20 Bytes mit einem möglichen Werteumfang von 0..255 direkt an die URL ohne dabei zu beachten, das diese Bytes als Zeichen interpretiert werden, von denen einige im URL-Umfeld eine besondere Bedeutung haben? Das kann nicht gut gehen. Nimm die Hexschreibweise mit 40 Zeichen aus dem Bereich 0..9a..f, die sind URL-sicher. Oder verwende eine URL-Kodierung.
Lo!
-
Du hängst also die 20 Bytes mit einem möglichen Werteumfang von 0..255 direkt an die URL ohne dabei zu beachten, das diese Bytes als Zeichen interpretiert werden, von denen einige im URL-Umfeld eine besondere Bedeutung haben?
Ich hänge gar nichts - das BitTorrent Protokol sieht es so vor.
Nur der Rewrite zerhackt es anscheinend. Muss ich da vielleicht vorher das Charset wechseln, oder den String irgendwie escapen?-
Hi!
Du hängst also die 20 Bytes mit einem möglichen Werteumfang von 0..255 direkt an die URL ohne dabei zu beachten, das diese Bytes als Zeichen interpretiert werden, von denen einige im URL-Umfeld eine besondere Bedeutung haben?
Ich hänge gar nichts - das BitTorrent Protokol sieht es so vor.
Nur der Rewrite zerhackt es anscheinend.Also irgendwer hängt da was an die URL und du stellst fest, dass da was fehlt. Woraus genau schlussfolgerst du das? Was genau fehlt denn?
Muss ich da vielleicht vorher das Charset wechseln, oder den String irgendwie escapen?
Wenn du selbst nichts machst und es einfach geschickt bekommst, wirst du vermutlich auch keine Änderung an dem dir gesendeten vornehmen können.
Mit jedem Wurm, den man einzeln aus der Nase ziehen muss sinkt übrigens die Mit-dem-Problem-Beschäftigungsbereitschaft. Wenn du vorwärtskommen möchtest, solltest du es so beschreiben, dass man es sofort nachvollziehen kann. Dass der Apache beim Rewriten einen Fehler macht, kann zwar nicht gänzlich ausgeschlossen werden, aber es ist doch eher umwahrscheinlich, dass es bis jetzt noch nicht bemerkt wurde. Also solltest du davon ausgehen, dass die Ursache irgendwo in deinem Einflussbereich zu suchen ist. Und wenn da ein Außenstehender die Ursache erkennen soll, muss er das Problem nachvollziehen können.
Was also bekommst du übergeben?
"GET /test.php?param1=1¶m2=%ea%81%e3h%28e%20-%5cJ%bc%00¶m3=%ef%85%1a%05%8f%a4%c5%93a8%15%07xP%f9b%9b%db%05%04¶m4=1850
Was bekommt test.php zu sehen?
var_dump($_GET);
Binärwerte: echo bin2hex($_GET[...]);Welcher Wert wird wie erwartet und was steht stattdessen drin?
var_dump(...);
Binärwerte: echo bin2hex(...);Lo!
-
-
-
-
-
-
-
-
-
-
-
RewriteEngine on
RewriteCond %{HTTP_HOST} ^(test.eu|test.de)$ [NC]
RewriteRule ^(.*) http://test.org/$1 [L,R=301]Kann es sein, dass bei dem Rewrite Sonderzeichen in $_GET Paramtern verfälscht oder ignoriert werden? Wenn ja, wie kann ich dem entgegen wirken?
Gehe mal ohne die Weiterleitung mit dem Websniffer auf die Seite test.eu oder test.de und schau dir mal den Content-Type Wert an. Dann schau dir test.org an. Ich vermute, du hast auf beiden Servern unterschiedliche charset-Werte.
-
Ich vermute, du hast auf beiden Servern unterschiedliche charset-Werte.
Ne, das ist ein und derselbe Server. Ich leite nur alle meine Domains auf eine um.
-
Ich vermute, du hast auf beiden Servern unterschiedliche charset-Werte.
Ne, das ist ein und derselbe Server. Ich leite nur alle meine Domains auf eine um.
Du hast Recht, ich korrigiere.
Ich vermute, du hast bei den verschiedenen Webseiten unterschiedliche charset-Werte.
-
Ich vermute, du hast bei den verschiedenen Webseiten unterschiedliche charset-Werte.
Nein, es ist auch dieselbe Website, halt nur mit mehreren Domains.
-
Nein, es ist auch dieselbe Website, halt nur mit mehreren Domains.
Nicht wirklich test.de und test.eu gehören der Stiftung Warentest, test.org gehört TMT Teleservice.
-
Nicht wirklich test.de und test.eu gehören der Stiftung Warentest, test.org gehört TMT Teleservice.
Achso, ja ich hab die beiden Beispiele vorher nicht getestet :)
Nein, ich hab mit denen nix am Hut. Sollte wirklich nur ein Beispiel sein.
-
-
-
-
-
-
Problem gelöst
aus: RewriteRule ^(.*) http://test.org/$1 [L,R=301]
wird: RewriteRule ^(.*) http://test.org/$1 [L,NE]
Und das war es dann auch schon.
Danke an alle für die Hilfe