<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1816356:1865403 (outdated) -->
+<!-- English Revision: 1865403 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
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.</p>
- <p>Pour résoudre ce problème, mod_authn_socache fournit une solution
- qui permet de maintenir un cache des données d'authentification.</p>
+ <p>Pour résoudre ce problème, <module>mod_authn_socache</module> fournit une
+ solution qui permet de maintenir un cache des données
+ d'authentification.</p>
</section>
<section id="usage"><title>Utilisation</title>
<p>Les principales règles à appliquer pour la mise en cache sont :</p>
<ol><li>Inclure le fournisseur pour lequel vous voulez effectuer une
mise en cache dans une directive
- <directive>AuthnCacheProvideFor</directive>.</li>
+ <directive module="mod_authn_socache">AuthnCacheProvideFor</directive>.</li>
<li>Mettre <var>socache</var> avant le fournisseur pour lequel
vous voulez effectuer une mise en cache dans votre directive
<directive module="mod_auth_basic">AuthBasicProvider</directive>
<section id="dev"><title>La mise en cache avec les modules tiers</title>
<p>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 <module>mod_authn_socache</module> doit être activée dans leurs modules. La
fonction de l'API <var>ap_authn_cache_store</var> 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
<override>AuthConfig</override>
<usage>
- <p>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
+ <p>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.</p>
+ directive <directive>AuthnCacheProvideFor</directive> ne seront pas mises en
+ cache.</p>
<p>Par exemple, pour mettre en cache les données d'authentification
trouvées par <module>mod_authn_dbd</module> ou par un fournisseur
<name>AuthnCacheTimeout</name>
<description>Définit une durée de vie pour les entrées du cache</description>
<syntax>AuthnCacheTimeout <var>durée-de-vie</var> (secondes)</syntax>
-<default>300 (5 minutes)</default>
+<default>AuthnCacheTimeout 300 (5 minutes)</default>
<contextlist><context>directory</context><context>.htaccess</context></contextlist>
<override>AuthConfig</override>
<name>AuthnCacheContext</name>
<description>Spécifie une chaîne de contexte à utiliser dans la clé du
cache</description>
-<syntax>AuthnCacheContext <var>directory|server|chaîne-personnalisée</var></syntax>
-<default>directory</default>
+<syntax>AuthnCacheContext directory|server|<var>custom-string</var></syntax>
+<default>AuthnCacheContext directory</default>
<contextlist><context>directory</context></contextlist>
<usage>
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.</p>
- <p>Il y a deux valeurs spéciales pour le paramètre : <var>directory</var>,
+ <p>Il y a deux valeurs spéciales pour le paramètre : <code>directory</code>,
qui utilise le contexte de répertoire de la requête comme chaîne, et
- <var>server</var>, qui utilise le nom du serveur virtuel.</p>
- <p>La valeur par défaut est <var>directory</var>, qui est aussi la
+ <code>server</code>, qui utilise le nom du serveur virtuel.</p>
+ <p>La valeur par défaut est <code>directory</code>, qui est aussi la
définition la plus courante. Ceci est cependant loin d'être optimal,
car par exemple, <var>$app-base</var>, <var>$app-base/images</var>,
<var>$app-base/scripts</var> et <var>$app-base/media</var>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1853640:1865364 (outdated) -->
+<!-- English Revision: 1865364 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<p>Le seul codage supporté est <code>gzip</code> afin d'assurer une complète
compatibilité avec les anciens navigateurs. Le codage <code>deflate</code>
n'est donc pas supporté ; voir à ce sujet la <a
- href="http://www.gzip.org/zlib/zlib_faq.html#faq38">documentation de zlib</a>
- pour une explication détaillée.
+ href="https://zlib.net/zlib_faq.html#faq39">documentation de zlib</a> pour une
+ explication détaillée.
</p>
</section>
<section id="precompressed"><title>Servir du contenu précompressé</title>
<p>Comme <module>mod_deflate</module> 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 :</p>
+ chaque requête, il est possible de gagner en performances en précompressant
+ ce contenu, et en forçant <module>mod_deflate</module> à servir ce contenu
+ précompressé sans avoir à le recompresser à chaque requête. Pour ce faire,
+ utilisez une configuration du style :</p>
<highlight language="config">
<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.