Crétin de navigateur: le cas du "/"
Ici, nous allons voir un soucis que j'ai eu il y a quelques mois, et que je ne pensais pas avoir.
Dans une URL, nous ne pouvons pas avoir de caractères spéciaux, comme les espaces. Du coup, nous les encodons. Par exemple, un espace est représenté par %20.
Après, il est vrai que nous navigateurs sont plus "dociles" et nous autorisent de plus en plus à ne pas encoder nos valeurs. Néanmoins, il est toujours conseillé de le faire pour éviter des confusions. Notamment autour du "/".
En effet, imaginer les cas suivants
1) Je souhaite injecter une valeur en query parameter qui contient "/". Pour des raisons de parsing de l'url, il est vivement conseillé de l'encoder. Nous aurons alors l'url:
2) J'ai une api REST et je souhaite injecter une valeur qui potentiellement peut avoir un "/" (ce qui vous vous en doutez, est très gênant). Naïvement, nous penserions que nous ferions cela:
Et bien il y a de très fortes chances que votre navigateur le comprenne malheureusement comme ça: http://www.example.com/products/range/my/range/princing
En effet, il semblerait que les navigateurs ont pris pour habitude pour le cas du "/" de le dé-encoder si ce dernier est avant les query parameters (autrement dit, avant un "?"). Et ça, quelque soit le navigateur.
Du coup, avec ce genre de comportement, des applications utilisant par exemple le routeur d'AngularJs vont "planter" car le chemin ne sera pas reconnu, ou les valeurs mal interceptés.
Et après avoir discuter avec des amis, il semblerait que cela peut du coup se produire également côté backend, et pas seulement pour ce cas là.
Ainsi, il est vivement conseillé de faire du double-encodage sur vos valeurs de paramètres qui peuvent contenir des caractères spéciaux.
Commentaires
Enregistrer un commentaire