Lighttpd

Le
Olivier Masson
Est-ce qu'il est interchangeable avec Apache2 ?

Parce que c'est la grande mode, il est tout léger, ça donne envie, mais
entre les scripts, le monitoring, les htaccess digest, le rewriting qui
utilisent Apache2, faut-il tout réapprendre et refaire ?

Merci.
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Mickaël Wolff
Le #22070231
Olivier Masson a écrit :
Parce que c'est la grande mode, il est tout léger, ça donne envie, mais
entre les scripts, le monitoring, les htaccess digest, le rewriting qui
utilisent Apache2, faut-il tout réapprendre et refaire ?



Il a un gros défaut : on ne peut pas définir un error_log par virtual
host. La raison en est l'usage du belle variable globale :-D

Mais ce qui refroidit, c'est la réponse à ce bug

Sinon c'est vrai que les fichiers de configuration sont agréable,
l'intégration de PHP ce fait naturellement (via fCGI).
--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
Olivier Masson
Le #22070171
Mickaël Wolff a écrit :

Il a un gros défaut : on ne peut pas définir un error_log par virtual
host. La raison en est l'usage du belle variable globale :-D



C'est nase. Mais bon, ça se filtre j'imagine.


Mais ce qui refroidit, c'est la réponse à ce bug




La réponse est un peu... abrupte :)
Mais je suis assez d'accord avec ça "You have one lighttpd running, so
one error.log. For your applications you should use extra error logs if
you need separate ones."
J'utilise souvent error_handler sur php, que je n'ai *jamais* vu sur des
fonctions ou classes récupérées sur le net. Pourtant je ne suis vraiment
pas du tout un bon dev php mais je ne comprends pas comment on peut se
passer d'un gestionnaire d'erreur propre à chaque appli.

Sinon c'est vrai que les fichiers de configuration sont agréable,
l'intégration de PHP ce fait naturellement (via fCGI).



C'est le header permettant de télécharger de gros fichiers via lighttpd
et non php qui m'a plu.
Et bien sûr la grande rapidité, semble-t'il.
Mais en lisant la roadmap, si la 1.5 semble très prometteuse, ça
_parait_ fragile pour le moment.
Mickaël Wolff
Le #22070161
Olivier Masson a écrit :

La réponse est un peu... abrupte :)
Mais je suis assez d'accord avec ça "You have one lighttpd running, so
one error.log. For your applications you should use extra error logs if
you need separate ones."



Oui mais non. Que l'application doive avoir un log différent, ok.
Mais quand le serveur web est utilisé pour héberger plusieurs sites
différents, qui ont besoin de comprendre pourquoi ça ne marche pas, il
faut que l'utilisateur puisse avoir les messages d'erreur concernant son
hôte virtuel.


J'utilise souvent error_handler sur php,



set_error_handler est un gestionnaire d'erreur global. Il n'a donc
pas à être géré par une classe qui sera utilisée. Au pire, dans
l'application finale. Mais très franchement, ça ne sert à rien.
Personnellement, je désactive l'affichage des erreurs, et vérifie
systématiquement le retour des fonctions que j'utilises. En cas d'erreur
grâve, je lève une exception et je gère depuis l'appelant. C'est plus
propre. (d'ailleurs, j'espère que ce système d'erreur bancale
disparaîtra un jour).


que je n'ai *jamais* vu sur des
fonctions ou classes récupérées sur le net. Pourtant je ne suis vraiment
pas du tout un bon dev php mais je ne comprends pas comment on peut se
passer d'un gestionnaire d'erreur propre à chaque appli.



Justement, error_handler ne permet pas, à mon avis, de gérer
proprement les erreurs.


Et bien sûr la grande rapidité, semble-t'il.
Mais en lisant la roadmap, si la 1.5 semble très prometteuse, ça
_parait_ fragile pour le moment.



Je pense que Youtube prouve que lighttpd est un serveur solide.

Par contre, attention aux habitudes : les .htaccess ne sont pas
chargés :) Et attention à la configuation. La version que j'ai sur mon
serveur Debian semble fâchée avec les regex dans la liste des fichiers
en deny. Ce qui est gênant.

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
Olivier Masson
Le #22070151
Mickaël Wolff a écrit :
Olivier Masson a écrit :

La réponse est un peu... abrupte :)
Mais je suis assez d'accord avec ça "You have one lighttpd running, so
one error.log. For your applications you should use extra error logs
if you need separate ones."



Oui mais non. Que l'application doive avoir un log différent, ok. Mais
quand le serveur web est utilisé pour héberger plusieurs sites
différents, qui ont besoin de comprendre pourquoi ça ne marche pas, il
faut que l'utilisateur puisse avoir les messages d'erreur concernant son
hôte virtuel.


J'utilise souvent error_handler sur php,



set_error_handler est un gestionnaire d'erreur global. Il n'a donc pas
à être géré par une classe qui sera utilisée. Au pire, dans
l'application finale. Mais très franchement, ça ne sert à rien.
Personnellement, je désactive l'affichage des erreurs, et vérifie
systématiquement le retour des fonctions que j'utilises. En cas d'erreur
grâve, je lève une exception et je gère depuis l'appelant. C'est plus
propre. (d'ailleurs, j'espère que ce système d'erreur bancale
disparaîtra un jour).


Justement, error_handler ne permet pas, à mon avis, de gérer
proprement les erreurs.




En fait, je ne l'utilise jamais dans une classe mais dans l'appli.
Je trouve ça très pratique pour ma part car je demande un renvoie des
erreurs fatales et warning par mail et le reste part en log.
Bien sûr, tout cela pourrait ressortir dans mon logcheck que je reçois
toutes les heures s'il y a problème, mais je préfère un truc à part car
il ne s'agit pas d'erreurs système.


Je pense que Youtube prouve que lighttpd est un serveur solide.



En effet !


Par contre, attention aux habitudes : les .htaccess ne sont pas
chargés :) Et attention à la configuation. La version que j'ai sur mon
serveur Debian semble fâchée avec les regex dans la liste des fichiers
en deny. Ce qui est gênant.




.htaccess pas chargés, c'est-à-dire ?
Pour le reste, la config est très similaire ou il faut tout retranscrire
pour lighttpd ?
Mickaël Wolff
Le #22070131
Olivier Masson a écrit :

.htaccess pas chargés, c'est-à-dire ?



.htaccess est spécifique à Apache, et lighttpd n'en a que faire.


Pour le reste, la config est très similaire ou il faut tout retranscrire
pour lighttpd ?



C'est complètement différent. Ça utilises un langage spécifique, et
il me semble que LUA est en cours d'intégration pour fournir les
fonctionnalité de configuration à travers des scripts LUA.

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
Publicité
Poster une réponse
Anonyme