From: Vincent Deffontaines Date: Mon, 18 Dec 2017 18:50:04 +0000 (+0000) Subject: Introducing 3 new .fr translations X-Git-Tag: 2.5.0-alpha2-ci-test-only~3062 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=3370f733e021fa303f3295231f02b0ad5b6f4c8c;p=thirdparty%2Fapache%2Fhttpd.git Introducing 3 new .fr translations git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1818608 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/mod_journald.xml.fr b/docs/manual/mod/mod_journald.xml.fr new file mode 100644 index 00000000000..88908c6d5ff --- /dev/null +++ b/docs/manual/mod/mod_journald.xml.fr @@ -0,0 +1,106 @@ + + + + + + + + + + + +mod_journald +Implémentation du fournisseur de journalisation d'erreurs +"journald" +Extension +mod_journald.c +journald_module + + +

Ce module implémente le fournisseur de journalisation d'erreurs + "journald". Il permet l'enregistrement des messages d'erreur et la + gestion des journaux personnalisés via systemd-journald(8).

+ + +
+ Jounalisation structurée +

Systemd-journald permet d'effectuer une journalisation + structurée, et autorise donc le filtrage des messages en fonction de + diverses variables. Les variables actuellement supportées sont : +

+
+
LOG
+
Le nom du journal. Pour ErrorLog, la valeur est "error_log". + Pour CustomLog ou TransferLog, la valeur correspond au premier + argument de ces directives.
+
REQUEST_HOSTNAME
+
Le nom d'hôte tel qu'il est fourni dans l'URI, ou l'en-tête + Host: de la requête.
+
REQUEST_USER
+
Correspond au nom d'utilisateur si une authentification a eu + lieu.
+
REQUEST_USERAGENT_IP
+
L'adresse IP de l'agent qui a envoyé la requête.
+
REQUEST_URI
+
La partie chemin de l'URI, ou "/" si l'URI ne contient pas de + chemin.
+
SERVER_HOSTNAME
+
Le nom d'hôte du serveur pour lequel le message a été généré.
+
+ +

Ces variables peuvent par exemple être utilisées pour ne montrer + que les messages concernant un URI particulier via la commande + journalctl : +

+ + journalctl REQUEST_URI=/index.html -a + +

Pour d'autres exemples, voir la documentation de + systemd-journalctl.

+
+ +
+ Exemples + +

Si le système le supporte, il est possible d'utiliser + systemd-journald(8) pour effectuer la journalisation en spécifiant + journald à la place d'un nom de fichier dans la + directive ErrorLog (voir core). +

+ + ErrorLog journald + +

Spécifier journald comme fournisseur de journal + d'erreurs avec la directive CustomLog (voir + mod_log_config) active la journalisation via + systemd-journald(8) si le système le supporte. +

+ + +CustomLog "journald" "%h %l %u %t \"%r\" %>s %b" + + + Avertissement en matière de performances

+ Actuellement, systemd-journald n'est pas conçu pour une + jounalisation à haut débit et son utilisation pour la journalisation + des accès peut induire une baisse importante de performances. +

+ +
+ + diff --git a/docs/manual/mod/mod_journald.xml.meta b/docs/manual/mod/mod_journald.xml.meta index b5c437a9753..e5d59c35084 100644 --- a/docs/manual/mod/mod_journald.xml.meta +++ b/docs/manual/mod/mod_journald.xml.meta @@ -8,5 +8,6 @@ en + fr diff --git a/docs/manual/mod/mod_policy.xml.fr b/docs/manual/mod/mod_policy.xml.fr new file mode 100644 index 00000000000..ff0cac58ca9 --- /dev/null +++ b/docs/manual/mod/mod_policy.xml.fr @@ -0,0 +1,757 @@ + + + + + + + + + + + +mod_policy +Mise en conformité avec le protocole HTTP. +Extension +mod_policy.c +policy_module + + +

Le protocole HTTP recommande aux clients d'être "indulgents pour + ce qu'ils doivent accepter", et aux serveurs d'être "stricts pour ce + qu'ils envoient". Dans certains cas, il peut s'avérer difficile de + déterminer si un serveur ou une application a été mal configuré, + sert un contenu qui ne peut pas être mis en cache ou se comporte de + manière non optimale, car le client HTTP est souvent en mesure de + compenser les défauts du serveur. Ces problèmes peuvent induire une + consommation de bande passante excessive, ou même une interruption + de service suite à une charge trop importante du serveur.

+ +

Le module mod_policy propose un jeu de filtres + qui permettent de tester la conformité du serveur au protocole HTTP. + Ces tests permettent à l'administrateur du serveur de journaliser + les violations, ou même de rejeter une réponse losque certaines + conditions spécifiées se réalisent.

+ +

Il devient ainsi possible de définir des critères de conformité + minimale au protocole HTTP pour développer des applications + sans problème. En outre, il est possible de configurer un + mandataire inverse ou un cache pour qu'il se protège lui-même contre + les serveurs d'origine mal configurés ou les contenus indument + impossible à être mis en cache, ou un mécanisme qui détecte les + erreurs de configuration au sein du serveur lui-même.

+ + +Les filtres +Conformité au protocole HTTP + +
+ Actions + +

Si une règle est violée, il possible d'effectuer les actions + suivantes :

+ +
+
ignore
+
La vérification de la politique de conformité sera désactivée + pour l'espace d'URL spécifié, même si le filtre est présent.
+ +
log
+
La vérification de la politique de conformité sera exécutée, et + si une violation est détectée, un avertissement sera enregistré dans + le journal error_log du serveur, et un en-tête Warning + ajouté à la réponse en tant qu'information à destination du client.
+ +
enforce
+
La vérification de la politique de conformité sera exécutée, + + The policy check will be executed, and if a violation is detected + an error will be logged to the server error_log, a + Warning header added to the response, and a 502 + Bad Gateway will be returned to the client. Optional links to + explanatory documentation can be added to each error message, + detailing the origin of each policy.
+ +
+ +

Il est aussi possible de désactiver toutes les règles pour un + espace d'URL donné, si le besoin s'en fait sentir, via la directive + PolicyFilter.

+ +

En outre, la directive PolicyEnvironment permet de + spécifier une variable d'environnement qui, si elle est définie, va + court-circuiter les règles ou diminuer leur portée.

+ +
+ +
+ Tests de la politique de filtrage + +

Les filtres suivants sont disponibles :

+ +
+
POLICY_TYPE + : Impose la validité des types de contenus
+
La requête peut être rejetée suite à la présence de types de contenus vides + ou syntaxiquement invalides. Les types peuvent aussi être restreints + à une liste pouvant contenir des caractères génériques ? et *.
+ +
POLICY_LENGTH + : Impose la présence de l'en-tête Content-Length
+
La longueur des réponses peut être spécifiée de trois manières + différentes : en spécifiant à l'avance une longueur explicite, en + utilisant un codage de morcellement (chunking) pour définir la + longueur, ou en ne spécifiant aucune longueur et en terminant la + requête lorsque son traitement est achevé. L'absence de + spécification d'une longueur de contenu peut affecter la possibilité + de mise en cache de la réponse, et empêcher l'utilisation de la + persistance avec les requêtes de type HTTP/1.0. Ce filtre impose la + présence d'une longueur de contenu explicite dans la réponse.
+ +
POLICY_KEEPALIVE + : Impose l'option de persistance
+
Moins restrictif que le filtre POLICY_LENGTH, ce filtre impose + la possibilité de persistance de la réponse. Si la réponse n'a pas + de longueur définie à 0 par le protocole, si elle n'est pas une + erreur, et si elle ne contient pas d'en-tête Content-Length ou si + elle est de type HTTP/1.1 et ne contient pas l'en-tête + Content-Encoding: chunked, alors elle sera rejetée.
+ +
POLICY_VARY + : Interdit la présence de certains en-têtes au sein des + en-têtes Vary
+
Si l'en-tête Vary contient un des en-têtes spécifiés, ce filtre + va rejeter la requête. Un cas typique est la présence de l'en-tête + User-Agent dans l'en-tête Vary, ce qui peut être à l'origine d'une + condition de déni de service au niveau du cache.
+ +
+ POLICY_VALIDATION: Impose la présence d'un en-tête Etag + et/ou Last-Modified
+
La possibilité pour un cache de déterminer si une entité qu'il + contient peut être rafraîchie dépend de la présence d'un en-tête + Etag et/ou Last-Modified pour vérifier si elle est valide. La requête sera + rejetée en cas d'absence de ces deux en-têtes, ou d'une syntaxe + invalide d'un de ces deux en-têtes.
+ +
+ POLICY_CONDITIONAL: Impose un traitement conforme des + en-têtes conditionnels
+
Lorsqu'une requête contient des en-têtes conditonnels, un + serveur doit répondre dans certaines conditions avec un code + 304 Not Modified ou 412 Precondition + Failed. Il arrive q'un serveur ignore les en-têtes + conditionnels, et cela diminue l'efficacité du mécanisme de mise en + cache HTTP. Ce filtre rejète les requêtes lorsqu'un en-tête + conditionnel était présent, et une réponse 2xx a été renvoyée au + lieu de la réponse 304 ou 412 attendue.
+ +
POLICY_NOCACHE + : Impose la possibilité de mise en cache des réponses
+
Lorsqu'une requête se déclare elle-même impossible à mettre en + cache, elle est rejetée. C'est le cas si elle contient l'un des + en-têtes suivants : +
  • Cache-Control: no-cache
    • +
  • Pragma: no-cache
    • +
  • Cache-Control: no-store
    • +
  • Cache-Control: private
    • +
+ +
POLICY_MAXAGE + : Impose une durée de vie minimale
+
Lorsqu'une réponse possède une durée de vie inférieure à la + valeur spécifiée, ou si cette durée de vie est heuristique, la + requête est rejetée. La chronologie de la vérification d'une réponse + est la suivante : +
  • Si s-maxage est présent mais d'une valeur trop + faible; ou
    • +
  • Si max-age est présent mais d'une valeur trop + faible; ou
    • +
  • Si Expires est présent et invalide; ou
    • +
  • Date est présent et invalide; ou
    • +
  • Expires moins Date est trop faible ; ou
    • +
  • Aucun en-tête s-maxage, maxage, ou + Expires/Date n'est présent
    • +
+ +
POLICY_VERSION + : Impose une version HTTP minimale dans la requête
+
Lorsqu'une requête possède un numéro de version HTTP inférieur + au numéro de version minimum requis, la requête est rejetée. Les + numéros de version suivants sont reconnus : +
  • HTTP/1.1
    • +
  • HTTP/1.0
    • +
  • HTTP/0.9
    • +
+ +
+ +
+ +
+ Exemple de configuration + +

Voici un exemple de configuration qui protège un serveur qui + délivre du contenu statique :

+ + +<Location "/"> + SetOutputFilter POLICY_TYPE;POLICY_LENGTH;POLICY_KEEPALIVE;POLICY_VARY;POLICY_VALIDATION; \ + POLICY_CONDITIONAL;POLICY_NOCACHE;POLICY_MAXAGE;POLICY_VERSION + + # le contenu peut être quelconque, mais l'en-tête Content-Type doit être + # présent et valide + PolicyType enforce */* + + # rejet si aucune longueur de contenu déclarée + PolicyLength enforce + + # pris en charge par le filtre policy length + PolicyKeepalive ignore + + # rejet si l'en-tête User-Agent aparaît dans les en-têtes Vary + PolicyVary enforce User-Agent + + # la validation est imposée + PolicyValidation enforce + + # les réponses conditionnelles non conformes sont rejetées + PolicyConditional enforce + + # les réponses impossibles à mettre en cache sont rejetées + PolicyNocache enforce + + # la durée de vie doit être au moins d'un jour + PolicyMaxage enforce 86400 + + # le numéro de version de la requête peut être quelconque + PolicyVersion ignore HTTP/1.1 +</Location> + +# désactivation du filtrage pour le répertoire /server-status +<Location "/server-status"> + PolicyFilter off +</Location> + + +
+ + + +PolicyFilter +Active ou désactive le filtrage pour un espace d'URL donné. +PolicyFilter on|off +on +server configvirtual host +directory +Disponible à partir de la version 2.5.0 du serveur HTTP +Apache. + + +

Commutateur principal qui permet d'activer ou de désactiver le + filtrage pour un espace d'URL donné.

+ + Example + +# activé par défaut +<Location "/"> + PolicyFilter on +</Location> + +# désactivation du filtrage pour le répertoire /server-status +<Location "/server-status"> + PolicyFilter off +</Location> + + + + + + + + +PolicyEnvironment +Modification des règles de filtrage en fonction d'une +variable d'environnement. +PolicyEnvironment variable log-value ignore-value +none +server configvirtual host +directory +Disponible à partir de la version 2.5.0 du serveur HTTP +Apache. + + +

Limite l'action des règles à la journalisation ou les désactive + totalement en fonction de la présence d'une variable d'environnement. Si + la variable spécifiée est présente et égale à la valeur de + l'argument log-value, les erreurs rencontrées par les filtres ne + seront que journalisées. Si la variable spécifiée est présente et + égale à la valeur de l'argument ignore-value, toutes les règles + seront ignorées.

+ + Example + +# limitation de l'action des règles si la variable POLICY_CONTROL +# est présente +PolicyEnvironment POLICY_CONTROL log ignore + + + + + + + + +PolicyConditional +Active le filtrage des requêtes conditionnelles. +PolicyConditional ignore|log|enforce +ignore +server configvirtual host +directory +Disponible à partir de la version 2.5.0 du serveur HTTP +Apache. + + +

Avec l'argument enforce, une réponse qui aurait du être + conditionnelle mais ne l'est pas sera rejetée.

+ + Exemple + +# les réponses conditionnelles non conformes doivent être rejetées +PolicyConditional enforce + + + + + + + + + + +PolicyConditionalURL +URL contenant la description de la politique de filtrage +des requêtes conditionnelles. +PolicyConditionalURL url +none +server configvirtual host +directory +Disponible à partir de la version 2.5.0 du serveur HTTP +Apache. + + +

Cette directive permet de spécifier l'URL de la documentation + décrivant la politique de filtrage des requêtes conditionnelles ; + elle apparaîtra dans les messages d'erreur.

+ + + + + + +PolicyLength +Active le filtrage de la spécification de la longueur du +contenu. +PolicyLength ignore|log|enforce +ignore +server configvirtual host +directory +Disponible à partir de la version 2.5.0 du serveur HTTP +Apache. + + +

Avec l'argument enforce, une réponse qui ne contient pas + d'en-tête Content-Length sera rejetée.

+ + Exemple + +# rejet suite à l'absence de l'en-tête Content-Length +PolicyLength enforce + + + + + + + + +PolicyLengthURL +URL contenant la description de la politique de filtrage de +la spécification de la longueur du contenu. +PolicyLengthURL url +none +server configvirtual host +directory +Disponible à partir de la version 2.5.0 du serveur HTTP +Apache. + + +

Cette directive permet de spécifier l'URL contenant la + documentation décrivant la politique de filtrage de la spécification + de la longueur du contenu ; elle apparaîtra dans les messages + d'erreur.

+ + + + + + +PolicyKeepalive +Active la politique de persistance. +PolicyKeepalive ignore|log|enforce +ignore +server configvirtual host +directory +Disponible à partir de la version 2.5.0 du serveur HTTP +Apache. + + +

Avec l'argument enforce, une réponse qui ne contient ni en-tête + Content-Length, ni en-tête + Transfer-Encoding de valeur chunked sera + rejetée.

+ + Exemple + +# rejet suite a absence d'en-tête Content-Length ou Transfer-Encoding +PolicyKeepalive enforce + + + + + + + + +PolicyKeepaliveURL +URL contenant la description de la politique de persistance. +PolicyKeepaliveURL url +none +server configvirtual host +directory +Disponible à partir de la version 2.5.0 du serveur HTTP +Apache. + + +

Cette directive permet de spécifier l'URL contenant la + description de la politique de persistance ; elle apparaîtra dans + les messages d'erreur.

+ + + + + + +PolicyType +Active la politique des types de contenus. +PolicyType ignore|log|enforce type [ type [ ... ]] +ignore +server configvirtual host +directory +Disponible à partir de la version 2.5.0 du serveur HTTP +Apache. + + +

Avec l'argument enforce, une réponse qui ne contient pas + d'en-tête Content-Type, ou dont l'en-tête + Content-Type est mal formé, ou dont l'en-tête + Content-Type contient une valeur qui ne correspond pas + au(x) modèle(s) spécifié(s) sera rejetée.

+ + Exemple + +# impose le type de contenu json ou XML +PolicyType enforce application/json text/xml + + + + Exemple + +# rejet suite à type de contenu mal formé +PolicyType enforce */* + + + + + + + + + +PolicyTypeURL +URL contenant la description de la politique des types de +contenu. +PolicyTypeURL url +none +server configvirtual host +directory +Disponible à partir de la version 2.5.0 du serveur HTTP +Apache. + + +

Cette directive permet de spécifier l'URL contenant la + description de la politique des types de contenu ; elle apparaîtra + dans les messages d'erreur.

+ + + + + + +PolicyVary +Active la politique de filtrage de l'en-tête Vary. +PolicyVary ignore|log|enforce header [ header [ ... ]] +ignore +server configvirtual host +directory +Disponible à partir de la version 2.5.0 du serveur HTTP +Apache. + + +

Avec l'argument enforce, une réponse dont l'en-tête + Vary contient un des en-têtes spécifiés sera rejetée.

+ + Exemple + +# rejet suite à la présence de l'en-tête "User-Agent" dans l'en-tête +# Vary +PolicyVary enforce User-Agent + + + + + + + + + +PolicyVaryURL +URL contenant la description de la politique de filtrage de +l'en-tête Vary. +PolicyVaryURL url +none +server configvirtual host +directory +Disponible à partir de la version 2.5.0 du serveur HTTP +Apache. + + +

Cette directive permet de spécifier l'URL contenant la + description de la politique de filtrage de l'en-tête Vary ; elle + apparaîtra dans les messages d'erreur.

+ + + + + + +PolicyValidation +Active le filtrage de la validation du contenu. +PolicyValidation ignore|log|enforce +ignore +server configvirtual host +directory +Disponible à partir de la version 2.5.0 du serveur HTTP +Apache. + + +

Avec l'argument enforce, une réponse qui ne contient ni en-tête + ETag valide, ni en-tête Last-Modified, ou + dont la syntaxe d'un de ces deux en-têtes est incorrecte sera + rejetée.

+ + Exemple + +# rejet suite à l'absence des en-têtes Etag et/ou Last-Modified +PolicyValidation enforce + + + + + + + + + +PolicyValidationURL +URL contenant la description de la politique de filtrage de +la validation du contenu. +PolicyValidationURL url +none +server configvirtual host +directory +Disponible à partir de la version 2.5.0 du serveur HTTP +Apache. + + +

Cette directive permet de spécifier l'URL contenant la + description de la politique de filtrage de la validation du contenu + ; elle apparaîtra dans les messages d'erreur.

+ + + + + + +PolicyNocache +Active le filtrage des réponses qui se définissent +elles-mêmes comme impossibles à mettre en cache. +PolicyNocache ignore|log|enforce +ignore +server configvirtual host +directory +Disponible à partir de la version 2.5.0 du serveur HTTP +Apache. + + +

Avec l'argument enforce, une réponse qui se définit elle-même + comme impossible à mettre en cache via l'en-tête + Cache-Control ou Pragma sera rejetée.

+ + Exemple + +# une réponse contenant l'en-tête Cache-Control: no-cache sera +# rejetée +PolicyNocache enforce + + + + + + + + + +PolicyNocacheURL +URL contenant la description de la politique de filtrage +des réponses qui se définissent elles-mêmes comme impossibles à mettre +en cache. +PolicyNocacheURL url +none +server configvirtual host +directory +Disponible à partir de la version 2.5.0 du serveur HTTP +Apache. + + +

Cette directive permet de spécifier l'URL contenant la + description de la politique de filtrage des réponses qui se + définissent elles-mêmes comme impossibles à mettre en cache ; elle + apparaîtra dans les messages d'erreur.

+ + + + + + +PolicyMaxage +Active le filtrage de la durée de vie des réponses. +PolicyMaxage ignore|log|enforce age +ignore +server configvirtual host +directory +Disponible à partir de la version 2.5.0 du serveur HTTP +Apache. + + +

Avec l'argument enforce, une réponse dont la durée de vie n'est + pas explicitement spécifiée via un en-tête max-age, + s-maxage ou Expires, ou dont la durée de + vie est inférieure à la valeur donnée sera rejetée.

+ + Exemple + +# rejet des réponses dont la durée de vie est inférieure à une +# journée +PolicyMaxage enforce 86400 + + + + + + + + + +PolicyMaxageURL +URL contenant la description de la politique de filtrage +des réponses en fonction de leur durée de vie. +PolicyMaxageURL url +none +server configvirtual host +directory +Disponible à partir de la version 2.5.0 du serveur HTTP +Apache. + + +

Cette directive permet de spécifier l'URL contenant la + description de la politique de filtrage des réponses en fonction de + leur durée de vie ; elle apparaîtra dans les messages d'erreur.

+ + + + + + +PolicyVersion +Active le filtrage des requêtes en fonction du numéro de +version HTTP. +PolicyVersion ignore|log|enforce HTTP/0.9|HTTP/1.0|HTTP/1.1 +ignore +server configvirtual host +directory +Disponible à partir de la version 2.5.0 du serveur HTTP +Apache. + + +

Avec l'argument enforce, une requête dont le numéro de version + HTTP est inférieur à la valeur spécifiée sera rejetée.

+ + Exemple + +# rejet des requêtes dont le numéro de version HTTP est inférieur à +# HTTP/1.1 +PolicyVersion enforce HTTP/1.1 + + + + + + + + + +PolicyVersionURL +URL contenant la description de la politique de filtrage +des requêtes en fonction du numéro de version HTTP. +PolicyVersionURL url +none +server configvirtual host +directory +Disponible à partir de la version 2.5.0 du serveur HTTP +Apache. + + +

Cette directive permet de spécifier l'URL contenant la + description de la politique de filtrage des requêtes en fonction du + numéro de version HTTP ; elle apparaîtra dans les messages d'erreur.

+ + + + + diff --git a/docs/manual/mod/mod_policy.xml.meta b/docs/manual/mod/mod_policy.xml.meta index 4198cf4ed1c..751487a8130 100644 --- a/docs/manual/mod/mod_policy.xml.meta +++ b/docs/manual/mod/mod_policy.xml.meta @@ -8,5 +8,6 @@ en + fr diff --git a/docs/manual/mod/mod_proxy_hcheck.xml.fr b/docs/manual/mod/mod_proxy_hcheck.xml.fr new file mode 100644 index 00000000000..27ebe78f687 --- /dev/null +++ b/docs/manual/mod/mod_proxy_hcheck.xml.fr @@ -0,0 +1,274 @@ + + + + + + + + + + + + +mod_proxy_hcheck +Check up dynamique des membres du groupe de répartition de charge +(équipiers) pour mod_proxy +Extension +mod_proxy_hcheck.c +proxy_hcheck_module +Disponible à partir de la version 2.4.21 du serveur HTTP Apache + + +

Ce module permet d'effectuer un check up dynamique des membres du groupe + de répartition de charge (équipiers). Ce check up peut être activé pour un + ou plusieurs équipiers et il est indépendant des requêtes de mandataire + inverse proprement dites.

+ +

Pour fonctionner, ce module nécessite le chargement préalable de + mod_watchdog.

+ +Paramètres +

Le mécanisme de check up est activé via l'utilisation de paramètres + supplémentaires de BalancerMember configurés de manière standard via la + directive ProxyPass :

+ +

Ce module définit un nouveau drapeau d'état pour BalancerMember : + "C". Lorsque l'équipier est mis hors service suite à un + disfonctionnement déterminé par le module de check up, ce drapeau est activé + et peut être lu (et modifié) via le balancer-manager.

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
ParamètreDéfautDescription
hcmethodNoneAucun check up dynamique n'est effectué. Les choix possibles sont : + + + + + + + + + + +
MethodDescriptionNote
NoneAucun check up dynamique effectué
TCPVérifie qu'un socket vers le serveur + d'arrière-plan peut être créé ; par exemple "es-tu en + état de fonctionner"
OPTIONSEnvoie une requête HTTP + OPTIONS au serveur d'arrière-plan*
HEADEnvoie une requête HTTP + HEAD au serveur d'arrière-plan*
GETEnvoie une requête HTTP + GET au serveur d'arrière-plan*
*: si hcexpr n'est pas + utilisé, un retour HTTP 2xx ou 3xx sera + interprété comme un passage avec succès du check + up.
+
hcpasses1Nombre de check up à passer avec succès avant de remettre en service + l'équipier
hcfails1Nombre de check up échoués avant mettre hors service l'équipier
hcinterval30Intervalle entre deux check up en secondes (par défaut effectué + toutes les 30 secondes). Utilise la syntaxe time-interval.
hcuri URI supplémentaire à ajouter à l'URL de l'équipier pour le check up.
hctemplate Nom du modèle créé via ProxyHCTemplate à + utiliser pour définir les paramètres de check up de cet équipier
hcexpr Nom de l'expression créée via ProxyHCExpr + utilisée pour analyser les en-têtes de la réponse du check up.
+ Si ce paramètre est absent, un état HTTP de 2xx à 3xx est + interprété comme un check up réussi.
+ + + +mod_proxy + +
+ + Exemples d'utilisation +

L'exemple suivant montre comment configurer le check up pour différents + serveurs d'arrière-plan :

+ + + +ProxyHCExpr ok234 {%{REQUEST_STATUS} =~ /^[234]/} +ProxyHCExpr gdown {%{REQUEST_STATUS} =~ /^[5]/} +ProxyHCExpr in_maint {hc('body') !~ /Under maintenance/} + +<Proxy balancer://foo> + BalancerMember http://www.example.com/ hcmethod=GET hcexpr=in_maint hcuri=/status.php + BalancerMember http://www2.example.com/ hcmethod=HEAD hcexpr=ok234 hcinterval=10 + BalancerMember http://www3.example.com/ hcmethod=TCP hcinterval=5 hcpasses=2 hcfails=3 + BalancerMember http://www4.example.com/ +</Proxy> + +ProxyPass "/" "balancer://foo" +ProxyPassReverse "/" "balancer://foo" + + +

Dans ce scénario, on teste l'équipier http://www.example.com/ en lui +envoyant une requête GET /status.php et en regardant si la réponse +contient la chaîne Under maintenance. Si c'est le cas, le check up est +considéré comme ayant échoué et l'équipier est mis hors service. Ce check up +dynamique est effectué toutes les 30 secondes, ce qui correspond à la valeur par +défaut.

+ +

On teste l'équipier http://www2.example.com/ en lui envoyant +simplement une requête HEAD toutes les 10 secondes et en vérifiant +que la réponse HTTP est bien un code d'état de 2xx, 3xx ou 4xx. On teste +l'équipier http://www3.example.com/ en vérifiant simplement toutes +les 5 secondes que le socket vers ce serveur est bien opérationnel. Si ce +serveur est marqué "hors service", il lui faudra 2 check up réussis pour être +réactivé et participer à nouveau à la répartition de charge. Si à ce moment-là +il échoue à 3 check up successifs, il sera à nouveau mis hors service. Enfin, +l'équipier http://www4.example.com/ ne fait l'objet d'aucun check +up.

+ +
+ + +ProxyHCExpr +Crée et nomme une expression conditionnelle à utiliser pour +déterminer la santé d'un serveur d'arrière-plan en fonction de sa valeur. +ProxyHCExpr name {ap_expr expression} +server configvirtual host + +FileInfo + + +

La directive ProxyHCExpr permet de créer et nommer + une expression conditionnelle dont la valeur calculée en fonction des + en-têtes de la réponse du serveur d'arrière-plan permettra d'évaluer la + santé de ce dernier. Cette expression nommée peut alors être assignée aux + serveurs d'arrière-plan via le paramètre hcexpr.

+ + ProxyHCExpr: interprète les réponses 2xx/3xx/4xx comme des + check up réussis + +ProxyHCExpr ok234 {%{REQUEST_STATUS} =~ /^[234]/} +ProxyPass "/apps" "balancer://foo" + +<Proxy balancer://foo> + BalancerMember http://www2.example.com/ hcmethod=HEAD hcexpr=ok234 hcinterval=10 +</Proxy> + + + + + L'expression peut utiliser des accolades ("{}") + comme délimiteurs en plus des guillemets normaux. + + +

Si l'on utilise une méthode de check up (par exemple GET) + qui génère un corps de réponse, ce corps peut lui-même être ausculté via + ap_expr en utilisant la fonction associée aux expressions + hc() spécifique à ce module.

+ +

Dans l'exemple suivant, on envoie une requête GET au serveur + d'arrière-plan, et si le corps de la réponse contient la chaîne Under + maintenance, ce serveur d'arrière-plan est mis hors service.

+ + ProxyHCExpr: auscultation du corps de la réponse + +ProxyHCExpr in_maint {hc('body') !~ /Under maintenance/} +ProxyPass "/apps" "balancer://foo" + +<Proxy balancer://foo> + BalancerMember http://www.example.com/ hcexpr=in_maint hcmethod=get hcuri=/status.php +</Proxy> + + + +

NOTE: Comme le corps de la réponse peut être assez grand, il est + recommandé de privilégier un check up basé sur les codes d'état.

+ + + + + +ProxyHCTemplate +Crée et nomme un modèle permettant de définir différents +paramètres de check up +ProxyHCTemplate name parameter=setting <...> +server configvirtual host + +FileInfo + + +

La directive ProxyHCTemplate permet de créer et + nommer un modèle de paramètres de check up qui peut alors être assigné aux + équipiers via le paramètre hctemplate

+ + ProxyHCTemplate + +ProxyHCTemplate tcp5 hcmethod=tcp hcinterval=5 +ProxyPass "/apps" "balancer://foo" + +<Proxy balancer://foo> + BalancerMember http://www2.example.com/ hctemplate=tcp5 +</Proxy> + + + + + + + +ProxyHCTPsize +Définit la taille totale, pour l'ensemble du +serveur, du jeu de threads utilisé pour le check up des +équipiers. +ProxyHCTPsize <size> +server config + + + +

Si Apache httpd et APR ont été compilés avec le support des threads, le + module de check up peut confier ce travail à un jeu de threads associé au + processus Watchdog, ce qui permet l'exécution des check up en parallèle. La + directive ProxyHCTPsize permet de déterminer la + taille de ce jeu de threads. Une valeur de 0 signifie qu'aucun + jeu de threads ne sera utilisé, et le check up des différents équipiers sera + alors effectué séquentiellement. La taille par défaut du jeu de threads est + de 16.

+ + ProxyHCTPsize + +ProxyHCTPsize 32 + + + + + + + diff --git a/docs/manual/mod/mod_proxy_hcheck.xml.meta b/docs/manual/mod/mod_proxy_hcheck.xml.meta index a325b81c63f..1ac64daac4a 100644 --- a/docs/manual/mod/mod_proxy_hcheck.xml.meta +++ b/docs/manual/mod/mod_proxy_hcheck.xml.meta @@ -8,5 +8,6 @@ en + fr