<?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: 1734947:1737396 (outdated) -->
+<!-- English Revision: 1769718:1772560 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<code>none</code> active le filtre <code>TCP_DEFER_ACCEPT</code>
pour ce protocole. Pour plus de détails, voir la page de
manuel Linux de <a
- href="http://homepages.cwi.nl/~aeb/linux/man2html/man7/
- tcp.7.html">tcp(7)</a>.</p>
+ href="http://man7.org/linux/man-pages/man7/tcp.7.html">tcp(7)</a>.</p>
<p>Sous Windows, les valeurs par défaut sont :</p>
<highlight language="config">
-AcceptFilter http data
-AcceptFilter https data
+AcceptFilter http connect
+AcceptFilter https connect
</highlight>
<p>Le module MPM pour Windows mpm_winnt utilise la directive
AcceptFilter comme commutateur de l'API AcceptEx(), et ne supporte
- pas la mise en tampon du protocole http. Deux valeurs utilisent
- l'API Windows AcceptEx() et vont recycler les sockets réseau entre
- les connexions. <code>data</code> attend jusqu'à ce que les données
- aient été transmises comme décrit plus haut, et le tampon de données
- initiales ainsi que les adresses réseau finales sont tous extraits
- grâce à une seule invocation d'AcceptEx(). <code>connect</code>
+ pas la mise en tampon du protocole http. <code>connect</code>
utilise l'API AcceptEx(), extrait aussi les adresses réseau finales,
mais à l'instar de <code>none</code>, la valeur <code>connect</code>
n'attend pas la transmission des données initiales.</p>
pilotes vpn, ou les filtres anti-spam, anti-virus ou
anti-spyware.</p>
+ <note type="warning">
+ <title>L'AcceptFilter <code>data</code> (Windows)</title>
+
+ <p>Jusqu'à la version 2.4.23, le filtre d'acceptation <code>data</code>
+ attendait que des données aient été transmises et que le tampon de données
+ initial et l'adresse réseau finale aient été déterminés par l'invocation
+ AcceptEx(). Cette implémentation étant vulnérable à une attaque de type
+ denial of service, elle a été désactivée.</p>
+
+ <p>La version actuelle de httpd prend par défaut le filtre
+ <code>connect</code> sous Windows, et reprendra la valeur
+ <code>data</code> si <code>data</code> est spécifié. Il est fortement
+ conseillé aux utilisateurs des versions plus anciennes de définir
+ explicitement le filtre <code>connect</code> pour leurs AcceptFilter
+ comme indiqué plus haut.</p>
+ </note>
+
</usage>
<seealso><directive module="core">Protocol</directive></seealso>
</directivesynopsis>
<dt>Nonfatal=[Override|Unknown|All]</dt>
- <dd>
- Permet d'utiliser l'option AllowOverride pour rendre les erreurs
- de syntaxe non fatales dans les fichiers .htaccess : au lieu de
- causer une Internal Server Error, les directives non autorisées ou
- non reconnues seront ignorées et un avertissement enregistré dans
- le journal :
+ <dd>Permet d'utiliser l'option AllowOverride pour rendre non fatales les
+ directives invalides (non reconnues ou non permises) dans les fichiers
+ .htaccess : au lieu de causer une Internal Server Error, les directives
+ non autorisées ou non reconnues seront ignorées et un avertissement
+ enregistré dans le journal :
<ul>
<li><strong>Nonfatal=Override</strong> rend les directives
interdite par AllowOverride non fatales.</li>
précédentes non fatales.</li>
</ul>
<p>Notez qu'une erreur de syntaxe dans une directive valide
- causera toujours une internal server error.</p>
+ causera toujours une Internal Server Error.</p>
<note type="warning"><title>Sécurité</title>
Les erreurs non fatales peuvent être à l'origine de problèmes
de sécurité pour les utilisateurs de fichiers .htaccess. Par
<p>Dans l'exemple ci-dessus, toutes les directives qui ne font
partie ni du groupe <code>AuthConfig</code>, ni du groupe
- <code>Indexes</code>, provoquent une erreur "internal
- server error".</p>
+ <code>Indexes</code>, provoquent une erreur "Internal
+ Server Error".</p>
<note><p>Pour des raisons de sécurité et de performance, ne
définissez pas <code>AllowOverride</code> à autre chose que
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>FileInfo</override>
-<compatibility>Disponible à partir de la version 2.5 du serveur HTTP Apache</compatibility>
+<compatibility>Disponible à partir de la version 2.4.21 du serveur HTTP Apache</compatibility>
<usage>
<p>Cette directive permet de contrôler la manière dont certaines variables CGI
<description>Racine principale de l'arborescence des documents visible
depuis Internet</description>
<syntax>DocumentRoot <var>chemin répertoire</var></syntax>
-<default>DocumentRoot /usr/local/apache/htdocs</default>
+<default>DocumentRoot "/usr/local/apache/htdocs"</default>
<contextlist><context>server config</context><context>virtual
host</context>
</contextlist>
</usage>
</directivesynopsis>
+<directivesynopsis>
+<name>HttpProtocolOptions</name>
+<description>Modifie les contraintes sur les messages des requêtes HTTP</description>
+<syntax>HttpProtocolOptions [Strict|Unsafe] [RegisteredMethods|LenientMethods]
+ [Allow0.9|Require1.0]</syntax>
+<default>HttpProtocolOptions Strict LenientMethods Allow0.9</default>
+<contextlist><context>server config</context>
+<context>virtual host</context></contextlist>
+<compatibility>Disponible à partir des versions 2.2.32 et 2.4.24 du serveur HTTP
+Apache</compatibility>
+
+<usage>
+ <p>Cette directive permet de modifier les règles qui s'appliquent à la ligne
+ de requête HTTP (<a
+ href="https://tools.ietf.org/html/rfc7230#section-3.1.1">RFC 7230
+ §3.1.1</a>) et aux champs des en-têtes des requêtes HTTP (<a
+ href="https://tools.ietf.org/html/rfc7230#section-3.2">RFC 7230
+ §3.2</a>), qui s'appliquent maintenant par défaut ou en utilisant
+ l'option <code>Strict</code>. L'option <code>Unsafe</code>
+ a été ajoutée pour pouvoir restaurer les anciens
+ comportements nécessaires aux anciens modules et applications et aux agents
+ utilisateurs personnalisés considérés comme obsolètes. Ces règles
+ s'appliquant avant le traitement de la requête, elles doivent, pour être prises en
+ compte, être définies
+ au niveau global ou dans la première section par défaut du serveur virtuel
+ qui correspond à la requête considérée, par interface IP/port et non par
+ nom.</p>
+
+ <p>Avant l'introduction de cette directive, les interpréteurs de requêtes du
+ serveur HTTP Apache toléraient un grand nombre de formats en entrée qui
+ n'étaient pas forcément conformes au protocole. <a
+ href="https://tools.ietf.org/html/rfc7230#section-9.4">RFC 7230 §9.4
+ Request Splitting</a> et <a
+ href="https://tools.ietf.org/html/rfc7230#section-9.5">§9.5 Response
+ Smuggling</a> ne rappellent que deux des risques potentiels induits par des
+ requêtes non conformes, alors que <a
+ href="https://tools.ietf.org/html/rfc7230#section-3.5">RFC 7230
+ §3.5</a> signale les risques encourus par l'acceptation de blancs non
+ conformes dans les lignes de requête. Avec l'introduction de cette
+ directive, toutes les règles de grammaire de la spécification doivent être
+ respectées dans le mode d'opérations par défaut <code>Strict</code>.</p>
+
+ <p>Il est fortement déconseillé aux utilisateurs d'utiliser le mode
+ d'opération <code>Unsafe</code>, ou
+ <code>UnsafeWhitespace</code>, en particulier pour les déploiements de
+ serveurs ouverts sur l'extérieur et/ou accessibles au public. Si un moniteur
+ défectueux ou autre logiciel spécialisé ne s'exécutant que sur un intranet
+ nécessite une interface, les utilisateurs ne doivent utiliser les options de
+ type UnSafe qu'en cas de nécessité et uniquement au sein d'un serveur
+ virtuel bien spécifique et sur un réseau privé.</p>
+
+ <p>La consultation des messages enregistrés dans le journal
+ <directive>ErrorLog</directive>, configuré via la directive
+ <directive>LogLevel</directive> avec un niveau <code>info</code>, pourra
+ vous aider à identifier de telles requêtes non conformes ainsi que leur
+ provenance. Les utilisateurs devront accorder une attention particulière aux
+ messages d'erreur de type 400 dans le journal access pour détecter les
+ requêtes apparemment valides mais rejetées.</p>
+
+ <p>La section de la <a
+ href="https://tools.ietf.org/html/rfc7231#section-4.1">RFC 7231
+ §4.1</a> "Request Methods" "Overview" indique que les serveurs doivent
+ renvoyer un message d'erreur lorsque la ligne de requête comporte une
+ méthode non supportée. C'est déjà le cas lorsque l'option
+ <code>LenientMethods</code> est utilisée, mais les administrateurs ont la
+ possibilité de limiter les méthodes utilisées via l'option
+ <code>RegisteredMethods</code> en enregistrant toute méthode non standard
+ via la directive <directive>RegisterHttpMethod</directive>, en particulier
+ si l'option <code>Unsafe</code> est utilisée. L'option
+ <code>RegisteredMethods</code> <strong>ne doit pas</strong> être utilisée
+ pour les serveurs mandataires car ces derniers ne connaissent pas les
+ méthodes supportées par les serveurs originaux.</p>
+
+ <p>La section de la <a
+ href="https://tools.ietf.org/html/rfc2616#section-19.6">RFC 2616
+ §19.6</a> "Compatibility With Previous Versions" encouragait les
+ serveurs HTTP à supporter les anciennes requêtes HTTP/0.9. La RFC 7230 va
+ cependant à son encontre via sa préconisation "Le souhait de supporter les
+ requêtes HTTP/0.9 a été supprimé" et y adjoint des commentaires dans <a
+ href="https://tools.ietf.org/html/rfc7230#appendix-A">RFC 7230 Appendix
+ A</a>. A ce titre, l'option <code>Require1.0</code> permet à l'utilisateur
+ d'inhiber le comportement induit par l'option par défaut
+ <code>Allow0.9</code>.</p>
+</usage>
+</directivesynopsis>
+
<directivesynopsis>
<name>Error</name>
<description>Interrompt la lecture de la configuration avec un message
l'interprétation de toute expression. Exemples :</p>
<highlight language="config">
-ErrorDocument 500 http://foo.example.com/cgi-bin/tester
-ErrorDocument 404 /cgi-bin/bad_urls.pl
+ErrorDocument 500 http://example.com/cgi-bin/server-error.cgi
+ErrorDocument 404 /errors/bad_urls.php
ErrorDocument 401 /subscription_info.html
ErrorDocument 403 "Désolé, nous ne pouvons pas vous accorder l'accès aujourd'hui"
ErrorDocument 403 Forbidden!
-ErrorDocument 403 /cgi-bin/forbidden.pl?referrer=%{escape:%{HTTP_REFERER}}
+ErrorDocument 403 /errors/forbidden.py?referrer=%{escape:%{HTTP_REFERER}}
</highlight>
<p>De plus, on peut spécifier la valeur spéciale <code>default</code>
<FilesMatch ".+\.(gif|jpe?g|png)$">
# ...
</FilesMatch>
-</highlight>
+ </highlight>
<p>correspondrait à la plupart des formats graphiques de
l'Internet.</p>
</usage>
</directivesynopsis>
+<directivesynopsis type="section">
+<name>IfFile</name>
+<description>Regroupe des directives qui ne seront traitées que si un fichier
+existe au démarrage</description>
+<syntax><IfFile [!]<var>parameter-name</var>> ...
+ </IfFile></syntax>
+<contextlist><context>server config</context><context>virtual host</context>
+<context>directory</context><context>.htaccess</context>
+</contextlist>
+
+<usage>
+ <p>La section <code><IfFile <var>filename</var>>...</IfFile></code>
+ permet de conditionner le traitement de directives à
+ l'existence d'un fichier sur disque. Ainsi, les directives définies au sein
+ d'une section <directive type="section">IfFile</directive> ne seront
+ traitées que si le fichier <var>filename</var> existe. Si le fichier
+ <var>filename</var> n'existe pas, tout ce qui se trouve entre les marqueurs
+ start et end sera ignoré. <var>filename</var> peut être un chemin absolu ou
+ relatif au chemin défini par la directive ServerRoot.</p>
+
+ <p>Le paramètre <var>filename</var> de l'en-tête d'une section <directive
+ type="section">IfFile</directive> peut prendre la même forme que la variable
+ <var>test</var> de la section <directive
+ type="section">IfDefine</directive> ; à ce titre, le résultat du test peut être
+ inversé en plaçant le caractère <code>!</code> juste avant
+ <var>filename</var>.
+ </p>
+
+ <p>Si <var>filename</var> est un chemin relatif, il sera généré par rapport
+ au chemin défini par la directive <directive>ServerRoot</directive>. Lorsque
+ la directive <directive type="section">IfFile</directive> intervient avant
+ la définition de la directive <directive>ServerRoot</directive>,
+ <var>filename</var> sera relatif au répertoire racine par défaut du serveur
+ ou au répertoire racine passé dans la ligne de commande via l'option
+ <code>-d</code>.</p>
+
+</usage>
+</directivesynopsis>
+
<directivesynopsis type="section">
<name>IfModule</name>
<description>Contient des directives qui ne s'appliquent qu'en fonction
<directive>Options</directive> peuvent s'appliquer à un répertoire,
c'est la plus spécifique qui est utilisée et les autres sont
ignorées ; les options ne sont pas fusionnées (voir <a
- href="../sections.html#mergin">comment les sections sont
+ href="../sections.html#merging">comment les sections sont
fusionnées</a>). Elles le sont cependant si <em>toutes</em> les
options de la directive <directive>Options</directive> sont
précédées d'un symbole <code>+</code> ou <code>-</code>. Toute
(que ce soit pour ServerName ou ServerAlias).</p>
<p>Tous les noms spécifiés au sein d'une section
- <directive>VirtualHost</directive> sont traités comme un
- <directive>ServerAlias</directive> (sans caractères génériques).</p>
+ <directive type="section" module="core">VirtualHost</directive> sont traités comme un
+ <directive type="section" module="core">ServerAlias</directive>
+ (sans caractères génériques).</p>
</usage>
<seealso><directive module="core">UseCanonicalName</directive></seealso>
<p>La directive <directive>ServerName</directive> permet
(éventuellement en conjonction avec la directive
- <directive>ServerAlias</directive>) d'identifier de manière unique
+ <directive module="core">ServerAlias</directive>) d'identifier de manière unique
un serveur virtuel, lorsqu'elle est utilisée dans un contexte de <a
href="../vhosts/name-based.html">serveurs virtuels à base de
noms</a>.</p>
<p>Cette directive est aussi utilisée lors de la création d'URLs de
redirection relatives quand la directive
- <directive>UseCanonicalName</directive> est définie à une valeur autre que
+ <directive module="core">UseCanonicalName</directive> est définie à une valeur autre que
la valeur par défaut.</p>
<p>Par exemple, si le nom de la
peut autoriser l'ajout d'un corps de requête à l'aide de la
définition non standard <code>TraceEnable extended</code>. Le noyau
du serveur (dans le cas d'un serveur d'origine) va limiter la taille
- du corps de requête à 64k (plus 8k pour les en-têtes de
+ du corps de requête à 64Kb (plus 8Kb pour les en-têtes de
fractionnement si <code>Transfer-Encoding: chunked</code> est
utilisé). Le noyau du serveur va reproduire l'ensemble des en-têtes,
y compris les en-têtes de fractionnement avec le corps de la
réponse. Dans le cas d'un serveur mandataire, la taille du corps de
- requête n'est pas limitée à 64k.</p>
+ requête n'est pas limitée à 64Kb.</p>
<note><title>Note</title>
- <p>Bien que certains prétendent le contraire, <code>TRACE</code> ne
- constitue pas une vulnérabilité en matière de sécurité, et il n'y a
- aucune raison suffisante pour le désactiver, ce qui rendrait
- votre serveur non conforme.</p>
+ <p>Bien que certains prétendent le contraire, activer la méthode
+ <code>TRACE</code> ne constitue pas un problème de sécurité dans Apache
+ httpd. La méthode <code>TRACE</code> est définie par la spécification
+ HTTP/1.1 et les différentes implémentations sont censées la supporter.</p>
</note>
</usage>
</directivesynopsis>
projects / apache / blobdiff