Impossible de permettre à ces caractères dans l'URL: -%/\ # +

Question

A propos du système

Je URL de ce format dans mon projet: -

http://project_name/browse_by_exam/type/tutor_search/keyword/class/new_search/1/search_exam/0/search_subject/0 

Où keyword/class paire moyens de recherche avec mot-clé "class"

Après mon fichier htaccess: -

##AddHandler application/x-httpd-php5 .php 

Options Includes +ExecCGI 
Options +FollowSymLinks 

<IfModule mod_rewrite.c> 
RewriteEngine on 

############To remove index.php from URL 

RewriteCond $1 !^(index\.php|resources|robots\.txt) 
RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteRule ^(.*)$ index.php/$1 [L,QSA] 
#################################################end of find a class 


</IfModule> 

J'ai un fichier index.php commun qui exécute pour chaque module dans le projet. Il n'y a qu'une règle de réécriture pour supprimer l'index.php de l'URL (comme vous pouvez le voir ci-dessus).

Je n'utilise aucune règle de réécriture htaccess pour définir le tableau $ _GET. J'ai une fonction d'analyseur d'URL dans PHP à l'intérieur qui fait cela à la place. Pour l'URL de mon exemple, le rendement de l'analyseur: -

Array ([a] => browse_by_exam [type] => tutor_search [keyword] => class [new_search] => 1 [search_exam] => 0 [search_subject] => 0) 

J'utilise urlencode() tout en préparant l'URL de recherche et urldecode() tout en lisant l'URL de recherche

Problème

Je suis confronté à des problèmes avec certains caractères de l'URL

Character    Response 
%      400 - Bad Request - Your browser sent a request that this server could not understand. 
/      404 - Not FOund 
\ # +     Page does not break but urldecode() removes these characters. 

Je souhaite autoriser tous ces caractères. Quel pourrait être le problème? Comment puis-je les autoriser? S'il vous plaît aider Merci, Sandeepan

Mises à jour

Maintenant seulement/caractère est à l'origine (erreur 404 comme avant) la rupture d'URL. Donc, j'ai essayé en supprimant la règle de réécriture htaccess qui cache l'index.php dans l'URL et essayé avec l'URL complète à la place. Pour un terme de recherche class/new J'ai essayé avec les deux URL suivantes: -

http://project_name/index.php?browse_by_exam/type/tutor_search/keyword/class%2Fnew/new_search/1/search_exam/0/search_subject/0 

http://project_name/index.php/browse_by_exam/type/tutor_search/keyword/class%2Fnew/new_search/1/search_exam/0/search_subject/0 

Et la première des œuvres, mais le 2ème ne fonctionne pas. Notez le index.php?browse_by_exam dans le premier. Mais je ne peux pas utiliser la 1ère convention d'URL. Je dois faire/travailler avec index.php caché.S'il vous plaît aider

Merci encore Sandeepan

Edition (Résolu)

Considérant la réponse de Bobince à mon autre question

urlencoded Forward slash is breaking URL , je pense qu'il est préférable d'avoir des URL comme ceci: - http://project_name/browse_by_exam?type/tutor_search/keyword/class %2Fnew/new_search/1/search_exam/0/search_subject/0

De cette façon, je me débarrasse de la diffi culté de lisibilité causée par &param1=value1&param2=value2 convention et également en mesure de permettre des barres obliques dans la partie chaîne de requête en utilisant ?

Je veux éviter AllowEncodedSlashes parce Bobince dit Also some tools or spiders might get confused by it. Although %2F to mean/in a path part is correct as per the standard, most of the web avoids it.

Answer 1

Certains des problèmes de son comme ils sont liés à vous essayer d'utiliser PATH_INFO (votre RewriteRule colle tout derrière index.php comme s'il s'agissait d'un chemin). Serait-il possible d'utiliser simplement la variable $_SERVER['REQUEST_URI'] comme entrée pour votre fonction d'analyseur d'URL à la place? Il contient la même information, et je pense que ce serait moins problématique. La tentative de création d'une solution PATH_INFO ne semble pas très bien fonctionner dans un contexte par répertoire (.htaccess). Vous pouvez définir AllowPathInfo On, mais une fois que mod_rewrite tente de rediriger l'URL en interne, il semble qu'Apache ne souhaite pas analyser la partie finale de l'URL, ce qui entraîne l'erreur 404.

Si vous utilisez $_SERVER['REQUEST_URI'] à la place, vous pouvez simplement réécrire index.php sans les informations de fuite, comme ceci:

RewriteCond $1 !^(index\.php|resources|robots\.txt) 
RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteRule ^(.*)$ index.php [L,QSA] 

En ce qui concerne la 400 erreur va, votre % doit être encodée comme %25 par urlencode(), mais il semble que pour une raison quelconque, il pourrait y avoir un problème. Je vérifie que les URL de vos recherches sont correctement codées dans la sortie envoyée au navigateur, car cela peut être lié à des problèmes avec les autres caractères restants (mais je ne suis pas sûr).

Edit: Si vous avez utilisé le rerwite ci-dessus, vous auriez des URL comme

http://project_name/browse_by_exam/type/tutor_search/keyword/class/new_search/1/search_exam/0/search_subject/0 

et ils seraient redirigées en interne à index.php. Ensuite, vous pouvez obtenir la partie

/browse_by_exam/type/tutor_search/keyword/class/new_search/1/search_exam/0/search_subject/0 

de $_SERVER['REQUEST_URI'] dans ce script (il contiendra cette valeur) que vous pouvez ensuite analyser comme vous faites maintenant. Je ne sais pas pourquoi vous devez être en mesure de le faire réécrire après le index.php, puisque vous pouvez obtenir cette information même si ce n'est pas le cas, et il ressemble exactement à l'utilisateur dans leur navigateur.Vous pouvez même le faire au début du script, si la partie qui utilise $_SERVER['PATH_INFO'] n'est pas disponible pour le changement:

$_SERVER['PATH_INFO'] = $_SERVER['REQUEST_URI']; 

Si vous ne pouvez vraiment pas faire comme ça, je ne suis pas sûr qu'il y ait une solution (il y avait une explication dans votre autre question sur les raisons pour lesquelles cela est problématique), mais je vais voir si c'est possible et revenir vers vous.