<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1779744:1830439 (outdated) -->
+<!-- English Revision: 1830439 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
en-tête Accept-Push-Policy</a> est un autre dispositif expérimental
implémenté dans <code>mod_http2</code> ; il permet au client de définir pour
chaque requête quels genres de PUSHes il accepte.</p>
+
+
+ <p>
+ La fonctionnalité PUSH n'apportera pas toujours le gain de performances dans
+ l'obtention de réponses aux requêtes. Vous trouverez plusieurs études sur ce
+ sujet sur internet qui en expliquent les avantages et inconvénients et
+ comment les particularités des clients et du réseau en influencent le
+ fonctionnement. Par exemple, le seul fait que le serveur PUSHes une
+ ressource n'implique pas forcément que le navigateur l'utilisera.</p>
+ <p>Ce qui influence le plus la réponse PUSHed, c'est la requête qui a été
+ simulée. En effet, l'URL de la requête pour un PUSH est fournie par
+ l'application, mais d'où viennent les en-têtes ? Par exemple, La requête
+ PUSH requiert-elle un en-tête <code>accept-language</code> et si oui, quelle
+ sera sa valeur ?</p>
+ <p>httpd va consulter la requête originale (celle qui a déclenché le PUSH)
+ et copier les en-têtes suivants vers la requête PUSH :
+ <code>user-agent</code>, <code>accept</code>, <code>accept-encoding</code>,
+ <code>accept-language</code> et <code>cache-control</code>.</p>
+ <p>Tous les autres en-têtes sont ignorés. Les cookies eux non plus ne seront
+ pas copiés. PUSHer des ressources qui requièrent la présence d'un cookie ne
+ fonctionnera pas. Ceci peut être sujet à débat, mais tant que ce ne sera pas
+ clairement discuté avec les navigateurs, restons prudents et évitons
+ d'exposer les cookies là où ils ne sont pas censés être visibles.</p>
</section>
+ <section id="earlyhints">
+ <title>Suggestions précoces</title>
+ <p>A l'instar des ressources PUSHées, une autre méthode consiste à envoyer
+ des en-têtes <code>Link</code> au client avant même que la réponse ne soit
+ prête. Cette méthode utilise la fonctionnalité appelée "Suggestions
+ précoces" (Early Hints) décrite dans la <a
+ href="https://tools.ietf.org/html/rfc8297">RFC 8297</a>.</p>
+ <p>Pour utiliser cette fonctionnalité, vous devez l'activer explicitement
+ sur le serveur via :</p>
+ <highlight language="config">
+H2EarlyHints on
+ </highlight>
+ <p>Elle n'est en effet pas activée par défaut car certains navigateurs
+ anciens perdent pied avec de telles réponses.</p>
+ <p>Une fois cette fonctionnalité activée, vous pouvez utiliser la directive
+ <code>H2PushResource</code> pour déclencher les suggestions précoces et les
+ PUSHes de ressources :</p>
+ <highlight language="config">
+<Location /xxx.html>
+ H2PushResource /xxx.css
+ H2PushResource /xxx.js
+</Location>
+ </highlight>
+ <p>Le serveur enverra alors au client une réponse <code>"103 Early
+ Hints"</code> dès qu'il <em>commencera</em> à traiter la requête. Selon
+ votre application web, cet envoi peut intervenir beaucoup plus tôt que le
+ moment où les premiers en-têtes de réponse auront été déterminés.</p>
+ <p>Si <code>H2Push</code> est activé, ceci déclenchera aussi le PUSH juste
+ après la réponse 103. Mais si <code>H2Push</code> n'est pas activé, la
+ réponse 103 sera quand-même envoyée au client.</p>
+ </section>
+
</manualpage>
<?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: 1818968:1829713 (outdated) -->
+<!-- English Revision: 1829713 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<dl>
<dt>Déclaration des filtres</dt>
- <dd>La directive <directive
- module="mod_filter">FilterDeclare</directive> permet de déclarer un
- filtre en lui assignant un nom et un type. Elle n'est obligatoire
- que si le filtre n'est pas du type par défaut
- AP_FTYPE_RESOURCE.</dd>
+ <dd>La directive <directive module="mod_filter">FilterDeclare</directive>
+ permet de déclarer un nouveau filtre intelligent en lui assignant un nom et
+ éventuellement un type.</dd>
<dt>Enregistrement des fournisseurs</dt>
<dd>La directive <directive
fournisseur à un filtre. Le filtre a été éventuellement déclaré à
l'aide de la directive <directive module="mod_filter"
>FilterDeclare</directive> ; si ce n'est pas le cas, FilterProvider
- va le déclarer implicitement avec le type par défaut
- AP_FTYPE_RESOURCE. Le fournisseur doit avoir été enregistré à
+ va le déclarer implicitement. Le fournisseur doit avoir été enregistré à
l'aide de <code>ap_register_output_filter</code> par un module
quelconque. Le dernier argument de la directive <directive
module="mod_filter">FilterProvider</directive> est une expression :
<dl>
<dt>Inclusions côté serveur (SSI)</dt>
<dd>Un exemple simple de remplacement de la directive <directive
- module="core">AddOutputFilterByType</directive>
+ module="core">AddOutputFilterByType</directive>. On crée un nouveau filtre
+ intelligent nommé "SSI" qui tire partie de manière conditionnelle du filtre
+ "INCLUDES" de <module>mod_include</module> en tant que fournisseur.
<highlight language="config">
FilterDeclare SSI
FilterProvider SSI INCLUDES "%{CONTENT_TYPE} =~ m|^text/html|"
</dd>
<dt>Émulation de mod_gzip avec mod_deflate</dt>
- <dd>Insertion du filtre INFLATE seulement si l'en-tête
- Accept-Encoding a une valeur autre que "gzip". Ce filtre s'exécute
+ <dd>Cet exemple illustre les propriétés dynamiques qu'acquiert un filtre
+ traditionnel lorsqu'un filtre intelligent est construit autour. Un nouveau
+ filtre intelligent nommé "gzip" est créé qui n'insère de manière dynamique le
+ filtre INFLATE de <module>mod_deflate</module> que si "gzip" n'est PAS dans
+ l'en-tête Accept-Encoding. Le filtre intelligent gzip s'exécute
avec le type ftype CONTENT_SET.
<highlight language="config">
FilterDeclare gzip CONTENT_SET
-FilterProvider gzip inflate "%{req:Accept-Encoding} !~ /gzip/"
+FilterProvider gzip INFLATE "%{req:Accept-Encoding} !~ /gzip/"
FilterChain gzip
</highlight>
</dd>
<dt>Diminution de la résolution d'une image</dt>
- <dd>Supposons que nous voulions réduire la résolution de toutes les
- images web, et que nous disposions de filtres pour les images GIF,
- JPEG et PNG.
+ <dd>Cette exemple montre des abstractions qui vont au delà du filtrage
+ intelligent. Supposons que nous voulions réduire la résolution de toutes les
+ images web, et que nous disposions de différents fournisseurs de filtrage pour les images GIF,
+ JPEG et PNG. La configuration ci-dessous définit les filtres intelligents
+ "unpack" et "repack" en invoquant le fournisseur de filtrage approprié au
+ type de contenu à l'exécution.
<highlight language="config">
FilterProvider unpack jpeg_unpack "%{CONTENT_TYPE} = 'image/jpeg'"
FilterProvider unpack gif_unpack "%{CONTENT_TYPE} = 'image/gif'"
<directivesynopsis>
<name>FilterDeclare</name>
<description>Déclare un filtre intelligent</description>
-<syntax>FilterDeclare <var>nom_filtre</var> <var>[type]</var></syntax>
+<syntax>FilterDeclare <var>smart-filter-name</var> <var>[type]</var></syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context></contextlist>
<override>Options</override>
<usage>
<p>Cette directive permet de déclarer un filtre en sortie associé à
un en-tête ou une variable d'environnement qui déterminera les
- conditions de son exécution. Le premier argument est le <var>nom du
- filtre</var> destiné à être utilisé dans les directives <directive
+ conditions de son exécution. Le premier argument est le
+ <var>smart-filter-name</var> destiné à être utilisé dans les directives
+ <directive
module="mod_filter">FilterProvider</directive>, <directive
module="mod_filter">FilterChain</directive> et <directive
module="mod_filter">FilterProtocol</directive>.</p>
<directivesynopsis>
<name>FilterProvider</name>
<description>Enregistre un filtre de contenu</description>
-<syntax>FilterProvider <var>nom_filtre</var> <var>nom_fournisseur</var>
+<syntax>FilterProvider <var>smart-filter-name</var> <var>provider-name</var>
<var>expression</var></syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context></contextlist>
filtre est appelé pour la première fois.</p>
<p>
- <var>nom fournisseur</var> doit avoir été enregistré au cours du
+ <var>provider-name</var> doit avoir été enregistré au cours du
chargement d'un module à l'aide de
<code>ap_register_output_filter</code>.
</p>
<directivesynopsis>
<name>FilterChain</name>
<description>Configure la chaîne de filtrage</description>
-<syntax>FilterChain [+=-@!]<var>nom_filtre</var> <var>...</var></syntax>
+<syntax>FilterChain [+=-@!]<var>smart-filter-name</var> <var>...</var></syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context></contextlist>
<override>Options</override>
entreprendre :</p>
<dl>
- <dt><code>+<var>nom filtre</var></code></dt>
- <dd>Ajoute<var>nom filtre</var> à la fin de la chaîne de filtrage</dd>
+ <dt><code>+<var>smart-filter-name</var></code></dt>
+ <dd>Ajoute <var>smart-filter-name</var> à la fin de la chaîne de filtrage</dd>
- <dt><code>@<var>nom filtre</var></code></dt>
- <dd>Ajoute <var>nom filtre</var> au début de la chaîne de filtrage</dd>
+ <dt><code>@<var>smart-filter-name</var></code></dt>
+ <dd>Ajoute <var>smart-filter-name</var> au début de la chaîne de filtrage</dd>
- <dt><code>-<var>nom filtre</var></code></dt>
- <dd>Supprime <var>nom filtre</var> de la chaîne de filtrage</dd>
+ <dt><code>-<var>smart-filter-name</var></code></dt>
+ <dd>Supprime <var>smart-filter-name</var> de la chaîne de filtrage</dd>
- <dt><code>=<var>nom filtre</var></code></dt>
+ <dt><code>=<var>smart-filter-name</var></code></dt>
<dd>Supprime tous les filtres de la chaîne de filtrage existante et
- les remplace par <var>nom filtre</var></dd>
+ les remplace par <var>smart-filter-name</var></dd>
<dt><code>!</code></dt>
<dd>Supprime tous les filtres de la chaîne de filtrage existante</dd>
- <dt><code><var>nom filtre</var></code></dt>
- <dd>Équivalent à <code>+<var>nom filtre</var></code></dd>
+ <dt><code><var>smart-filter-name</var></code></dt>
+ <dd>Équivalent à <code>+<var>smart-filter-name</var></code></dd>
</dl>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>FilterProtocol</name>
<description>Vérifie le respect du protocole HTTP</description>
-<syntax>FilterProtocol <var>nom_filtre</var> [<var>nom_fournisseur</var>]
- <var>drapeaux_protocole</var></syntax>
+<syntax>FilterProtocol <var>smart-filter-name</var> [<var>provider-name</var>]
+ <var>proto-flags</var></syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context></contextlist>
<override>Options</override>
compte des effets du filtre.</p>
<p>Cette directive se présente sous deux formes. Avec trois
- arguments, elle s'applique de manière spécifique à un <var>nom
- filtre</var> et un <var>nom fournisseur</var> pour ce filtre. Avec
- deux arguments, elle s'applique à un <var>nom filtre</var> pour
+ arguments, elle s'applique de manière spécifique à un <var>smart-filter-name</var> et un <var>provider-name</var> pour ce filtre. Avec
+ deux arguments, elle s'applique à un <var>smart-filter-name</var> pour
<em>tout</em> fournisseur qu'il actionne.</p>
<p>Les drapeaux spécifiés sont fusionnés avec les drapeaux que les
en spécifiant <code>change=no</code>.
</p>
- <p><var>drapeaux_protocole</var> peut contenir un ou plusieurs
+ <p><var>proto-flags</var> peut contenir un ou plusieurs
drapeaux parmi les suivants :</p>
<dl>
<name>FilterTrace</name>
<description>Obtention d'informations de débogage/diagnostique en
provenance de <module>mod_filter</module></description>
-<syntax>FilterTrace <var>nom_filtre</var> <var>niveau</var></syntax>
+<syntax>FilterTrace <var>smart-filter-name</var> <var>level</var></syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context></contextlist>
<?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: 1783722:1830443 (outdated) -->
+<!-- English Revision: 1830443 -->
<!-- French translation : Lucien GENTIS -->
-<!-- $LastChangedRevision: 2017022501 $ -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
</dl>
</section>
+<section id="h2push"><title>HTTP/2 PUSH</title>
+ <p>Ce module ne supporte pas la fonctionnalité HTTP/2 PUSH. Les serveurs
+ d'arrière-plan qui veulent indiquer des ressources à précharger doivent
+ envoyer les en-têtes <code>Link</code> appropriés.</p>
+ <p>En cas de besoin, il peuvent le faire en utilisant les réponses
+ intermédiaires <code>"103 Early Hints"</code> comme indiqué dans la <a
+ href="https://tools.ietf.org/html/rfc8297">RFC 8297</a>, ce qui fournira
+ les meilleures performances. Si le client comprend aussi le langage HTTP/2,
+ il en résultera un PUSH de la part de httpd vers le celui-ci ou un simple
+ transfert de la réponse 103.</p>
+
+</section>
+
</modulesynopsis>
<?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: 1828238:1830819 (outdated) -->
+<!-- English Revision: 1830819 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<name>SSLCertificateFile</name>
<description>Fichier de données contenant les informations de certificat X.509 du serveur
codées au format PEM</description>
-<syntax>SSLCertificateFile <em>chemin-fichier</em></syntax>
+<syntax>SSLCertificateFile <var>file-path</var></syntax>
<contextlist><context>server config</context>
<context>virtual host</context></contextlist>
<name>SSLCertificateKeyFile</name>
<description>Fichier contenant la clé privée du serveur codée en
PEM</description>
-<syntax>SSLCertificateKeyFile <em>chemin-fichier</em></syntax>
+<syntax>SSLCertificateKeyFile <var>file-path</var>|<var>keyid</var></syntax>
<contextlist><context>server config</context>
<context>virtual host</context></contextlist>
+<compatibility><var>keyid</var> est disponible à partir de la version 2.5.1 du
+serveur HTTP Apache.</compatibility>
<usage>
<p>
-Cette directive permet de définir le fichier contenant la clé privée du
-serveur codée en PEM. Si la clé privée est
-chiffrée, une boîte de dialogue demandant le mot de passe de cette
-dernière s'ouvre au démarrage du serveur.</p>
+Cette directive permet de définir le fichier contenant la clé privée du serveur
+codée en PEM ou l'identifiant de la clé via un jeton cryptographique défini. Si
+la clé privée est chiffrée, une boîte de dialogue demandant le mot de passe de
+cette dernière s'ouvre au démarrage du serveur.</p>
<p>
Cette directive peut être utilisée plusieurs fois pour référencer
certificats qui comportent une telle clé doivent être définis après les
certificats en utilisant un fichier de clé séparé.</p>
+<p>Plutôt que de stocker des clés privées dans des fichiers, il est possible
+d'identifier une clé privée via un identifiant stocké dans un jeton.
+Actuellement, seuls les <a href="https://tools.ietf.org/html/rfc7512">PKCS#11
+URIs</a> sont reconnus comme identifiants de clés privées et peuvent être
+utilisés en conjonction avec le moteur OpenSSL <code>pkcs11</code> configuré via
+la directive <directive module="mod_ssl">SSLCryptoDevice</directive>.</p>
+
<example><title>Exemple</title>
<highlight language="config">
+# Pour utiliser une clé privée stockée dans fichier encodé PEM :
SSLCertificateKeyFile "/usr/local/apache2/conf/ssl.key/server.key"
+# Pour utiliser une clé privée à partir d'un jeton PKCS#11 :
+SSLCryptoDevice pkcs11
+...
+SSLCertificateKeyFile "pkcs11:token=My%20Token%20Name;id=45"
</highlight>
</example>
</usage>
<name>SSLCertificateChainFile</name>
<description>Fichier contenant les certificats de CA du serveur codés en
PEM</description>
-<syntax>SSLCertificateChainFile <em>chemin-fichier</em></syntax>
+<syntax>SSLCertificateChainFile <var>file-path</var></syntax>
<contextlist><context>server config</context>
<context>virtual host</context></contextlist>
<name>SSLCACertificateFile</name>
<description>Fichier contenant une concaténation des certificats de CA
codés en PEM pour l'authentification des clients</description>
-<syntax>SSLCACertificateFile <em>chemin-fichier</em></syntax>
+<syntax>SSLCACertificateFile <var>file-path</var></syntax>
<contextlist><context>server config</context>
<context>virtual host</context></contextlist>
<override>AuthConfig</override>
<name>SSLCADNRequestFile</name>
<description>Fichier contenant la concaténation des certificats de CA
codés en PEM pour la définition de noms de CA acceptables</description>
-<syntax>SSLCADNRequestFile <em>chemin-fichier</em></syntax>
+<syntax>SSLCADNRequestFile <var>file-path</var></syntax>
<contextlist><context>server config</context>
<context>virtual host</context></contextlist>
<name>SSLCARevocationFile</name>
<description>Fichier contenant la concaténation des CRLs des CA codés en
PEM pour l'authentification des clients</description>
-<syntax>SSLCARevocationFile <em>chemin-fichier</em></syntax>
+<syntax>SSLCARevocationFile <var>file-path</var></syntax>
<contextlist><context>server config</context>
<context>virtual host</context></contextlist>
<directivesynopsis>
<name>SSLSRPVerifierFile</name>
<description>Chemin du fichier de vérification SRP</description>
-<syntax>SSLSRPVerifierFile <em>file-path</em></syntax>
+<syntax>SSLSRPVerifierFile <var>file-path</var></syntax>
<contextlist><context>server config</context>
<context>virtual host</context></contextlist>
<compatibility>Disponible depuis la version 2.4.4 du serveur HTTP
<name>SSLProxyMachineCertificateFile</name>
<description>Fichier contenant la concaténation des clés et certificats
clients codés en PEM que le mandataire doit utiliser</description>
-<syntax>SSLProxyMachineCertificateFile <em>chemin-fichier</em></syntax>
+<syntax>SSLProxyMachineCertificateFile <em>file-path</em></syntax>
<contextlist><context>server config</context> <context>virtual host</context>
<context>proxy section</context></contextlist>
<name>SSLProxyCACertificateFile</name>
<description>Fichier contenant la concaténation des certificats de CA
codés en PEM pour l'authentification des serveurs distants</description>
-<syntax>SSLProxyCACertificateFile <em>file-path</em></syntax>
+<syntax>SSLProxyCACertificateFile <var>file-path</var></syntax>
<contextlist><context>server config</context> <context>virtual host</context>
<context>proxy section</context></contextlist>
<name>SSLProxyCARevocationFile</name>
<description>Fichier contenant la concaténation des CRLs de CA codés en
PEM pour l'authentification des serveurs distants</description>
-<syntax>SSLProxyCARevocationFile <em>chemin-fichier</em></syntax>
+<syntax>SSLProxyCARevocationFile <var>file-path</var></syntax>
<contextlist><context>server config</context> <context>virtual host</context>
<context>proxy section</context></contextlist>
<name>SSLSessionTicketKeyFile</name>
<description>Clé de chiffrement/déchiffrement permanente pour les
tickets de session TLS</description>
-<syntax>SSLSessionTicketKeyFile <em>chemin-fichier</em></syntax>
+<syntax>SSLSessionTicketKeyFile <var>file-path</var></syntax>
<contextlist><context>server config</context>
<context>virtual host</context></contextlist>
<compatibility>Disponible depuis la version 2.4.0 du serveur HTTP
projects / apache / commitdiff