From: Lucien Gentis Date: Sat, 24 Aug 2019 13:32:33 +0000 (+0000) Subject: fr doc XML updates. X-Git-Tag: 2.5.0-alpha2-ci-test-only~1918 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=a33209f4e619b6ba93dcfaa17cd9deb1fa4666ed;p=thirdparty%2Fapache%2Fhttpd.git fr doc XML updates. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1865847 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/mod_authn_socache.xml.fr b/docs/manual/mod/mod_authn_socache.xml.fr index a730b176b33..4286c310446 100644 --- a/docs/manual/mod/mod_authn_socache.xml.fr +++ b/docs/manual/mod/mod_authn_socache.xml.fr @@ -1,7 +1,7 @@ - + @@ -47,28 +47,28 @@ la charge des serveurs d'arrière-plan etc...), et où une requête pour cette page génère des centaines de sous-requêtes à effet immédiat pour des contenus supplémentaires authentifiés.

-

Pour résoudre ce problème, mod_authn_socache fournit une solution - qui permet de maintenir un cache des données d'authentification.

+

Pour résoudre ce problème, mod_authn_socache fournit une + solution qui permet de maintenir un cache des données + d'authentification.

Utilisation -

Le cache d'authentification doit être utilisé lorsque les - requêtes d'authentification induisent une charge significative sur le - serveur, le serveur d'arrière-plan ou le réseau. Cette mise en cache - n'apportera probablement aucune amélioration dans le cas d'une - authentification à base de fichier (mod_authn_file) - ou de base de données dbm (mod_authn_dbm) car ces - méthodes sont de par leur conception rapides et légères (la mise en - cache peut cependant s'avérer utile dans le cas où le fichier est - situé sur un montage réseau). Les fournisseurs d'authentification - basés sur SQL ou LDAP ont plus de chances de tirer parti de cette - mise en cache, en particulier lorsqu'un problème de performances est - détecté. mod_authnz_ldap gérant son propre cache, - seul mod_authn_dbd est concerné par notre sujet.

+

Le cache d'authentification doit être utilisé lorsque les requêtes + d'authentification induisent une charge significative sur le serveur, le + serveur d'arrière-plan ou le réseau. Cette mise en cache n'apportera + probablement aucune amélioration dans le cas d'une authentification à base + de fichier (mod_authn_file) ou de base de données dbm + (mod_authn_dbm) car ces méthodes sont de par leur + conception rapides et légères (la mise en cache peut cependant s'avérer + utile dans le cas où le fichier est situé sur un montage réseau). Les + fournisseurs d'authentification basés sur SQL ou LDAP ont plus de chances de + tirer parti de cette mise en cache, en particulier lorsqu'un problème de + performances est détecté. mod_authnz_ldap gérant son propre + cache, seul mod_authn_dbd est concerné par notre sujet.

Les principales règles à appliquer pour la mise en cache sont :

-
  1. Inclure le fournisseur pour lequel vous voulez effectuer une - mise en cache dans une directive - AuthnCacheProvideFor.
  2. +
    1. Inclure le fournisseur pour lequel vous voulez effectuer une mise en + cache dans une directive AuthnCacheProvideFor .
    2. Mettre socache avant le fournisseur pour lequel vous voulez effectuer une mise en cache dans votre directive AuthBasicProvider @@ -96,12 +96,11 @@ AuthnCacheSOCache dbm
La mise en cache avec les modules tiers -

Les développeurs de modules doivent savoir que la mise en cache - avec mod_authn_socache doit être activée dans leurs modules. La - fonction de l'API ap_authn_cache_store permet de - mettre en cache les données d'authentification qu'un fournisseur - vient de rechercher ou de générer. Vous trouverez des exemples - d'utilisation à Les développeurs de modules doivent savoir que la mise en cache avec + mod_authn_socache doit être activée dans leurs modules. La + fonction de l'API ap_authn_cache_store permet de mettre en cache + les données d'authentification qu'un fournisseur vient de rechercher ou de + générer. Vous trouverez des exemples d'utilisation à r957072, où trois fournisseurs authn sont activés pour la mise en cache.

@@ -157,10 +156,11 @@ mise en cache AuthConfig -

Cette directive permet de spécifier un ou plusieurs fournisseurs - pour le(s)quel(s) on veut effectuer une mise en cache. Les données +

Cette directive permet de spécifier un ou plusieurs fournisseurs pour + le(s)quel(s) on veut effectuer une mise en cache. Les données d'authentification trouvées par un fournisseur non spécifié dans une - directive AuthnCacheProvideFor ne seront pas mises en cache.

+ directive AuthnCacheProvideFor ne seront pas mises en + cache.

Par exemple, pour mettre en cache les données d'authentification trouvées par mod_authn_dbd ou par un fournisseur @@ -176,7 +176,7 @@ AuthnCacheProvideFor dbd mon-fournisseur AuthnCacheTimeout Définit une durée de vie pour les entrées du cache AuthnCacheTimeout durée-de-vie (secondes) -300 (5 minutes) +AuthnCacheTimeout 300 (5 minutes) directory.htaccess AuthConfig @@ -204,8 +204,8 @@ AuthnCacheProvideFor dbd mon-fournisseur AuthnCacheContext Spécifie une chaîne de contexte à utiliser dans la clé du cache -AuthnCacheContext directory|server|chaîne-personnalisée -directory +AuthnCacheContext directory|server|custom-string +AuthnCacheContext directory directory @@ -215,12 +215,12 @@ cache construction d'une clé de cache. Ceci permet de lever l'ambiguïté entre plusieurs noms d'utilisateurs identiques servant différentes zones d'authentification sur le serveur.

-

Il y a deux valeurs spéciales pour le paramètre : directory, +

Il y a deux valeurs spéciales pour le paramètre : directory, qui utilise le contexte de répertoire de la requête comme chaîne, et - server, qui utilise le nom du serveur virtuel.

-

La valeur par défaut est directory, qui est aussi la - définition la plus courante. Ceci est cependant loin d'être optimal, - car par exemple, $app-base, $app-base/images, + server, qui utilise le nom du serveur virtuel.

La valeur + par défaut est directory, qui est aussi la définition la plus + courante. Ceci est cependant loin d'être optimal, car par exemple, + $app-base, $app-base/images, $app-base/scripts et $app-base/media possèderont chacun leur propre clé de cache. Il est préférable d'utiliser le fournisseur de mot de passe : par exemple un fichier diff --git a/docs/manual/mod/mod_deflate.xml.fr b/docs/manual/mod/mod_deflate.xml.fr index c27776a8e18..2e99abad788 100644 --- a/docs/manual/mod/mod_deflate.xml.fr +++ b/docs/manual/mod/mod_deflate.xml.fr @@ -1,7 +1,7 @@ - + @@ -42,8 +42,8 @@ client

Le seul codage supporté est gzip afin d'assurer une complète compatibilité avec les anciens navigateurs. Le codage deflate n'est donc pas supporté ; voir à ce sujet la documentation de zlib - pour une explication détaillée. + href="https://zlib.net/zlib_faq.html#faq39">documentation de zlib pour une + explication détaillée.

@@ -205,17 +205,17 @@ SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip
Servir du contenu précompressé

Comme mod_deflate recompresse le contenu demandé à - chaque requête, il est possible de gagner en performances en - précompressant ce contenu, et en forçant mod_deflate à servir ce - contenu précompressé sans avoir à le recompresser à chaque requête. - Pour ce faire, utilisez une configuration du style :

+ chaque requête, il est possible de gagner en performances en précompressant + ce contenu, et en forçant mod_deflate à servir ce contenu + précompressé sans avoir à le recompresser à chaque requête. Pour ce faire, + utilisez une configuration du style :

<IfModule mod_headers.c> # Servir des fichiers JS et CSS compressés avec gzip, s'ils existent, et # si le client accepte gzip. RewriteCond "%{HTTP:Accept-encoding}" "gzip" - RewriteCond "%{REQUEST_FILENAME}\.gz" "-s" + RewriteCond "%{REQUEST_FILENAME}\.gz" -s RewriteRule "^(.*)\.(css|js)" "$1\.$2\.gz" [QSA] # Servir des types de contenus corrects, et empêcher mod_deflate