<?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: 1932811:1934488 (outdated) -->
+<!-- English Revision: 1934488 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
fichier réel (ou un fichier qui n'existe pas dans un répertoire qui
existe) doivent être acceptées ou rejetées. Les scripts peuvent
accéder à cette information via la variable d'environnement
- <code>PATH_INFO</code>.</p>
+ <glossary ref="pathinfo">PATH_INFO</glossary>.</p>
<p>Supposons par exemple que <code>/test/</code> pointe vers un
répertoire qui ne contient que le fichier <code>here.html</code>.
</contextlist>
<usage>
- <p>Au cours du traitement d'une requête, le serveur recherche le
- premier fichier de configuration existant à partir de la liste
- de noms dans chaque répertoire composant le chemin du document, à
- partir du moment où les fichiers de configuration distribués sont <a
- href="#allowoverride">activés pour ce répertoire</a>. Par exemple
- :</p>
-
- <highlight language="config">AccessFileName .acl</highlight>
-
- <p>avant de renvoyer le document
- <code>/usr/local/web/index.html</code>, le serveur va rechercher les
- fichiers <code>/.acl</code>, <code>/usr/.acl</code>,
- <code>/usr/local/.acl</code> et <code>/usr/local/web/.acl</code>
- pour y lire d'éventuelles directives, à moins quelles n'aient été
- désactivées avec</p>
+ <p>La directive AccessFileName permet de modifier le nom du fichier qui sera
+ pris en compte pour les outrepassements de configuration au niveau du
+ répertoire, si la directive <directive
+ module="core">AllowOverride</directive> est activée pour le répertoire
+ considéré.</p>
+
+ <note type="warning">Nous vous déconseillons de modifier cette valeur et en
+ particulier de fournir une liste de plusieurs fichiers possibles, car cela
+ rendrait plus difficile la recherche d’erreurs pour quelqu’un qui n’est pas
+ familier avec votre configuration locale.</note>
+
+ <p>Lors du traitement d’une requête, le serveur cherche les fichiers dont le
+ nom (ou les noms) sont définis à l’aide de la directive <code>AccessFileName</code> dans
+ tous les répertoires du chemin du document, si les fichiers de configuration
+ distribués sont <a href="#allowoverride">autorisés pour ce répertoire</a>.
+ Par exemple, avant de renvoyer le document
+ <code>/usr/local/web/index.html</code>, le serveur va rechercher des
+ directives dans les fichiers <code>/.htaccess</code>, <code>/usr/.htaccess</code>,
+ <code>/usr/local/.htaccess</code> et <code>/usr/local/web/.htaccess</code>.</p>
+
+ <p>C’est pour cette raison que le fichier de configuration par défaut
+ contient les instructions suivantes :</p>
<highlight language="config">
<Directory "/">
AllowOverride None
</Directory>
</highlight>
+
+ <p>Ce bloc de configuration permet de prévenir tout accès non nécessaire à
+ des fichiers dans des répertoires en dehors de votre racine des documents
+ <directive module="core">DocumentRoot</directive>. Voir aussi la note à ce
+ sujet dans la documentation de la directive <code>AllowOverride</code>.</p>
</usage>
<seealso><directive module="core">AllowOverride</directive></seealso>
<seealso><a href="../configuring.html">Fichiers de configuration</a></seealso>
<code>.htaccess</code></description>
<syntax>AllowOverride All|None|<var>directive-type</var>
[<var>directive-type</var>] ...</syntax>
-<default>AllowOverride None à partir de la version 2.3.9, AllowOverride
-All pour les versions antérieures</default>
+<default>AllowOverride None</default>
<contextlist><context>directory</context></contextlist>
<usage>
- <p>Lorsque le serveur trouve un fichier <code>.htaccess</code> (dont
- le nom est défini par la directive <directive
- module="core">AccessFileName</directive>), il doit savoir lesquelles
- des directives placées dans ce fichier sont autorisées à modifier la
- configuration préexistante.</p>
+ <p>Lorsque le serveur trouve un fichier de configuration distribuée (nommé
+ en général <code>.htaccess</code> — configurable à l’aide de la directive
+ <directive module="core">AccessFileName</directive>), il doit savoir
+ lesquelles des directives placées dans ce fichier sont autorisées à modifier
+ la configuration préexistante.</p>
<note><title>Valable seulement dans les sections
<Directory></title>
<dt><a href="overrides.html#override-limit">Limit</a></dt>
- <dd>
- Permet l'utilisation des directives contrôlant l'accès au serveur
- (<directive
- module="mod_access_compat">Allow</directive>, <directive
- module="mod_access_compat">Deny</directive> et <directive
- module="mod_access_compat">Order</directive>).</dd>
-
-<!-- TODO - Update this for 2.4 syntax -->
+ <dd> Permet l'utilisation des directives patrimoniales de contrôle d'accès
+ au serveur (<directive module="mod_access_compat">Allow</directive>,
+ <directive module="mod_access_compat">Deny</directive> et <directive
+ module="mod_access_compat">Order</directive>). Pour un équivalent moderne,
+ voir la directive <directive module="mod_authz_core">Require</directive>
+ contrôlée par <code>AuthConfig</code>. Sont aussi incluses les directives
+ <directive module="mod_include">SSIETag</directive>, <directive
+ module="mod_include">SSILastModified</directive> et <directive
+ module="mod_include">SSILegacyExprParser</directive>. </dd>
<dd>
Permet l'utilisation des directives contrôlant les fonctionnalités
- spécifiques d'un répertoire (<directive
- module="core">Options</directive> et <directive
- module="mod_include">XBitHack</directive>).
- Pour restreindre les options pouvant être outrepassées, ajoutez un
- signe "égal" suivi d'une liste d'options, séparées par des virgules
- (sans espaces), pouvant être définies à l'aide de la directive
- <directive module="core">Options</directive>.
+ spécifiques d'un répertoire (<directive module="core">Options</directive>
+ et <directive module="mod_include">XBitHack</directive>). Pour
+ restreindre les options pouvant être outrepassées, ajoutez un signe "égal"
+ suivi d'une liste d'options, séparées par des virgules (sans espaces),
+ pouvant être définies à l'aide de la directive <directive
+ module="core">Options</directive>.
<note><title>Désactivation implicite des options</title>
<p>Bien que la liste des options disponibles dans les fichiers
<highlight language="config">AllowOverride AuthConfig Indexes</highlight>
-
<p>Dans l'exemple ci-dessus, toutes les directives qui ne font
+ <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>
<name>AllowOverrideList</name>
<description>Directives autorisées dans les fichiers <code>.htaccess</code></description>
<syntax>AllowOverrideList None|<var>directive</var>
-[<var>directive-type</var>] ...</syntax>
+[<var>directive</var>] ...</syntax>
<default>AllowOverrideList None</default>
<contextlist><context>directory</context></contextlist>
module="core">AllowOverride</directive> autorise les directives du
groupement <code>AuthConfig</code>, et
<directive>AllowOverrideList</directive> n'autorise que deux
- directives du groupement <code>FileInfo</code>. Toutes les autres
- provoqueront une erreur interne du serveur.</p>
+ directives du groupement <code>FileInfo</code>. Le jeu de directives
+ permises effectif est l’union des deux. Toutes les autres causeront une
+ erreur interne du serveur.</p>
+
+ <p>En outre, certaines directives sont toujours permises dans les fichiers
+ <code>.htaccess</code>, pourvu que le mécanisme d’outrepassement soit activé
+ (c’est-à-dire que la directive <directive
+ module="core">AllowOverride</directive> ne soit pas définie à
+ <code>None</code>). Ces directives sont listées dans la section <a
+ href="overrides.html#override-all">All</a> de l’<a
+ href="overrides.html">index de la classe override</a>.</p>
</usage>
<seealso><directive module="core">AccessFileName</directive></seealso>
<usage>
<p>Cette directive permet de contrôler la manière dont certaines variables CGI
- sont définies.</p>
+ sont définies lorsque des requêtes sont transmises à des scripts CGI ou
+ d’autres gestionnaires qui reçoivent un environnement CGI. Actuellement, la
+ seule variable prise en charge est <code>REQUEST_URI</code>.</p>
+
+ <p>Par défaut, la variable d’environnement CGI <code>REQUEST_URI</code>
+ contient l’URI original de la requête du client. Cela implique que même si
+ <module>mod_rewrite</module> ou une redirection interne modifie la ressource
+ qui va être servie, le script CGI verra quand-même l’URI original que le
+ client a envoyé.</p>
+
+ <p>Avec <code>CGIVar REQUEST_URI current-uri</code>, la valeur est définie à
+ l’URI actuel après l’application de toute réécriture ou redirection interne.</p>
- <p>règles <strong>REQUEST_URI</strong> :</p>
+ <p><strong>Valeurs autorisées :</strong></p>
<dl>
<dt><code>original-uri</code> (valeur par défaut)</dt>
- <dd>La valeur est extraite de la requête originale, et ne tient pas compte
- des redirections internes ou des sous-requêtes qui pourraient modifier la
- ressource demandée.</dd>
+ <dd>Définit <code>REQUEST_URI</code> avec l’URI de la requête originale du
+ client, sans tenir compte d’une réécriture ou redirection interne
+ quelconque.</dd>
<dt><code>current-uri</code></dt>
- <dd>La valeur reflète la ressource en cours de traitement ; elle peut être
- différente de la ressource demandée dans la requête initiale du client suite à
- d'éventuelles redirections internes ou sous-requêtes.</dd>
+ <dd>Définit <code>REQUEST_URI</code> avec l’URI de la ressource en train
+ d’être traitée, qui peut être différente de la requête originale en cas de
+ réécriture ou de redirection interne.</dd>
</dl>
+
+ <highlight language="config">
+# Montrer aux scripts CGI l’URI réécrit à la place de l’original
+CGIVar REQUEST_URI current-uri
+ </highlight>
+
+ <note><title>Note</title>
+ <p>Dans tous les cas, la variable d’environnement CGI <code>REQUEST_URI</code>
+ contient l’URI complet, y compris la chaîne de paramètres. Cela est différent
+ pour la variable de serveur <code>%{REQUEST_URI}</code> utilisée dans
+ <module>mod_rewrite</module> et les expressions de <a
+ href="../expr.html">ap_expr</a>, qui ne contient que la partie chemin (pas la
+ chaîne de paramètres).</p></note>
</usage>
</directivesynopsis>
et la section <directive type="section">Directory</directive>
correspondante s'appliquera.</p>
- <p><strong>Notez que la politique d'accès par défaut
+ <note type="warning">
+ <p>La politique d'accès par défaut
dans les sections <code><Directory "/"></code> consiste à
autoriser tout accès sans restriction. Ceci signifie qu'Apache httpd va servir tout fichier
correspondant à une URL. Il est recommandé de modifier cette
- situation à l'aide d'un bloc du style</strong></p>
+ situation à l'aide d'un bloc du style</p>
<highlight language="config">
<Directory "/">
</Directory>
</highlight>
- <p><strong>puis d'affiner la configuration pour les répertoires que vous
+ <p>Puis d’affiner la configuration pour les répertoires que vous
voulez rendre accessibles. Voir la page <a
href="../misc/security_tips.html">Conseils à propos de sécurité</a>
- pour plus de détails.</strong></p>
+ pour plus de détails.</p>
+ </note>
<p>Les sections <directive type="section">Directory</directive> se situent
dans le fichier <code>httpd.conf</code>. Les directives <directive
</contextlist>
<usage>
- <p>Les balises <directive type="section">DirectoryMatch</directive>
- et <code></DirectoryMatch></code> permettent de regrouper un
- ensemble de directives qui ne s'appliqueront qu'au répertoire
- précisé (et aux fichiers qu'il contient), comme pour la section <directive
- module="core" type="section">Directory</directive>. Cependant, le
- répertoire est précisé sous la forme d'une <glossary
- ref="regex">expression rationnelle</glossary>. Par exemple :</p>
+ <p>Les balises <directive type="section">DirectoryMatch</directive> et
+ <code></DirectoryMatch></code> permettent de regrouper un ensemble de
+ directives qui ne s'appliqueront qu’aux répertoires (et aux fichiers qu’ils
+ contiennent) dont le chemin du système de fichiers correspond à l’<glossary
+ ref="regex">expression rationnelle</glossary> spécifiée. À la différence de
+ <directive module="core" type="section">Directory</directive>, les
+ directives ne s’appliqueront aux sous-répertoires que si le motif leur
+ correspond aussi. Cette balise prend comme argument une expression
+ rationnelle qui est comparée en tant que sous-chaîne (elle n’est pas ancrée au
+ début ou à la fin, à moins que vous n’indiquiez explicitement <code>^</code>
+ ou <code>$</code> dans le motif. Par exemple :</p>
<highlight language="config">
<DirectoryMatch "^/www/(.+/)?[0-9]{3}/">
directives contenues dans la section.
</note>
- <note><title>slash de fin</title>
- Cette directive s'applique aux requêtes pour des répertoires avec
- ou sans slash de fin ; les expressions contenant un symbole de fin
- de ligne ($) doivent donc faire l'objet d'une attention
- particulière.
+ <note><title>slash de fin</title>
+ Cette directive s'applique aux requêtes pour des répertoires avec ou sans
+ slash de fin. Si vous ancrez votre motif avec <code>$</code>, vous devrez
+ peut-être comparer les deux formes ; par exemple, <code><DirectoryMatch
+ "^/var/www/?$"></code>.
</note>
<p>A partir de la version 2.4.8, les groupes nommés et les
<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
+ de requête HTTP (<rfc section="3.1.1">7230</rfc>) et aux champs des en-têtes
+ des requêtes HTTP (<rfc section="3.2">7230</rfc>), 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.</p>
<dd>
<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>
+ n'étaient pas forcément conformes au protocole. La <rfc
+ section="9.4">7230</rfc> (Request Splitting) et la <rfc
+ section="9.5">7230</rfc> (Response Smuggling) ne rappellent que deux des
+ risques potentiels induits par des requêtes non conformes, alors que la <rfc
+ section="3.5">7230</rfc> (Message Parsing Robustness) 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>
<note type="warning"><title>Risques de sécurité liés au mode Unsafe</title>
<p>Il est fortement déconseillé aux utilisateurs d'utiliser le mode
</dd>
<dt>RegisteredMethods|LenientMethods</dt>
<dd>
- <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.</p>
+ <p>La section "Overview" de la <rfc section="4.1">7231</rfc> "Request
+ Methods" 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.</p>
<note type="warning"><title>Compatibilité avec le mandat direct</title>
<p>L'option
</dd>
<dt>Allow0.9|Require1.0</dt>
<dd>
- <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>
+ <p>La <rfc section="19.6">2616</rfc> "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 <rfc anchor="appendix-A">7230</rfc> Appendix 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>
<example>
<title>Exemple de requête provoquant l'envoi d'un message HTTP 400 en
ErrorDocument 403 /errors/forbidden.py?referrer=%{escape:%{HTTP_REFERER}}
</highlight>
+ <p>Quand l’argument est une chaîne de texte (c’est-à-dire ni un chemin, ni
+ un URL), il est envoyé au client avec <code>text/html</code> comme type de
+ contenu, si bien que vous pouvez inclure des balises HTML. Vous pouvez
+ utiliser une controblique comme caractère de continuation de ligne afin de
+ répartir le document sur plusieurs lignes :</p>
+
+ <highlight language="config">
+ErrorDocument 403 "\
+<html><head>\
+<title>403 Forbidden</title>\
+</head><body>\
+<h1>Forbidden</h1>\
+<p> Vous n’êtes pas autorisé à accéder à cette ressource.</p>\
+</body></html>"
+ </highlight>
+
<p>De plus, on peut spécifier la valeur spéciale <code>default</code>
pour indiquer l'utilisation d'un simple message d'Apache httpd codé en
dur. Bien que non nécessaire dans des circonstances normales, la
connexion ou d'une requête ne génère aucun message dans le journal,
alors aucune information additionnelle n'est enregistrée.</p>
- <p>Il peut arriver que certains items de la chaîne de format ne
+ <p>Il peut arriver que certains spécificateurs de format ne
produisent aucune sortie. Par exemple, l'en-tête Referer n'est
présent que si le message du journal est associé à une requête et s'il
est généré à un moment où l'en-tête Referer a déjà été lu par le
client. Si aucune sortie n'est générée, le comportement par défaut
consiste à supprimer tout ce qui se trouve entre l'espace précédent
- et le suivant. Ceci implique que la ligne de journalisation est
+ et le suivant. Ceci implique que la chaîne de format est
divisée en champs ne contenant pas d'espace séparés par des espaces.
- Si un item de la chaîne de format ne génère aucune sortie,
+ Si un spécificateur de format ne génère aucune sortie,
l'ensemble du champ est omis. Par exemple, si l'adresse distante
<code>%a</code> du format <code>[%t] [%l] [%a] %M </code> n'est
pas disponible, les crochets qui l'entourent ne seront eux-mêmes pas
<p>Un modificateur de type entier permet d'assigner un niveau de
sévérité à un item de format. L'item considéré ne
- sera journalisé que si la sévérité du message n'est pas
- plus haute que le niveau de sévérité spécifié. Les
+ sera journalisé que si le message journalisé possède un niveau de sévérité
+ du nombre spécifié ou supérieur (c’est-à-dire que le nombre correspondant au
+ niveau de sévérité du message est inférieur ou égal au modificateur). Les
valeurs possibles vont de 1 (alert) à 15 (trace8), en passant par 4
(warn) ou 7 (debug).</p>
<tr>
<td><code>%4{Referer}i</code></td>
<td>N'enregistre le contenu de l'en-tête <code>Referer</code> que si
- la sévérité du message de journalisation est supérieure à 4.</td>
+ la sévérité du message de journalisation est 4 (avertissement) ou supérieure
+ (niveaux 1 à 4 : alerte, critique, erreur, avertissement).</td>
</tr>
</table>
- <p>Certains items de format acceptent des paramètres supplémentaires
+ <p>Certains spécificateurs de format acceptent des paramètres supplémentaires
entre accolades.</p>
<table border="1" style="zebra">
une section <directive type="section">Limit</directive> pour la
restriction d'accès, car une section <directive type="section"
module="core">LimitExcept</directive> fournit une protection contre
- les méthodes arbitraires.</note>
+ les méthodes arbitraires. Voir aussi la <a
+ href="../sections.html#merging">documentation sur la fusion des sections de
+ configuration</a> pour un avertissement à propos de la manière dont une
+ directive <directive type="section">Limit</directive> au sein d’une section
+ <directive type="section" module="core">Location</directive> peut
+ outrepasser silencieusement les directives d’une section <directive
+ type="section" module="core">Directory</directive>.</note>
<p>Les directives <directive type="section">Limit</directive> et
<directive type="section" module="core">LimitExcept</directive>
URL est un chemin d'URL de la forme
<code>/chemin/</code>. <em>Aucun protocole, nom d'hôte, port, ou chaîne
de requête ne doivent apparaître.</em> Pour les requêtes mandatées, l'URL
- spécifiée doit être de la forme
+ à comparer dépend du type de mandataire. Avec un mandataire <strong>direct
+ (forward)</strong> (configuré via <directive
+ module="mod_proxy">ProxyRequests</directive>), l'URL
+ à comparer doit être de la forme
<code>protocole://nom_serveur/chemin</code>, et vous devez inclure
- le préfixe.</p>
+ le préfixe. Avec un mandataire <strong>inverse (reverse)</strong> (configuré
+ via <directive module="mod_proxy">ProxyPass</directive> ou <directive
+ module="mod_proxy">RewriteRule ... [P]</directive>), la requête arrive en
+ tant que chemin d’URL local ; il faut donc utiliser <code>/chemin/</code>,
+ comme vous le feriez pour la requête originale.</p>
<p>L'URL peut contenir des caractères génériques. Dans une chaîne
avec caractères génériques, <code>?</code> correspond à un caractère
Le serveur va suivre les liens symboliques dans le répertoire
concerné. Il s'agit de la valeur par défaut.
<note>
- <p>Bien que le serveur suive les liens symboliques, il ne modifie
+ <p>Quand le serveur suit les liens symboliques, il ne modifie
<em>pas</em> le nom de chemin concerné défini par la section
<directive type="section"
module="core">Directory</directive>.</p>
+
+ <p>Désactiver cette option empêche aussi <module>mod_rewrite</module>
+ d’agir dans un contexte de répertoire (fichiers <code>.htaccess</code> et
+ sections <directive type="section" module="core">Directory</directive>.</p>
<p>Les options <code>FollowSymLinks</code> et
<code>SymLinksIfOwnerMatch</code> ne fonctionnent que dans les
<p>Spécifier des protocoles non disponibles ou désactivés n'aura
aucun effet, et ceux-ci seront simplement ignorés.</p>
+
+ <note><title>Note</title> <p>Le protocole <code>http/1.1</code> est
+ toujours disponible, même s’il est exclu de cette directive. Cette
+ dernière permet de spécifier les protocoles supplémentaires disponibles
+ pour la négociation, ainsi que leur ordre de préférence lorsqu’elle est
+ utilisée avec la directive
+ <directive>ProtocolsHonorOrder</directive>.</p></note>
<p>Si un serveur virtuel ne possède pas de directive Protocols
propre, il hérite des protocoles spécifiés pour le serveur
<p>Cette directive est aussi utilisée lors de la création d'URLs de
redirection relatives quand la directive
- <directive module="core">UseCanonicalName</directive> est définie à une valeur autre que
- la valeur par défaut.</p>
+ <directive module="core">UseCanonicalName</directive> est définie à
+ <code>On</code>. Si <code>UseCanonicalName</code> est définie à
+ <code>DNS</code>, une recherche DNS inverse est effectuée</p>
<p>Par exemple, si le nom de la
machine hébergeant le serveur web est
doit apparaître dans l'en-tête de requête <code>Host:</code> pour
pouvoir atteindre ce serveur virtuel.</p>
-
<p>Parfois, le serveur s'exécute en amont d'un dispositif qui
implémente SSL, comme un mandataire inverse, un répartiteur de
charge ou un boîtier dédié SSL. Dans ce cas, spécifiez le protocole
</example>
</note>
+ <note type="warning">
+ <p>Les adresses IPv6 ne sont actuellement pas prises
+ en charge par la directive <directive>ServerName</directive> et produisent
+ une erreur au démarrage du serveur, même si elles sont entourées de
+ crochets. Il s’agit d’un <a
+ href="https://bz.apache.org/bugzilla/show_bug.cgi?id=52178"
+ >problème connu</a>.</p></note>
+
</usage>
<seealso><a href="../dns-caveats.html">Problèmes concernant le DNS et
<usage>
<p>La directive <directive>ServerPath</directive> permet de définir
- le nom de chemin d'URL hérité d'un hôte, à utiliser avec les <a
- href="../vhosts/">serveurs virtuels à base de nom</a>.</p>
+ le nom de chemin d'URL patrimonial d'un hôte, à utiliser avec les <a
+ href="../vhosts/name-based.html">serveurs virtuels à base de nom</a>.</p>
+
+ <note><p>Il s’agit d’une fonctionnalité patrimoniale qui permet d’assurer
+ une compatibilité avec les clients HTTP/1.0 qui n’envoient pas d’en-tête
+ <code>Host:</code>. Lorsqu’un tel client soumet un URL correspondant à la
+ valeur de la directive <directive>ServerPath</directive> d’un serveur
+ virtuel, la requête est servie depuis ce serveur virtuel. En pratique, tous
+ les clients HTTP modernes envoient l’en-tête <code>Host:</code>, ce qui rend
+ cette directive inutile.</p></note>
</usage>
<seealso><a href="../vhosts/">Documentation sur les serveurs virtuels
du serveur HTTP Apache</a></seealso>
+<seealso><a href="../vhosts/name-based.html">Prise en charge des serveurs
+virtuels à base de nom</a></seealso> <seealso><a
+href="../vhosts/examples.html#serverpath">Exemple d’utilisation de
+ServerPath</a></seealso>
</directivesynopsis>
<directivesynopsis>
<code>None</code>.</p>
<note><title>Note</title>
- <p>Comme <directive>SetHandler</directive> l'emporte sur la
- définition des gestionnaires par défaut, le comportement habituel
- consistant à traiter les URLs se terminant par un slash (/) comme
- des répertoires ou des fichiers index est désactivé.</p></note>
+ <p>Comme <directive>SetHandler</directive> l'emporte sur la définition des
+ gestionnaires par défaut, le comportement habituel consistant à traiter les
+ URLs se terminant par un slash (/) comme des répertoires ou des fichiers
+ index est désactivé. Cette directive outrepasse aussi la directive
+ <directive module="mod_dir">FallbackResource</directive>, car un
+ gestionnaire est déjà explicitement assigné à la requête.
+ </p></note>
</usage>
<seealso><directive module="mod_mime">AddHandler</directive></seealso>
+<seealso><directive module="mod_dir">FallbackResource</directive></seealso>
</directivesynopsis>
réponse. Dans le cas d'un serveur mandataire, la taille du corps de
requête n'est pas limitée à 64Kb.</p>
+ <p>Les directives <directive type="section" module="core">Limit</directive>
+ ou <directive type="section" module="core">LimitExcept</directive> ne
+ permettent pas de restreindre la méthode <code>TRACE</code>. Pour ce faire,
+ utilisez la directive <directive>TraceEnable</directive>.</p>
+
<note><title>Note</title>
<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
projects / thirdparty / apache / httpd.git / commitdiff
