From: Lucien Gentis Date: Sat, 24 Aug 2019 13:34:32 +0000 (+0000) Subject: fr doc XML updates. X-Git-Tag: 2.4.42~282 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=3df0e0efc352751a7c4996a5d536e0d27c6862ea;p=thirdparty%2Fapache%2Fhttpd.git fr doc XML updates. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1865849 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 8d92c36acba..4c46b845e14 100644 --- a/docs/manual/mod/mod_authn_socache.xml.fr +++ b/docs/manual/mod/mod_authn_socache.xml.fr @@ -1,7 +1,7 @@ - + @@ -47,8 +47,9 @@ 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 @@ -68,7 +69,7 @@ la charge des serveurs d'arrière-plan

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. + AuthnCacheProvideFor.
  2. Mettre socache avant le fournisseur pour lequel vous voulez effectuer une mise en cache dans votre directive AuthBasicProvider @@ -97,7 +98,7 @@ 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 + 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 @@ -157,10 +158,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 +178,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 +206,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,10 +217,10 @@ 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 + 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 diff --git a/docs/manual/mod/mod_deflate.xml.fr b/docs/manual/mod/mod_deflate.xml.fr index 116d31e7d3e..f61545ffdba 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.

    @@ -206,19 +206,18 @@ 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 CSS et JS compressés avec gzip, s'ils existent, et # si le client accepte gzip. RewriteCond "%{HTTP:Accept-encoding}" "gzip" - RewriteCond "%{REQUEST_FILENAME}\.gz" "-s" - RewriteRule "^(.*)\.(css|js)" "$1\.$2\.gz" [QSA] - + RewriteCond "%{REQUEST_FILENAME}\.gz" -s + RewriteRule "^(.*)\.(css|js)" "$1\.$2\.gz" [QSA] # Servir des types de contenus corrects, et empêcher mod_deflate # d'effectuer un double gzip.