J'avais un petit serveur perso avec lighttpd qui servait des fichiers statiques. J'ai eu besoin d'y greffer une application python, avec le protocole uwsgi. Dans lighttpd, il fallait passer par un module externe, à compiler soi-même (il est maintenant en Debian testing). Dans nginx, c'était fourni d'entrée dans le paquet Debian. Du coup, j'ai migré.
Le module uwsgi fait partie des modules nginx standard, et c'est une bonne chose(c).
Car l'ajout d'extensions tierces est justement le principal défaut de nginx (par rapport à lighttpd) à mes yeux.
Avec nginx, l'extension (fut-elle externe ou non) doit être compilée avec le coeur de nginx. Ajouter un module non fournis par sa distro impose donc de plus ou moins forker la version fournie (et maintenue…) par sa distribution. Les distributions tendent à lourdement patcher les versions de nginx qu'elles proposent, pour pouvoir packager et fournir les extensions tierces populaires. Malheureusement, le premier reflexe des développeurs upstream lors des rapports de bugs concernant ces versions frankenstein de nginx est de suggérer de tester un nginx nu…
À l'inverse, chez lighttpd (comme chez Apache, via apxs), une extension peut être compilée séparément du core et il suffit de poser le .so résultant dans le bon répertoire pour pouvoir l'utiliser; le core n'a pas besoin de "connaître" les extensions disponibles au moment de la compilation.
Je reconnais que c'est un défaut assez mineur, et je ne commencerai de nouveaux projets qu'avec nginx plutôt lighttpd ;). Car justement, des extensions disponibles, il en offre … beaucoup plus (faites une recherche github "nginx" et "lighttpd").
[^] # Re: NginX & lighttpd
Posté par herodiade . En réponse à la dépêche Nginx 1.2, des progrès sur le code et les parts de marché. Évalué à 4.
Le module uwsgi fait partie des modules nginx standard, et c'est une bonne chose(c).
Car l'ajout d'extensions tierces est justement le principal défaut de nginx (par rapport à lighttpd) à mes yeux.
Avec nginx, l'extension (fut-elle externe ou non) doit être compilée avec le coeur de nginx. Ajouter un module non fournis par sa distro impose donc de plus ou moins forker la version fournie (et maintenue…) par sa distribution. Les distributions tendent à lourdement patcher les versions de nginx qu'elles proposent, pour pouvoir packager et fournir les extensions tierces populaires. Malheureusement, le premier reflexe des développeurs upstream lors des rapports de bugs concernant ces versions frankenstein de nginx est de suggérer de tester un nginx nu…
À l'inverse, chez lighttpd (comme chez Apache, via apxs), une extension peut être compilée séparément du core et il suffit de poser le .so résultant dans le bon répertoire pour pouvoir l'utiliser; le core n'a pas besoin de "connaître" les extensions disponibles au moment de la compilation.
Je reconnais que c'est un défaut assez mineur, et je ne commencerai de nouveaux projets qu'avec nginx plutôt lighttpd ;). Car justement, des extensions disponibles, il en offre … beaucoup plus (faites une recherche github "nginx" et "lighttpd").