From: Lucien Gentis Date: Mon, 25 May 2026 15:26:16 +0000 (+0000) Subject: fr doc XML file update X-Git-Tag: 2.4.68-rc1-candidate~90 X-Git-Url: http://git.ipfire.org/gitweb/index.cgi?a=commitdiff_plain;h=5d0eb2e3759009e79665c0e206596cdf431c3bb6;p=thirdparty%2Fapache%2Fhttpd.git fr doc XML file update git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1934593 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/core.xml.fr b/docs/manual/mod/core.xml.fr index 71645c61c7..896215b13d 100644 --- a/docs/manual/mod/core.xml.fr +++ b/docs/manual/mod/core.xml.fr @@ -1,7 +1,7 @@ - + @@ -169,7 +169,7 @@ nom de chemin en fin de requête. comme /test/here.html/more dans l'exemple ci-dessus renverra une erreur "404 NOT FOUND". -
On
Une requête sera acceptée si la partie +
On
Une requête sera acceptée si la partie principale du chemin correspond à un fichier existant. Dans l'exemple ci-dessus /test/here.html/more, la requête sera acceptée si /test/here.html correspond à un nom de @@ -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|type directive [type directive] ... -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,11 +466,12 @@ 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.
Nonfatal=[Override|Unknown|All]
@@ -547,7 +559,7 @@ All pour les versions antérieures AllowOverrideList Directives autorisées dans les fichiers .htaccess AllowOverrideList None|directive -[directive-type] ... +[directive] ... AllowOverrideList None directory @@ -600,8 +612,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.

+ groupement FileInfo. Le jeu de directives permises effectif est + l’union des deux. Toutes les autres provoqueront 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 @@ -681,19 +702,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é.

-

règles REQUEST_URI :

+

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.

+ +

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

 @@ -984,11 +1029,13 @@ 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 "/"> @@ -996,10 +1043,10 @@ 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}/"> @@ -1051,10 +1102,10 @@ 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. + 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 @@ -1356,13 +1407,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.

@@ -1381,17 +1429,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. 7230 (Request Splitting) et 7230 (Response Smuggling) ne rappellent que deux des + risques potentiels induits par des requêtes non conformes, alors que 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 @@ -1423,16 +1469,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 @@ -1452,15 +1496,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 +

La section "Compatibility With Previous Versions" de la 2616 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.

@@ -1583,6 +1625,22 @@ ErrorDocument 403 Forbidden! ErrorDocument 403 /errors/forbidden.py?referrer=%{escape:%{HTTP_REFERER}} +

Quand l’argument est une chaîne de texte (c’est-à-dire ni un chemin, ni + un URL), il est envoyé au client avec text/html 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 :

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

De plus, on peut spécifier la valeur spéciale default pour indiquer l'utilisation d'un simple message d'Apache httpd codé en dur. Bien que non nécessaire dans des circonstances normales, la @@ -1732,15 +1790,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.

-

Il peut arriver que certains items de la chaîne de format ne +

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 %a du format [%t] [%l] [%a] %M  n'est pas disponible, les crochets qui l'entourent ne seront eux-mêmes pas @@ -1760,8 +1818,9 @@ ErrorLogFormat "[%t] [%l] [pid %P] %F: %E: [client %a] %M"

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

@@ -1789,12 +1848,13 @@ ErrorLogFormat "[%t] [%l] [pid %P] %F: %E: [client %a] %M" %4{Referer}i N'enregistre le contenu de l'en-tête Referer que si - la sévérité du message de journalisation est supérieure à 4. + la sévérité du message de journalisation est 4 (avertissement) ou supérieure + (niveaux 1 à 4 : alerte, critique, erreur, avertissement). -

Certains items de format acceptent des paramètres supplémentaires +

Certains spécificateurs de format acceptent des paramètres supplémentaires entre accolades.

@@ -2950,7 +3010,13 @@ certaines méthodes HTTP une section Limit pour la restriction d'accès, car une section LimitExcept fournit une protection contre - les méthodes arbitraires. + les méthodes arbitraires. Voir aussi la documentation sur la fusion des sections de + configuration pour un avertissement à propos de la manière dont une + directive Limit au sein d’une section + Location peut + outrepasser silencieusement les directives d’une section Directory.

Les directives Limit et LimitExcept @@ -3355,9 +3421,16 @@ spécifiées URL est un chemin d'URL de la forme /chemin/. Aucun protocole, nom d'hôte, port, ou chaîne de requête ne doivent apparaître. 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 direct + (forward) (configuré via ProxyRequests), l'URL + à comparer doit être de la forme protocole://nom_serveur/chemin, et vous devez inclure - le préfixe.

+ le préfixe. Avec un mandataire inverse (reverse) (configuré + via ProxyPass ou RewriteRule ... [P]), la requête arrive en + tant que chemin d’URL local ; il faut donc utiliser /chemin/, + comme vous le feriez pour la requête originale.

L'URL peut contenir des caractères génériques. Dans une chaîne avec caractères génériques, ? correspond à un caractère @@ -4174,10 +4247,14 @@ particulier Le serveur va suivre les liens symboliques dans le répertoire concerné. Il s'agit de la valeur par défaut. -

Bien que le serveur suive les liens symboliques, il ne modifie +

Quand le serveur suit les liens symboliques, il ne modifie pas le nom de chemin concerné défini par la section Directory.

+ +

Désactiver cette option empêche aussi mod_rewrite + d’agir dans un contexte de répertoire (fichiers .htaccess et + sections Directory.

Les options FollowSymLinks et SymLinksIfOwnerMatch ne fonctionnent que dans les @@ -4392,6 +4469,13 @@ seulement depuis la version 2.3.3 sous Windows.

Spécifier des protocoles non disponibles ou désactivés n'aura aucun effet, et ceux-ci seront simplement ignorés.

+ + 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 @@ -4825,9 +4909,10 @@ s'authentifier lui-même href="../vhosts/name-based.html">serveurs virtuels à base de noms.

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.

+ redirection relatives quand la directive + 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 @@ -4894,6 +4979,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 @@ -4915,8 +5008,20 @@ 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.

+ href="../vhosts/name-based.html">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.

 +Prise en charge des serveurs +virtuels à base de nom Exemple d’utilisation de +ServerPath Documentation sur les serveurs virtuels du serveur HTTP Apache @@ -5128,13 +5233,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 @@ -5269,6 +5378,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