From: Lucien Gentis Date: Sun, 12 Jul 2026 13:18:05 +0000 (+0000) Subject: fr doc XML files updates. X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=d40d2b0fe25dc7a180b0a2f60069c971b4f3e325;p=thirdparty%2Fapache%2Fhttpd.git fr doc XML files updates. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1936086 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/mod_dbd.xml.fr b/docs/manual/mod/mod_dbd.xml.fr index 4875cdfd91..8937cd7257 100644 --- a/docs/manual/mod/mod_dbd.xml.fr +++ b/docs/manual/mod/mod_dbd.xml.fr @@ -1,7 +1,7 @@ - + diff --git a/docs/manual/mod/mod_heartmonitor.xml.fr b/docs/manual/mod/mod_heartmonitor.xml.fr index a7abcdfaec..4aa432efb8 100644 --- a/docs/manual/mod/mod_heartmonitor.xml.fr +++ b/docs/manual/mod/mod_heartmonitor.xml.fr @@ -1,7 +1,7 @@ - + @@ -114,10 +114,11 @@ serveur HTTP Apache contrôler la quantité de mémoire partagée allouée pour le stockage des données heartbeat lorsqu'on utilise mod_slotmem_shm.

-

Pour utiliser un stockage de type fichier bidimensionnel (flat-file) - lorque le module mod_slotmem_shm n'est pas chargé, cette - directive doit être définie à 0. La valeur doit être soit égale à 0, soit - supérieure ou égale à 10.

+ +

Définissez cette directive à 0 pour utiliser un stockage de + type fichier bidimensionnel (flat-file) au lieu de la mémoire partagée + (c’est-à-dire sans charger mod_slotmem_shm). Lorsqu’on + utilise la mémoire partagée, la valeur doit être supérieure ou égale à 10.

diff --git a/docs/manual/mod/mod_unique_id.xml.fr b/docs/manual/mod/mod_unique_id.xml.fr index adaaccaa54..c04ba0e84e 100644 --- a/docs/manual/mod/mod_unique_id.xml.fr +++ b/docs/manual/mod/mod_unique_id.xml.fr @@ -1,7 +1,7 @@ - + @@ -13,7 +13,7 @@ (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at - http://www.apache.org/licenses/LICENSE-2.0 +http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, @@ -73,27 +73,30 @@ identifiant unique pour chaque requête
  • Les temps des machines sont synchronisés via NTP ou tout autre protocole de synchronisation du temps en réseau.
    • -
  • Les nom d'hôtes des machines sont tous différents, de façon à - ce que le module puisse recevoir une adresse IP différente pour - chaque machine du cluster en effectuant une recherche sur le nom - d'hôte.
    • + Changements à partir de la version 2.4.29 +

    Dans les versions précédentes, l’unicité nécessitait aussi que chaque + machine ait une adresse IP distincte. Depuis la version 2.4.29, le module + utilise un générateur de nombres pseudo-aléatoires cryptographique (PRNG) + ensemencé au démarrage, tout en supprimant l’adresse IP et le PID de + l’identifiant et en ne nécessitant plus de noms d’hôte distincts ou de + délai au démarrage.

     +

    Au vu des caractéristiques actuelles du système d'exploitation, nous supposerons que les pids (identifiants processus) sont codés sur 32 bits. Si le système d'exploitation utilise plus de 32 bits pour un pid, la correction est triviale mais doit être effectuée dans le code.

    -

    Ces hypothèses posées, à un instant donné, nous pouvons - distinguer tout processus httpd sur toute machine du cluster de tous - les autres processus httpd. Pour ce faire, il suffit d'utiliser - l'adresse IP de la machine et le pid du processus httpd. Un - processus httpd peut traiter plusieurs requêtes simultanément si - vous utilisez un module MPM multi-threadé. Pour identifier les - threads, Apache httpd utilise en interne un index de threads. Ainsi, - afin de générer des identifiants uniques pour chaque requête, il - suffit d'effectuer une distinction en fonction du temps.

    +

    Ces hypothèses posées, à un instant donné, nous pouvons distinguer tout + processus httpd sur toute machine du cluster de tous les autres processus + httpd. La valeur racine générée par PRNG et l’index des threads permettent + d’accomplir cette tâche. Un processus httpd peut traiter plusieurs requêtes + simultanément si vous utilisez un module MPM multi-threadé. Pour identifier + les threads, Apache httpd utilise en interne un index de threads. Ainsi, + afin de générer des identifiants uniques pour chaque requête, il suffit + d'effectuer une distinction en fonction du temps.

    Pour déterminer le temps, nous utiliserons un repère de temps Unix (les secondes écoulées depuis le 1er janvier 1970 UTC), et un @@ -175,21 +178,21 @@ identifiant unique pour chaque requête redémarrage.

    -

    La variable d'environnement UNIQUE_ID est construite - par codage du quadruplet de 144 bits (adresse IP sur 32 bits, pid - sur 32 bits, repère de temps sur 32 bits, compteur 16 bits et index - de threads sur 32 bits) en +

    Depuis la version 2.4.29, la variable d'environnement UNIQUE_ID est construite + par codage d’une valeur de 160 bits (32 bits pour l’horodatage, 80 bits pour + la racine PRNG, 16 bits pour le compteur et 32 bits pour l’index des + threads)) en utilisant l'alphabet [A-Za-z0-9_-] d'une manière similaire à celle du codage MIME base64, et sa valeur se présente - sous la forme d'une chaîne de 24 caractères. L'alphabet MIME base64 + sous la forme d'une chaîne de 27 caractères. L'alphabet MIME base64 est en fait [A-Za-z0-9+/] ; cependant, les caractères + et / nécessitent un codage particulier dans les URLs, ce qui rend leur utilisation peu commode. Toutes les valeurs sont codées dans l'ordre des octets d'une adresse réseau de façon à ce que le codage soit comparable entre des architectures où l'ordre des - octets est différent. L'ordre réel de codage est : repère de temps, - adresse IP, pid, compteur. Cet ordre de codage possède un but + octets est différent. L'ordre réel de codage est : horodatage, racine, + compteur, index des threads. Cet ordre de codage possède un but précis, mais il faut souligner que les applications n'ont aucun intérêt à entrer dans les détails de ce codage. Les applications doivent se contenter de traiter la variable UNIQUE_ID @@ -217,12 +220,7 @@ identifiant unique pour chaque requête machines du cluster (seule la synchronisation NTP est requise, ce qui représente une charge très faible), et aucune communication entre les processus httpd n'est nécessaire (la communication est - implicite et incluse dans le pid assigné par le noyau). Dans des - situations très spécifiques, l'identifiant peut être raccourci, mais - dans ce cas, d'avantage d'informations doivent être admises (par - exemple, les 32 bits de l'adresse IP sont excessifs pour la plupart - des sites, mais il n'existe pas de valeur de remplacement portable - plus courte).

    + implicite dans la graine PRNG assignée au démarrage)..

    diff --git a/docs/manual/suexec.xml.fr b/docs/manual/suexec.xml.fr index 32224f76a2..e161c36159 100644 --- a/docs/manual/suexec.xml.fr +++ b/docs/manual/suexec.xml.fr @@ -3,7 +3,7 @@ - +