l'empreinte mémoire d'un processus php laissé en tâche de fond augmente. C'est d'ailleurs pour cela que la variable PHP_FCGI_MAX_REQUESTS a été créée.
Tu peux détailler ?
Je parlais de tous ces exploits qui ont permis la désactivation de l'open_basedir, du safe_mode, du disable_functions. J'avais lu un article à ce sujet (dans misc peut-être) je n'arrives pas à remettre la main dessus. De ce que j'ai compris dans la quasi totalité des cas c'est on arrivait dans un traitement (particulièrement dans un traitement d'erreur) à modifier une variable dans la conf. Il faut vraiment que je retrouve cet article sinon je vais dire des conneries.
Je parle aussi du fait que l'utilisation sur des serveurs en thread n'est pas possible. Parce qu'au dernières nouvelles le parser n'est ni thread-safe ni réentrant.
L'utilisation en event n'est pas possible non plus car le processus php ne peut rester en tâche de fond pour cause de gonflement de l'empreinte mémoire.
On doit donc rester dans un modèle un processus par requête.
e pense que tu parle de récusion. En effet, PHP crash en cas de récursion trop profonde, parce que chaque niveau de récursion prend un peu de place sur la pile, et quand la pile est pleine, ça crash.
Oui ça crashe et c'est bien normal. Par contre sous apache ça te sert une page et pas en fastcgi. Il n'y a pas de mystère la dedans. C'est la gestion de la sortie standard qui est différente. Le problème ici n'est pas d'avoir une erreur 500 en fastcgi mais d'avoir un 200 sous apache.
De quoi tu parles ?
Voir plus haut
Ce sont des "features" dépréciée et désactivée par défaut dans 5.3.
Non. Les fonctions de sandboxing ne sont pas dépréciées (sauf le safe_mode).
Et permet moi d'avoir un léger doute quand je vois comment un serveur http a été introduit à l'arache dans la sapi cli. Php 5.3 est un progres peut-être mais beaucoup de travail reste à faire.
[^] # Re: Pour compléter...
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche État d'insécurité chez PHP. Évalué à 6.
l'empreinte mémoire d'un processus php laissé en tâche de fond augmente. C'est d'ailleurs pour cela que la variable PHP_FCGI_MAX_REQUESTS a été créée.
Je parlais de tous ces exploits qui ont permis la désactivation de l'open_basedir, du safe_mode, du disable_functions. J'avais lu un article à ce sujet (dans misc peut-être) je n'arrives pas à remettre la main dessus. De ce que j'ai compris dans la quasi totalité des cas c'est on arrivait dans un traitement (particulièrement dans un traitement d'erreur) à modifier une variable dans la conf. Il faut vraiment que je retrouve cet article sinon je vais dire des conneries.
Je parle aussi du fait que l'utilisation sur des serveurs en thread n'est pas possible. Parce qu'au dernières nouvelles le parser n'est ni thread-safe ni réentrant.
L'utilisation en event n'est pas possible non plus car le processus php ne peut rester en tâche de fond pour cause de gonflement de l'empreinte mémoire.
On doit donc rester dans un modèle un processus par requête.
Oui ça crashe et c'est bien normal. Par contre sous apache ça te sert une page et pas en fastcgi. Il n'y a pas de mystère la dedans. C'est la gestion de la sortie standard qui est différente. Le problème ici n'est pas d'avoir une erreur 500 en fastcgi mais d'avoir un 200 sous apache.
Voir plus haut
Non. Les fonctions de sandboxing ne sont pas dépréciées (sauf le safe_mode).
Et permet moi d'avoir un léger doute quand je vois comment un serveur http a été introduit à l'arache dans la sapi cli. Php 5.3 est un progres peut-être mais beaucoup de travail reste à faire.