From 0b109d0796f4a5b4e9159b202a330faec58fd364 Mon Sep 17 00:00:00 2001 From: Lucien Gentis Date: Wed, 1 May 2013 11:24:11 +0000 Subject: [PATCH] Updates. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1477949 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/mod/event.xml.fr | 18 ++++++++++-------- docs/manual/mod/mod_lua.xml.fr | 19 ++++++++++--------- 2 files changed, 20 insertions(+), 17 deletions(-) diff --git a/docs/manual/mod/event.xml.fr b/docs/manual/mod/event.xml.fr index 874d640c5c..06ee8eb615 100644 --- a/docs/manual/mod/event.xml.fr +++ b/docs/manual/mod/event.xml.fr @@ -1,7 +1,7 @@ - + @@ -68,10 +68,12 @@ mobiliser des threads que pour les connexions en cours de traitementmod_status montre les connexions qui se trouvent dans les situations mentionnées.

-

Le gestionnaire de connexion amélioré ne fonctionne pas encore - pour certains filtres de connexion, et en particulier SSL. Pour les - connexions SSL, ce MPM réadopte le comportement du MPM - worker et réserve un thread par connexion.

+

Le gestionnaire de connexion amélioré peut ne pas + fonctionner pour les filtres de connexion qui se déclarent eux-mêmes + comme incompatibles avec le MPM event. Dans ce cas, le MPM event + adopte le comportement du MPM worker et + réserve un thread par connexion. Tous les modules fournis + avec le serveur sont compatibles avec le MPM event.

Le MPM présuppose que l'implémentation apr_pollset sous-jacente est raisonnablement sûre du point de vue des threads. @@ -165,8 +167,8 @@ mobiliser des threads que pour les connexions en cours de traitement

Le MPM event gère certaines connexions de manière asynchrone ; dans ce cas, les threads traitant la requête sont alloués selon les - besoins et pour de courtes périodes. Dans les autres cas (la plupart - du temps pour les connexions SSL), un thread est réservé par + besoins et pour de courtes périodes. Dans les autres cas, un + thread est réservé par connexion. Ceci peut conduire à des situations où tous les threads sont saturés et où aucun thread n'est capable d'effectuer de nouvelles tâches pour les connexions asynchrones établies.

@@ -183,7 +185,7 @@ mobiliser des threads que pour les connexions en cours de traitementCette directive permet de personnaliser finement la limite du nombre de connexions par thread. Un processus n'acceptera de nouvelles connexions que si le nombre actuel de connexions (sans - compter les connexions à l'état "closing") est + compter les connexions à l'état "closing") est inférieur à :

diff --git a/docs/manual/mod/mod_lua.xml.fr b/docs/manual/mod/mod_lua.xml.fr index 15526e78b9..f0b0748bc0 100644 --- a/docs/manual/mod/mod_lua.xml.fr +++ b/docs/manual/mod/mod_lua.xml.fr @@ -1,7 +1,7 @@ - + @@ -677,7 +677,7 @@ while nous_avons_des_données_à_envoyer do r:puts("Bla bla bla\n") -- envoi des données à envoyer vers le tampon r:flush() -- vidage du tampon (envoi au client) r:sleep(0.5) -- mise en attente et bouclage -+end +end @@ -696,22 +696,23 @@ end -r:parseargs() -- renvoie une table Lua contenant la chaîne -d'arguments de la requête +r:parseargs() -- renvoie deux tables : une table standard de couples +clé/valeur pour les données GET simples, et une autre pour les données +multivaluées (par exemple foo=1&foo=2&foo=3) : -local GET = r:parseargs() -+r:puts("Votre nom est : " .. GET['name'] or "Unknown") +local GET, GETMULTI = r:parseargs() +r:puts("Votre nom est : " .. GET['name'] or "Unknown") r:parsebody()([sizeLimit]) -- interprète le corps de la requête -en tant que POST et renvoie une table lua. Un nombre optionnel +en tant que POST et renvoie deux tables lua, comme r:parseargs(). Un nombre optionnel peut être fourni pour spécifier le nombre maximal d'octets à interpréter. La valeur par défaut est 8192. -local POST = r:parsebody(1024*1024) -+r:puts("Votre nom est : " .. POST['name'] or "Unknown") +local POST, POSTMULTI = r:parsebody(1024*1024) +r:puts("Votre nom est : " .. POST['name'] or "Unknown") -- 2.50.1