Est une barre oblique ("/") équivalente à une barre oblique codée ("% 2F") dans la partie chemin d'une URL HTTP
J'ai un site qui traite "/" et "% 2F" dans la partie chemin (pas la chaîne de requête) d'une URL différemment. Est-ce une mauvaise chose à faire selon le RFC ou le monde réel?
Je demande parce que je continue à rencontrer de petites surprises avec le framework web que j'utilise (Ruby on Rails) ainsi que les couches en dessous (Passenger, Apache, par exemple, j'ai dû activer "ALLOW_ENCODED_SLASHES" pour Apache). Je suis maintenant en train de me débarrasser complètement des barres obliques encodées, mais je me demande si je devrais déposer des rapports de bogues où je vois un comportement étrange impliquant les barres obliques encodées.
Quant à savoir pourquoi j'ai les barres obliques encodées en premier lieu, j'ai essentiellement des itinéraires comme celui-ci:
:controller/:foo/:bar
où: foo est quelque chose comme un chemin qui peut contenir des barres obliques. Je pensais que la chose la plus simple à faire serait de simplement échapper l'URL foo afin que les barres obliques soient ignorées par le mécanisme de routage. Maintenant, j'ai des doutes, et il est assez clair que les cadres ne prennent pas vraiment en charge cela, mais selon la RFC, est-ce mal de le faire de cette façon?
Voici quelques informations que j'ai recueillies:
RFC 1738 (URL):
Habituellement, une URL a la même interprétation lorsqu'un octet est représenté par un caractère et lorsqu'il est codé. Cependant, cela n'est pas vrai pour les caractères réservés: le codage d'un caractère réservé pour un schéma particulier peut changer la sémantique d'une URL.
RFC 2396 (URI):
Ces caractères sont appelés "réservés", car leur utilisation dans le composant URI est limitée à leur fin réservée. Si les données d'un composant URI entrent en conflit avec l'objectif réservé, les données en conflit doivent être échappées avant de former l'URI.
(Est-ce que s'échapper ici signifie autre chose que coder le caractère réservé?)
RFC 2616 (HTTP/1.1):
Les caractères autres que ceux des ensembles "réservés" et "non sûrs" (voir RFC 2396 [42]) sont équivalents à leur codage ""% "HEX HEX".
Il y a aussi ce rapport de bogue pour Rails, où ils semblent s'attendre à ce que la barre oblique codée se comporte différemment:
Bon, je m'attendrais à des résultats différents car ils pointent vers des ressources différentes.
Il recherche le fichier littéral 'foo/bar' dans le répertoire racine. La version non échappée recherche la barre de fichiers dans le répertoire foo.
Il est clair d'après les RFC que raw vs encoded est l'équivalent pour les personnages non réservés, mais quelle est l'histoire pour les personnages réservés?
D'après les données que vous avez collectées, j'aurais tendance à dire que "/" encodé dans un uri est censé être à nouveau considéré comme "/" au niveau de l'application/cgi.
Cela veut dire que si vous utilisez Apache avec mod_rewrite par exemple, il ne correspondra pas au modèle qui attend des barres obliques contre l'URI avec des barres obliques encodées. Cependant, une fois que le module approprié/cgi/... est appelé pour gérer la demande, c'est à lui de faire le décodage et, par exemple, de récupérer un paramètre incluant des barres obliques comme premier composant de l'URI.
Si votre application utilise ensuite ces données pour récupérer un fichier (dont le nom de fichier contient une barre oblique), c'est probablement une mauvaise chose.
Pour résumer, je trouve parfaitement normal de voir une différence de comportement dans "/" ou "% 2F" car leur interprétation se fera à différents niveaux.
L'histoire de %2F contre / était que, selon les initiales recommandations du W3C , les barres obliques "doivent impliquer une structure hiérarchique" :
Exemple 2
Les URI
http://www.w3.org/albert/bertram/marie-claude
et
http://www.w3.org/albert/bertram%2Fmarie-claude
ne sont PAS identiques, car dans le second cas, la barre oblique codée n'a pas de signification hiérarchique.
J'ai également un site qui contient de nombreuses URL avec des caractères encodés en url. Je constate que de nombreuses API Web (y compris les outils Google pour les webmasters et plusieurs Drupal) trébuchent sur les caractères encodés en url. De nombreuses API décodent automatiquement les URL à un moment donné de leur processus, puis utilisent le résultat comme URL ou HTML. Lorsque je trouve l'un de ces problèmes, je double généralement les résultats (qui transforment% 2f en% 252f) pour cette API. Cependant, cela cassera les autres API qui ne s'attendent pas à un double encodage, donc ce n'est pas universel Solution.
Personnellement, je supprime autant de caractères spéciaux que possible dans mes URL.
De plus, j'utilise des numéros d'identification dans mes URL qui ne dépendent pas du codage urld:
example.com/blog/my-amazing-blog%2fstory/yesterday
devient:
example.com/blog/12354/my-amazing-blog%2fstory/yesterday
dans ce cas, mon code utilise uniquement 12354 pour rechercher l'article, et le reste de l'URL est ignoré par mon système (mais est toujours utilisé pour le référencement.) De plus, ce numéro doit apparaître AVANT les composants d'URL inutilisés. de cette façon, l'url fonctionnera toujours, même si% 2f n'est pas décodé correctement.
Assurez-vous également d'utiliser des balises canoniques pour vous assurer que les erreurs d'URL ne se traduisent pas en contenu dupliqué.
Si vous utilisez Tomcat, ajoutez '-Dorg.Apache.Tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH = true' dans VM propriétés.
https://Tomcat.Apache.org/Tomcat-7.0-doc/config/systemprops.html#Security
Que faire si :foo dans sa forme naturelle contient des barres obliques? Vous ne voudriez pas que ce soit que la distinction que la recommandation tente de préserver? Il note spécifiquement ,
La similitude avec unix et les autres conventions de nom de fichier du système d'exploitation de disque doit être considérée comme purement fortuite et ne doit pas être interprétée comme indiquant que les URI doivent être interprétés comme des noms de fichier.
Si l'on construisait une interface en ligne pour un programme de sauvegarde et souhaitait exprimer le chemin en tant que partie du chemin URL, il serait logique d'encoder les barres obliques dans le chemin du fichier, comme c'est le cas ne fait pas vraiment partie de la hiérarchie de la ressource - et plus important encore, la route . /backups/2016-07-28content//home/dan/ perd la racine du système de fichiers dans la double barre oblique. Échapper aux barres obliques est le moyen approprié de distinguer, comme je l'ai lu.