From: Lucien Gentis Date: Mon, 25 May 2026 15:24:25 +0000 (+0000) Subject: fr doc XML file update. X-Git-Url: http://git.ipfire.org/gitweb/index.cgi?a=commitdiff_plain;h=db3902fa6b3ba08d9f32d201008ed36753934e59;p=thirdparty%2Fapache%2Fhttpd.git fr doc XML file update. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1934592 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/core.xml.fr b/docs/manual/mod/core.xml.fr index 2a735f1056..c0d187c9c5 100644 --- a/docs/manual/mod/core.xml.fr +++ b/docs/manual/mod/core.xml.fr @@ -1,7 +1,7 @@ - + @@ -151,7 +151,7 @@ nom de chemin en fin de requête. 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 - PATH_INFO.

+ PATH_INFO.

Supposons par exemple que /test/ pointe vers un répertoire qui ne contient que le fichier here.html. @@ -217,27 +217,39 @@ nom de chemin en fin de requête. -

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 activés pour ce répertoire. Par exemple - :

- - AccessFileName .acl - -

avant de renvoyer le document - /usr/local/web/index.html, le serveur va rechercher les - fichiers /.acl, /usr/.acl, - /usr/local/.acl et /usr/local/web/.acl - pour y lire d'éventuelles directives, à moins quelles n'aient été - désactivées avec

+

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 AllowOverride est activée pour le répertoire + considéré.

+ + 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. + +

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 AccessFileName dans + tous les répertoires du chemin du document, si les fichiers de configuration + distribués sont autorisés pour ce répertoire. + Par exemple, avant de renvoyer le document + /usr/local/web/index.html, le serveur va rechercher des + directives dans les fichiers /.htaccess, /usr/.htaccess, + /usr/local/.htaccess et /usr/local/web/.htaccess.

+ +

C’est pour cette raison que le fichier de configuration par défaut + contient les instructions suivantes :

<Directory "/"> AllowOverride None </Directory> + +

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 + DocumentRoot. Voir aussi la note à ce + sujet dans la documentation de la directive AllowOverride.

AllowOverride Fichiers de configuration @@ -343,16 +355,15 @@ autorisés à transiter dans les URLs tels quels .htaccess AllowOverride All|None|directive-type [directive-type] ... -AllowOverride None à partir de la version 2.3.9, AllowOverride -All pour les versions antérieures +AllowOverride None directory -

Lorsque le serveur trouve un fichier .htaccess (dont - le nom est défini par la directive AccessFileName), il doit savoir lesquelles - des directives placées dans ce fichier sont autorisées à modifier la - configuration préexistante.

+

Lorsque le serveur trouve un fichier de configuration distribuée (nommé + en général .htaccess — configurable à l’aide de la directive + AccessFileName), il doit savoir + lesquelles des directives placées dans ce fichier sont autorisées à modifier + la configuration préexistante.

Valable seulement dans les sections <Directory> @@ -455,14 +466,15 @@ All pour les versions antérieures
Limit
-
- Permet l'utilisation des directives contrôlant l'accès au serveur - (Allow, Deny et Order).
- - +
Permet l'utilisation des directives patrimoniales de contrôle d'accès + au serveur (Allow, + Deny et Order). Pour un équivalent moderne, + voir la directive Require + contrôlée par AuthConfig. Sont aussi incluses les directives + SSIETag, SSILastModified et SSILegacyExprParser.
@@ -498,13 +510,12 @@ All pour les versions antérieures
Permet l'utilisation des directives contrôlant les fonctionnalités - spécifiques d'un répertoire (Options et XBitHack). - 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 - Options. + spécifiques d'un répertoire (Options + et XBitHack). 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 Options. Désactivation implicite des options

Bien que la liste des options disponibles dans les fichiers @@ -527,7 +538,7 @@ All pour les versions antérieures AllowOverride AuthConfig Indexes -

Dans l'exemple ci-dessus, toutes les directives qui ne font +

Dans l'exemple ci-dessus, toutes les directives qui ne font partie ni du groupe AuthConfig, ni du groupe Indexes, provoquent une erreur "Internal Server Error".

@@ -551,7 +562,7 @@ All pour les versions antérieures AllowOverrideList Directives autorisées dans les fichiers .htaccess AllowOverrideList None|directive -[directive-type] ... +[directive] ... AllowOverrideList None directory @@ -604,8 +615,17 @@ AllowOverrideList CookieTracking CookieName module="core">AllowOverride autorise les directives du groupement AuthConfig, et AllowOverrideList n'autorise que deux - directives du groupement FileInfo. Toutes les autres - provoqueront une erreur interne du serveur.

+ directives du groupement FileInfo. Le jeu de directives + permises effectif est l’union des deux. Toutes les autres causeront une + erreur interne du serveur.

+ +

En outre, certaines directives sont toujours permises dans les fichiers + .htaccess, pourvu que le mécanisme d’outrepassement soit activé + (c’est-à-dire que la directive AllowOverride ne soit pas définie à + None). Ces directives sont listées dans la section All de l’index de la classe override.

AccessFileName @@ -711,19 +731,43 @@ Apache

Cette directive permet de contrôler la manière dont certaines variables CGI - sont définies.

+ 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 REQUEST_URI.

+ +

Par défaut, la variable d’environnement CGI REQUEST_URI + contient l’URI original de la requête du client. Cela implique que même si + mod_rewrite 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é.

+ +

Avec CGIVar REQUEST_URI current-uri, la valeur est définie à + l’URI actuel après l’application de toute réécriture ou redirection interne.

-

règles REQUEST_URI :

+

Valeurs autorisées :

original-uri (valeur par défaut)
-
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.
+
Définit REQUEST_URI avec l’URI de la requête originale du + client, sans tenir compte d’une réécriture ou redirection interne + quelconque.
current-uri
-
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.
+
Définit REQUEST_URI 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.
+ + +# Montrer aux scripts CGI l’URI réécrit à la place de l’original +CGIVar REQUEST_URI current-uri + + + Note +

Dans tous les cas, la variable d’environnement CGI REQUEST_URI + contient l’URI complet, y compris la chaîne de paramètres. Cela est différent + pour la variable de serveur %{REQUEST_URI} utilisée dans + mod_rewrite et les expressions de ap_expr, qui ne contient que la partie chemin (pas la + chaîne de paramètres).

 @@ -1006,11 +1050,12 @@ sous-répertoires, et à leur contenu. et la section Directory correspondante s'appliquera.

-

Notez que la politique d'accès par défaut + +

La politique d'accès par défaut dans les sections <Directory "/"> 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

+ situation à l'aide d'un bloc du style

<Directory "/"> @@ -1018,10 +1063,11 @@ sous-répertoires, et à leur contenu. </Directory> -

puis d'affiner la configuration pour les répertoires que vous +

Puis d’affiner la configuration pour les répertoires que vous voulez rendre accessibles. Voir la page Conseils à propos de sécurité - pour plus de détails.

+ pour plus de détails.

+

Les sections Directory se situent dans le fichier httpd.conf. Les directives -

Les balises DirectoryMatch - et </DirectoryMatch> 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 Directory. Cependant, le - répertoire est précisé sous la forme d'une expression rationnelle. Par exemple :

+

Les balises DirectoryMatch et + </DirectoryMatch> 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’expression rationnelle spécifiée. À la différence de + Directory, 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 ^ + ou $ dans le motif. Par exemple :

<DirectoryMatch "^/www/(.+/)?[0-9]{3}/"> @@ -1072,11 +1122,11 @@ du système de fichiers correspondant à une expression rationnelle - slash de fin - 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. + slash de fin + Cette directive s'applique aux requêtes pour des répertoires avec ou sans + slash de fin. Si vous ancrez votre motif avec $, vous devrez + peut-être comparer les deux formes ; par exemple, <DirectoryMatch + "^/var/www/?$">.

A partir de la version 2.4.8, les groupes nommés et les @@ -1381,13 +1431,10 @@ Apache

Cette directive permet de modifier les règles qui s'appliquent à la ligne - de requête HTTP (RFC 7230 - §3.1.1) et aux champs des en-têtes des requêtes HTTP (RFC 7230 - §3.2), qui s'appliquent maintenant par défaut ou en utilisant - l'option Strict. L'option Unsafe - a été ajoutée pour pouvoir restaurer les anciens + de requête HTTP (7230) et aux champs des en-têtes + des requêtes HTTP (7230), qui s'appliquent + maintenant par défaut ou en utilisant l'option Strict. L'option + Unsafe 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.

@@ -1406,17 +1453,15 @@ Apache

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. RFC 7230 §9.4 - Request Splitting et §9.5 Response - Smuggling ne rappellent que deux des risques potentiels induits par des - requêtes non conformes, alors que RFC 7230 - §3.5 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 Strict.

+ n'étaient pas forcément conformes au protocole. La 7230 (Request Splitting) et la 7230 (Response Smuggling) ne rappellent que deux des + risques potentiels induits par des requêtes non conformes, alors que la 7230 (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 Strict.

Risques de sécurité liés au mode Unsafe

Il est fortement déconseillé aux utilisateurs d'utiliser le mode @@ -1448,16 +1493,14 @@ Apache

RegisteredMethods|LenientMethods
-

La section de la RFC 7231 - §4.1 "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 - LenientMethods est utilisée, mais les administrateurs ont la - possibilité de limiter les méthodes utilisées via l'option - RegisteredMethods en enregistrant toute méthode non standard - via la directive RegisterHttpMethod, en particulier - si l'option Unsafe est utilisée.

+

La section "Overview" de la 7231 "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 LenientMethods est utilisée, mais les + administrateurs ont la possibilité de limiter les méthodes utilisées via + l'option RegisteredMethods en enregistrant toute méthode non + standard via la directive RegisterHttpMethod, en + particulier si l'option Unsafe est utilisée.

Compatibilité avec le mandat direct

L'option @@ -1477,16 +1520,13 @@ Apache

Allow0.9|Require1.0
-

La section de la RFC 2616 - §19.6 "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 7230 Appendix - A. A ce titre, l'option Require1.0 permet à l'utilisateur - d'inhiber le comportement induit par l'option par défaut - Allow0.9.

+

La 2616 "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 7230 Appendix A. A ce + titre, l'option Require1.0 permet à l'utilisateur d'inhiber le + comportement induit par l'option par défaut Allow0.9.

Exemple de requête provoquant l'envoi d'un message HTTP 400 en @@ -1609,6 +1649,22 @@ ErrorDocument 403 Forbidden! 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 @@ -1763,15 +1819,15 @@ ErrorLogFormat "[%t] [%l] [pid %P] %F: %E: [client %a] %M" 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 @@ -1791,8 +1847,9 @@ ErrorLogFormat "[%t] [%l] [pid %P] %F: %E: [client %a] %M" <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> @@ -1820,12 +1877,13 @@ ErrorLogFormat "[%t] [%l] [pid %P] %F: %E: [client %a] %M" <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"> @@ -2988,7 +3046,13 @@ certaines méthodes HTTP</description> 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> @@ -3393,9 +3457,16 @@ spécifiées</description> 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 @@ -4272,10 +4343,14 @@ particulier</description> 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 @@ -4490,6 +4565,13 @@ serveur HTTP Apache.</compatibility> <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

Le protocole http/1.1 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 + ProtocolsHonorOrder.

Si un serveur virtuel ne possède pas de directive Protocols propre, il hérite des protocoles spécifiés pour le serveur @@ -4934,8 +5016,9 @@ s'authentifier lui-même

Cette directive est aussi utilisée lors de la création d'URLs de redirection relatives quand la directive - UseCanonicalName est définie à une valeur autre que - la valeur par défaut.

+ UseCanonicalName est définie à + On. Si UseCanonicalName est définie à + DNS, une recherche DNS inverse est effectuée

Par exemple, si le nom de la machine hébergeant le serveur web est @@ -4971,7 +5054,6 @@ s'authentifier lui-même doit apparaître dans l'en-tête de requête Host: pour pouvoir atteindre ce serveur virtuel.

-

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 @@ -5002,6 +5084,14 @@ s'authentifier lui-même + +

Les adresses IPv6 ne sont actuellement pas prises + en charge par la directive ServerName et produisent + une erreur au démarrage du serveur, même si elles sont entourées de + crochets. Il s’agit d’un problème connu.

+ Problèmes concernant le DNS et @@ -5022,11 +5112,23 @@ de nom accédé par un navigateur incompatible

La directive ServerPath permet de définir - le nom de chemin d'URL hérité d'un hôte, à utiliser avec les serveurs virtuels à base de nom.

+ le nom de chemin d'URL patrimonial d'un hôte, à utiliser avec les serveurs virtuels à base de nom.

+ +

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 + Host:. Lorsqu’un tel client soumet un URL correspondant à la + valeur de la directive ServerPath 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 Host:, ce qui rend + cette directive inutile.

 Documentation sur les serveurs virtuels du serveur HTTP Apache +Prise en charge des serveurs +virtuels à base de nom Exemple d’utilisation de +ServerPath @@ -5235,13 +5337,17 @@ gestionnaire particulier None.

Note -

Comme SetHandler 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é.

 +

Comme SetHandler 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 + FallbackResource, car un + gestionnaire est déjà explicitement assigné à la requête. +

AddHandler +FallbackResource @@ -5376,6 +5482,11 @@ du serveur réponse. Dans le cas d'un serveur mandataire, la taille du corps de requête n'est pas limitée à 64Kb.

+

Les directives Limit + ou LimitExcept ne + permettent pas de restreindre la méthode TRACE. Pour ce faire, + utilisez la directive TraceEnable.

+ Note

Bien que certains prétendent le contraire, activer la méthode TRACE ne constitue pas un problème de sécurité dans Apache