Lors de la mise en production ou du transfert d’une application web chez un hébergeur comme OVH, il arrive fréquemment de voir surgir un avertissement bloquant de ce type : Warning: include() [function.include]: http:// wrapper is disabled in the server configuration by allow_url_include=0. Si ce message peut surprendre après des tests concluants sur un environnement de développement local mal configuré, il s’agit en réalité d’une sécurité élémentaire activée par défaut sur la plupart des serveurs web en production.
Pourquoi PHP bloque-t-il l’inclusion par URL ?
Ce message d’erreur signifie que le moteur PHP refuse d’exécuter une instruction d’inclusion (qu’il s’agisse de include, require, include_once ou require_once) pointant vers une URL distante, c’est-à-dire une adresse commençant par http:// ou https://.
Dans la configuration globale de PHP (le fichier php.ini), la directive allow_url_include est désactivée pour contrer les attaques de type Remote File Inclusion (RFI). Si cette option était active, un pirate pourrait injecter une URL externe pointant vers un script malveillant hébergé sur son propre serveur, forçant ainsi votre serveur à exécuter du code arbitraire.
De plus, appeler un fichier interne via une requête HTTP externe pose deux problèmes majeurs d’architecture :
- Une dégradation nette des performances : le serveur doit ouvrir une socket réseau, résoudre le nom de domaine et attendre la réponse HTTP pour un simple composant local.
- La perte du code source PHP : en passant par le protocole HTTP, le serveur distant exécute le script et ne renvoie que le flux HTML résultant. Les variables, fonctions et classes définies dans le fichier inclus ne sont donc pas chargées dans le scope d’exécution courant. Ce comportement anarchique génère d’ailleurs souvent une autre erreur bien connue : le PHP Warning: Cannot modify header information – headers already sent by (output ..
La mauvaise solution : tenter d’activer allow_url_include
Certains développeurs tentent de contourner la restriction en forçant allow_url_include = 1 via un fichier de configuration locale (comme un fichier .user.ini ou php.ini personnalisé). C’est une très mauvaise pratique. Ouvrir cette directive expose immédiatement l’hébergement à des failles de sécurité critiques et ne résout en rien l’inefficacité technique de la requête réseau interne.
Comment corriger proprement vos chemins d’inclusion ?
Pour lier des fichiers au sein d’une même application, vous devez impérativement faire référence au système de fichiers local du serveur (chemin absolu ou relatif) plutôt qu’à une adresse web.
1. Utiliser le chemin absolu avec DOCUMENT_ROOT
La variable globale issue de l’environnement serveur permet de pointer précisément vers la racine web de votre site, de manière similaire au fonctionnement des Variable d’environnement Unix sur le système hôte :
include($_SERVER[‘DOCUMENT_ROOT’] . ‘/includes/config.php’);
Cette méthode garantit que le chemin est résolu directement par le système de fichiers du système Linux ou Windows, sans solliciter la couche réseau.
2. Utiliser la constante magique __DIR__ (recommandé)
Depuis PHP 5.3, la constante magique __DIR__ retourne le dossier dans lequel se trouve le fichier courant. C’est la solution la plus robuste et la plus portable, car elle reste totalement indépendante de la configuration du VirtualHost ou du répertoire racine :
require_once __DIR__ . ‘/../classes/Database.php’;
En adoptant ces chemins locaux, le chargement de vos scripts sera instantané, sécurisé et totalement compatible avec les exigences des hébergements mutualisés et dédiés.
