Mort des URL locales (file://)
Le dimanche 19 janvier 2014 à 22:10 - Lien permanent
Selon le navigateur, le test d'applications web en local (donc avec des URL en file://
) ne fonctionne pas complètement. Quelques exemples que j'ai rencontrés récemment : les requêtes AJAX échouent, impossible d'inclure un fichier SVG depuis un autre, impossible d'inclure des sous-titres WebVTT... Le pire, c'est que ça fluctue énormément entre navigateurs, et entre versions d'un même navigateur. De plus, je n'arrive pas à trouver de bonne doc sur le sujet.
Il semble néanmoins qu'il existe une position assez tranchée des éditeurs de navigateurs. Selon Adam Barth, un développeur de Chrome, « The file scheme's security model is totally broken. [...] We tell [web developers] not to run their sites locally. It doesn't work well. » Ouch, ça a le mérite d'être clair.
Alors que faire ? Une solution grâce à Python
Il faut donc absolument avoir un serveur web (HTTP) en local pour servir ses fichiers en cours de développement, même pour un contenu purement statique. En général, qui dit serveur web dit configuration un peu complexe, ce qui n'est pas vraiment adapté au développement d'une petite appli, ou à la réalisation de quelques tests.
Heureusement, une solution simple est livrée avec Python. Pour faire servir le contenu d'un répertoire, il suffit de lancer dans ce répertoire :
Avec Python 2 :
python -m SimpleHTTPServer 8000
Ou bien avec Python 3 :
python3 -m http.server 8000
8000 est à remplacer par le port de son choix.
Mise à jour : une autre solution avec Node.js
Si vous avez installé Node.js et npm, il existe une autre solution simple : le package http-server.
Il suffit d'installer globalement http-server globalement :
npm install http-server -g
Puis pour faire servir un répertoire (par défaut sur le port 8080, modifiable avec l'argument -p
) :
http-server
Pour plus de sécurité, on peut restreindre l'écoute à localhost :
http-server -a localhost
Commentaires
Toute la sécurité du web (et je pense surtout à javascript) repose sur les règles de same-origin, étendues uniquement par des headers HTTP qui se base sur les FQDN. Difficile d'appliquer ça à un pseudo-protocole comme file: ou data: pour qui la notion de domaine (ou de header !) n'a aucun sens...
Attention tout du moins avec SimpleHTTPServer, qui écoute sur toutes les interfaces (!) et sert les fichiers au-dessus de ce répertoire sans broncher via /../ (!!!)
Il me semble qu'on aurait pu dire que toutes les URL file: appartenaient à un même (pseudo-)domaine, ça aurait simplifié la vie des développeurs...
Quant à SimpleHTTPServer, bien sûr c'est pour tester en local, ce n'est pas à utiliser en production. Mais tout de même, la soi-disant faille permettant d'accéder aux répertoires parents était visiblement une fausse alerte : bug Python, bug RedHat.