Bonjour à tous !
Pour le moteur de recherchee de mon site PHP j'ai décidé d'utiliser une regle d'ecriture qui me permet d'avoir des url comme : -http://www.monsite.com/recherche/ma+recherche+simple !
Après m'être rendu compte que des visiteurs pourrait faire des recherches avec des caractères spéciaux, j'ai utiliser un urlencode sur la phrase de recherche.
Ce qui donne par ex. pour "recherche (caractères_AT_spéciaux)" : -http://www.monsite.com/recherche/recherche%2B%28caract%E8res%40sp%E9ciaux%29
Jusque la tout va bien ca marche !
La ou cela se complique c'est lorsque un visiteur fait une recherche avec une phrase contenant des slashes ou back slashes. Par ex. lorsqu'il cherche une url du type : "http://www.webmaster-hub.com/dossier/page/index.html" Ce qui donne : -http://www.monsite.com/recherche/http%3A%2F%2Fwww.webmaster-hub.com%2Fdossier%2Fpage%2Findex.html
Car en étant encodé en %2F les / (slashes) se comportent comme des slashes normaux. On dirait que cela revient à faire : -http://www.monsite.com/recherche/http%3A//www.webmaster-hub.com/dossier/page/index.html :8 Et vu que c'est le slashe est le séparateur de ma règle d'écriture forcément l'url n'est plus reconnue :/ Pas cool
La question est donc : y a t'il une solution pour contourner ce probleme ?
Merci pour votre aide !
Version complète: sur le forum Webmaster Hub : URL avec %2F se comporte comme une URL avec un slash
Webmaster Hub > Création et exploitation de Sites Internet > Les langages du Net > Fichier .htaccess et réécriture d'URLs
Hello,
fais donc voir ta règle de rewriting stp... à mon avis l'erreur vient de là, le rawurlencode() servant justement à éviter ce genre de couac.
fais donc voir ta règle de rewriting stp... à mon avis l'erreur vient de là, le rawurlencode() servant justement à éviter ce genre de couac.
Re Kioob comment ca va depuis cette nuit 
La regle d'écriture est plutot simple :
Je crois que le pb vient plutot du fait que les '%2F' sont autorisés dans les querystring mais pas dans les url. Car quand je remplace les '%2F' par des '%252f' cela marche parfaitement avec le résultat attendu. J'ai trouvé cette astuce sur http://www.webmasterworld.com/apache/3279075.htm
Par contre je n'ai pas trouvé d'équivalent du meme genre pour le backslashe (\), le diese (#), le & commercial, les doubles guillemets qui les caracteres speciaux qui font encore planté mon url :/ D'ailleurs je sais meme pas quel encodage c'est ce '%252f' ...
La regle d'écriture est plutot simple :
CODE
RewriteRule ^recherche/(.+)$ /search.php?string=$1 [L]
Je crois que le pb vient plutot du fait que les '%2F' sont autorisés dans les querystring mais pas dans les url. Car quand je remplace les '%2F' par des '%252f' cela marche parfaitement avec le résultat attendu. J'ai trouvé cette astuce sur http://www.webmasterworld.com/apache/3279075.htm
Par contre je n'ai pas trouvé d'équivalent du meme genre pour le backslashe (\), le diese (#), le & commercial, les doubles guillemets qui les caracteres speciaux qui font encore planté mon url :/ D'ailleurs je sais meme pas quel encodage c'est ce '%252f' ...
ok c'est j'ai trouvé !
En fait le caractere '%252f' est créé avec un double encodage ! Du coup pour que l'url passe sans pb il suffit de l'encoder 2 fois ainsi :
Après suffit de decoder 2 fois egalement $MyString pour la traiter et hop ca roule !
En fait le caractere '%252f' est créé avec un double encodage ! Du coup pour que l'url passe sans pb il suffit de l'encoder 2 fois ainsi :
CODE
$MyString = urlencode($MyString );
$MyString = urlencode($MyString );
$MyString = urlencode($MyString );
Après suffit de decoder 2 fois egalement $MyString pour la traiter et hop ca roule !
re 
pour le coup je n'ai pas trop d'idée... ça me semble quand même étonnant tout ça... mais j'ai la flemme de regarder dans la RFC pour voir si c'est "normal".
PS : attention toutefois, à ma connaissance urlencode() ne sert qu'à simuler les requêtes POST. Dans les autres cas c'est rawurlencode() qu'il faut utiliser, même si la déférence est mince (je crois que seul l'espace change).
En même temps ça fait longtemps que je n'ai pas regardé ça, je peux me tromper
pour le coup je n'ai pas trop d'idée... ça me semble quand même étonnant tout ça... mais j'ai la flemme de regarder dans la RFC pour voir si c'est "normal".
PS : attention toutefois, à ma connaissance urlencode() ne sert qu'à simuler les requêtes POST. Dans les autres cas c'est rawurlencode() qu'il faut utiliser, même si la déférence est mince (je crois que seul l'espace change).
En même temps ça fait longtemps que je n'ai pas regardé ça, je peux me tromper
Etonnant c'est le mot ... merci pour ton aide ++
++
Bonjour,
En fait ton problème de page non trouvée que tu as interprété comme une règle qui n'a pas fonctionné vient du fait que, par défaut, Apache n'autorise pas les "slash" ou "backslash" encodés dans les URL et renvoie une page 404 lorsqu'une telle URL est utilisée. Il existe une directive pour modifier ce comportement :
AllowEncodedSlashes On
À placer dans ton httpd.conf ou dans la configuration de ton VirtualHost (si tu en as un), cette directive ne fonctionne pas dans un .htaccess et donc suivant ton type d'hébergement ne sera pas modifiable.
Concernant urlencode ou rawurlencode, il faut savoir que ces fonctions sont destinése non à des URL complète mais à des données qui sont passées dans l'URL par la querystring. Et effectivement, une autre RFC (malheureusement je ne me souviens plus du numéro) indique que dans la partie "chemin" d'une URI l'encodage est différent et correspond effectivement à un double encodage.
J'ai récemment fait l'expérience d'un double encodage de paramètre dans le même cas de figure (slash) et selon mon interprétation, Google semble conserver l'URL décodée (une seule fois) comme référence et donc lors du second passage (non en suivant le lien mais directement avec l'URL mémorisée) détermine que la page n'existe pas car Apache renvoie une erreur 404 (la directive AllowEncodedSlashes étant à Off), donc selon mon expérience le double encodage fonctionne bien pour les utilisateurs, mais lorsqu'il s'agit d'indexer une telle URL on s'expose à ce genre de problème :S Mais si tu peux modifier cette directement cela semble régler le problème sans avoir recours à un double encodage (du moins pour les slash). Elle aura toutefois un effet de bord si tu t'appuye sur le comportement par défaut (page 404 lorsque %2f est utilisé) dans d'autre cas.
En fait ton problème de page non trouvée que tu as interprété comme une règle qui n'a pas fonctionné vient du fait que, par défaut, Apache n'autorise pas les "slash" ou "backslash" encodés dans les URL et renvoie une page 404 lorsqu'une telle URL est utilisée. Il existe une directive pour modifier ce comportement :
AllowEncodedSlashes On
À placer dans ton httpd.conf ou dans la configuration de ton VirtualHost (si tu en as un), cette directive ne fonctionne pas dans un .htaccess et donc suivant ton type d'hébergement ne sera pas modifiable.
Concernant urlencode ou rawurlencode, il faut savoir que ces fonctions sont destinése non à des URL complète mais à des données qui sont passées dans l'URL par la querystring. Et effectivement, une autre RFC (malheureusement je ne me souviens plus du numéro) indique que dans la partie "chemin" d'une URI l'encodage est différent et correspond effectivement à un double encodage.
J'ai récemment fait l'expérience d'un double encodage de paramètre dans le même cas de figure (slash) et selon mon interprétation, Google semble conserver l'URL décodée (une seule fois) comme référence et donc lors du second passage (non en suivant le lien mais directement avec l'URL mémorisée) détermine que la page n'existe pas car Apache renvoie une erreur 404 (la directive AllowEncodedSlashes étant à Off), donc selon mon expérience le double encodage fonctionne bien pour les utilisateurs, mais lorsqu'il s'agit d'indexer une telle URL on s'expose à ce genre de problème :S Mais si tu peux modifier cette directement cela semble régler le problème sans avoir recours à un double encodage (du moins pour les slash). Elle aura toutefois un effet de bord si tu t'appuye sur le comportement par défaut (page 404 lorsque %2f est utilisé) dans d'autre cas.
Ceci est une version "bas débit" de notre forum. Pour voir la version complète avec plus d'information, la mise en page et les images, veuillez cliquer ici.