2009-01-14 17 views
3

Mon hébergeur a refusé de m'aider avec ceci, donc je viens ici aux gens sages pour de l'aide sur le "débogage boîte noire". Voici une version modifiée de ce que je leur ai envoyé:Pourquoi Apache décoderait-elle ma chaîne de requête?

J'ai deux (entre autres) domaines à dreamhost:

1) thefigtrees.net 2) shouldivoteformccain.com

J'ai remarqué aujourd'hui que lorsque J'héberge un script CGI sur # 1, que lorsque le script CGI s'exécute, la chaîne de requête HTTP GET transmise comme la variable d'environnement QUERY_STRING a déjà été décodée par l'URL. Ceci est un problème car cela signifie qu'une bibliothèque CGI standard (telle que CGI.pm de Perl) va essayer de diviser sur des esperluettes, puis de décoder la chaîne elle-même. Il y a deux problèmes potentiels avec ceci:

1) la chaîne est décodé deux fois, donc si une valeur est soumise au script comme « % 2525 », il finira par être traitée comme « % » (décodé deux fois) plutôt que « % 25 » (décodé une fois)

2) (plus fréquent) s'il y a une esperluette dans une valeur soumise, il obtiendra (correctement) soumis en% 26, mais la QUERY_STRING env. variable aura déjà décodé dans un "&" et alors la bibliothèque CGI va incorrectement diviser la chaîne de requête à cette perluète. C'est un gros problème! Le script http://thefigtrees.net/test.cgi le démontre. Il fait écho aux variables d'environnement avec lesquelles il est appelé. Navigation dans un navigateur pour:

http://thefigtrees.net/lee/test.cgi?x=y%26z

Vous pouvez voir que REQUEST_URI contient correctement x = y% 26Z (non codée), mais que QUERY_STRING l'a déjà décodé à x = y z &. Si je répète le test au domaine n ° 2 ( http://www.shouldivoteformccain.com/test.cgi?x=y%26z), je vois que le QUERY_STRING reste non décodé, de sorte que CGI.pm se sépare et décode correctement .

J'ai essayé de désactiver mes fichiers .htaccess sur les deux pour m'assurer que ce n'était pas le problème , et je n'ai vu aucune différence. Est-ce que quelqu'un pourrait spéculer sur les causes potentielles de ceci, puisque mon hébergeur ne semble pas vouloir m'aider?

grâce, Lee

Répondre

0

curieux. Rien de ce que je peux voir à partir d'ici nous donnerait une idée pourquoi cela se produirait ... Je peux seulement confirmer que c'est un bug de l'environnement et soupçonner peut-être des différences de configuration comme peut-être réécrire les règles. Par CGI 1.1, ce décodage ne devrait arriver qu'à SCRIPT-NAME et PATH-INFO, et non à QUERY-STRING. Il est inutile et ennuyeux que cela arrive, mais c'est la spécification. Utiliser REQUEST-URI au lieu de ces variables lorsqu'elles sont disponibles (c'est-à-dire Apache) est une solution de contournement courante pour les endroits où vous souhaitez placer des caractères hors-limites et Unicode dans les parties de chemin. jusqu'à ce qu'une sorte de résolution soit disponible de l'hôte.

SMV ne coûtent pas cher ces jours-ci ...

1

J'ai le même comportement dans Apache.

Je crois que mod_rewrite décodera automatiquement l'URL si elle est installée, cependant, j'ai vu le comportement d'auto-décodage même sans elle. Je n'ai pas retrouvé l'autre coupable. Une solution de contournement commune consiste à doubler le codage du paramètre d'entrée (en tirant parti du fait que le décodage d'URL est sûr lorsqu'il est appelé sur une URL non codée).