Les directives INI, c'est le mal !

This post is also available in English.

Plusieurs fois, alors que des évolutions étaient discutées pour PHP 7, j’ai assisté à des échanges où un intervenant proposait de rendre optionnelle une nouvelle fonctionnalité¹, par le biais d’une directive de configuration INI – l’idée étant que chacun pourrait alors l’activer ou non.

Mais le principe même de directives permettant de changer, parfois en profondeur, le comportement d’un langage de programmation… J’en ai des frissons !

Imaginez un langage² créé pour faciliter la mise en place de formulaires HTML et le traitement des données saisies.

Pour aider les débutants n’ayant aucune notion de sécurité, et puisque l’utilisation de MySQL pour le stockage de données est à la mode, les développeurs de ce langage mettent en place une option qui, une fois activée, entraine l’ajout automatique d’un \ devant tous les guillemets ' arrivant en entrée³ (GET/POST/…).

Bien sûr, une partie des administrateurs système active immédiatement cette directive, puisqu’elle améliore considérablement la sécurité⁴ en empêchant certaines injections SQL. Mais d’autres administrateurs la désactivent, puisque c’est à chaque développeur de savoir gérer ses données : le langage ne doit pas les modifier à la volée !

Et là, une application donnée fonctionnera parfaitement sur un serveur, alors qu’elle fera n’importe quoi sur un autre – soit en injectant des \ partout, soit en explosant violemment sur la moitié de ses requêtes SQL ! Elle n’aura en effet pas été spécifiquement développée pour tenir compte des différentes combinaisons d’options de configurations.

Vous en rêviez ? Bienvenue dans l’enfer des magic quotes⁵ !

Dans le même genre, vous vous souvenez de register_globals, où des variables apparaissaient par magie dans vos scripts, pour peu que cette directive soit activée ? C’était d’enfer !

Revenons à une période un peu plus proche : chaque fois qu’une directive de configuration est ajoutée à PHP⁶, cela signifie :

• Plusieurs branches de code à tester, déboguer, maintenir. La maintenance d’une fonctionnalité introduite dans un langage aussi répandu que PHP, c’est sur 10 ans. Et plus !
• Plus de documentation à rédiger, d’une part – et à lire et à comprendre, d’autre part.
• Plus de travail à fournir pour s’assurer que chaque application⁷ fonctionne avec chaque combinaison de paramètres.
• En cas de problème, combien de temps avant de réaliser qu’un comportement étrange est dû à une valeur inhabituelle ou inattendue pour une directive de configuration bien spécifique ? Ou, pire, à une combinaison inhabituelle de valeurs pour quelques directives de configuration tordues ?

Heureusement, les développeurs qui travaillent sur PHP sont conscients de ces problèmes et limitent donc autant que possible les ajouts de nouvelles directives INI. Ils fournissent également deux fichiers php.ini-development et php.ini-production, qui contiennent des valeurs assez appropriées, dont il est bon de rester proche.

Quoi qu’il en soit, avant de suggérer « mais ils pourraient permettre d’activer ou non cette fonctionnalité via une simple directive INI » pour des points aussi critiques qu’un système de typage souple ou strict, demandez-vous si vous souhaitez véritablement arriver à deux langages se comportant de manière complètement différente, avec des applications et bibliothèques fonctionnant uniquement sur certaines combinaisons de configurations et pas d’autres…

Et maintenant, répétez après moi : « les directives INI, c’est le mal ! »