From fe39ffb8b90ae4e002ed73fe98617cd590abb467 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sat, 27 Apr 2024 08:33:50 +0200 Subject: Adding upstream version 2.4.56. Signed-off-by: Daniel Baumann --- docs/manual/mod/core.html.fr.utf8 | 5669 +++++++++++++++++++++++++++++++++++++ 1 file changed, 5669 insertions(+) create mode 100644 docs/manual/mod/core.html.fr.utf8 (limited to 'docs/manual/mod/core.html.fr.utf8') diff --git a/docs/manual/mod/core.html.fr.utf8 b/docs/manual/mod/core.html.fr.utf8 new file mode 100644 index 0000000..0e9abf2 --- /dev/null +++ b/docs/manual/mod/core.html.fr.utf8 @@ -0,0 +1,5669 @@ + + + + + +core - Serveur HTTP Apache Version 2.4 + + + + + + + + +
<-
+ +
+

Fonctionalités de Base Apache

+
+

Langues Disponibles:  de  | + en  | + es  | + fr  | + ja  | + tr 

+
+ +
Description:Fonctionnalités de base du serveur HTTP Apache toujours +disponibles
Statut:Noyau httpd
+
+
Support Apache!

Directives

+ +

Traitement des bugs

Voir aussi

+
+ +
top
+

Directive AcceptFilter

+ + + + + + +
Description:Permet d'optimiser la configuration d'une socket pour +l'écoute d'un protocole
Syntaxe:AcceptFilter protocole filtre +d'acceptation
Contexte:configuration globale
Statut:Noyau httpd
Module:core
+

Cette directive permet d'effectuer une optimisation de la socket + d'écoute d'un type de protocole en fonction du système + d'exploitation. Le but premier est de faire en sorte que le noyau + n'envoie pas de socket au processus du serveur jusqu'à ce que + des données soient reçues, ou qu'une requête HTTP complète soit mise + en tampon. Seuls les Filtres d'acceptation de FreeBSD, le filtre plus + primitif TCP_DEFER_ACCEPT sous Linux, et la version + optimisée d'AcceptEx() de Windows sont actuellement supportés.

+ +

L'utilisation de l'argument none va désactiver tout + filtre d'acceptation pour ce protocole. Ceci s'avère utile pour les + protocoles qui nécessitent l'envoi de données par le serveur en + premier, comme ftp: ou nntp:

+
AcceptFilter nntp none
+ + +

Les noms de protocoles par défaut sont https pour le + port 443 et http pour tous les autres ports. Pour + spécifier un autre protocole à utiliser avec un port en écoute, + ajoutez l'argument protocol à la directive Listen.

+ +

Sous FreeBSD, les valeurs par défaut sont :

+
AcceptFilter http httpready
+AcceptFilter https dataready
+ + +

Le filtre d'acceptation httpready met en tampon des + requêtes HTTP entières au niveau du noyau. Quand une requête + entière a été reçue, le noyau l'envoie au serveur. Voir la page de + manuel de accf_http(9) pour plus de détails. Comme les requêtes + HTTPS sont chiffrées, celles-ci n'autorisent que le filtre accf_data(9).

+ +

Sous Linux, les valeurs par défaut sont :

+
AcceptFilter http data
+AcceptFilter https data
+ + +

Le filtre TCP_DEFER_ACCEPT de Linux ne supporte pas + la mise en tampon des requêtes http. Toute valeur autre que + none active le filtre TCP_DEFER_ACCEPT + pour ce protocole. Pour plus de détails, voir la page de + manuel Linux de tcp(7).

+ +

Sous Windows, les valeurs par défaut sont :

+
AcceptFilter http connect
+AcceptFilter https connect
+ + +

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. connect + utilise l'API AcceptEx(), extrait aussi les adresses réseau finales, + mais à l'instar de none, la valeur connect + n'attend pas la transmission des données initiales.

+ +

Sous Windows, none utilise accept() au lieu + d'AcceptEx(), et ne recycle pas les sockets entre les connexions. + Ceci s'avère utile pour les interfaces réseau dont le pilote est + défectueux, ainsi que pour certains fournisseurs de réseau comme les + pilotes vpn, ou les filtres anti-spam, anti-virus ou + anti-spyware.

+ +
+

L'AcceptFilter data (Windows)

+ +

Jusqu'à la version 2.4.23, le filtre d'acceptation data + 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.

+ +

La version actuelle de httpd prend par défaut le filtre + connect sous Windows, et reprendra la valeur + data si data est spécifié. Il est fortement + conseillé aux utilisateurs des versions plus anciennes de définir + explicitement le filtre connect pour leurs AcceptFilter + comme indiqué plus haut.

+
+ + +

Voir aussi

+ +
+
top
+

Directive AcceptPathInfo

+ + + + + + + + +
Description:Les ressources acceptent des informations sous forme d'un +nom de chemin en fin de requête.
Syntaxe:AcceptPathInfo On|Off|Default
Défaut:AcceptPathInfo Default
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:FileInfo
Statut:Noyau httpd
Module:core
+ +

Cette directive permet de définir si les requêtes contenant des + informations sous forme d'un nom de chemin suivant le nom d'un + 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.

+ +

Supposons par exemple que /test/ pointe vers un + répertoire qui ne contient que le fichier here.html. + Les requêtes pour /test/here.html/more et + /test/nothere.html/more vont affecter la valeur + /more à la variable d'environnement + PATH_INFO.

+ +

L'argument de la directive AcceptPathInfo + possède trois valeurs possibles :

+
+
Off
Une requête ne sera acceptée que si + elle correspond à un chemin qui existe. Par conséquent, une requête + contenant une information de chemin après le nom de fichier réel + 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 + 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 + fichier valide.
+ +
Default
Le traitement des requêtes est + déterminé par le gestionnaire responsable de la requête. + Le gestionnaire de base pour les fichiers normaux rejette par défaut + les requêtes avec PATH_INFO. Les gestionnaires qui + servent des scripts, commecgi-script et isapi-handler, acceptent en général par + défaut les requêtes avec PATH_INFO.
+
+ +

Le but premier de la directive AcceptPathInfo est de + vous permettre de remplacer le choix du gestionnaire d'accepter ou + de rejeter PATH_INFO. Ce remplacement est nécessaire + par exemple, lorsque vous utilisez un filtre, comme INCLUDES, pour générer un contenu basé + sur PATH_INFO. Le gestionnaire de base va en général + rejeter la requête, et vous pouvez utiliser la configuration + suivante pour utiliser un tel script :

+
<Files "mypaths.shtml">
+  Options +Includes
+  SetOutputFilter INCLUDES
+  AcceptPathInfo On
+</Files>
+ + + + +
+
top
+

Directive AccessFileName

+ + + + + + + +
Description:Nom du fichier de configuration distribué
Syntaxe:AccessFileName nom-du-fichier +[nom-du-fichier] ...
Défaut:AccessFileName .htaccess
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
+

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

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

Voir aussi

+ +
+
top
+

Directive AddDefaultCharset

+ + + + + + + + +
Description:Paramètre jeu de caractères par défaut à ajouter quand le +type de contenu d'une réponse est text/plain ou +text/html
Syntaxe:AddDefaultCharset On|Off|jeu de caractères
Défaut:AddDefaultCharset Off
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:FileInfo
Statut:Noyau httpd
Module:core
+

Cette directive spécifie une valeur par défaut pour le paramètre + jeu de caractères du type de média (le nom d'un codage de + caractères) à ajouter à une réponse, si et seulement si le type de + contenu de la réponse est soit text/plain, soit + text/html. Ceci va remplacer + tout jeu de caractères spécifié dans le corps de la réponse via un + élément META, bien que cet effet dépende en fait + souvent de la configuration du client de l'utilisateur. La + définition de AddDefaultCharset Off désactive cette + fonctionnalité. AddDefaultCharset On ajoute un jeu de + caractères par défaut de iso-8859-1. Toute autre valeur + peut être définie via le paramètre jeu de caractères, qui + doit appartenir à la liste des valeurs de + jeux de caractères enregistrés par l'IANA à utiliser dans les + types de média Internet (types MIME). + Par exemple :

+ +
AddDefaultCharset utf-8
+ + +

La directive AddDefaultCharset ne doit + être utilisée que lorsque toutes les ressources textes auxquelles + elle s'applique possèdent le jeu de caractère spécifié, et qu'il est + trop contraignant de définir leur jeu de caractères + individuellement. Un exemple de ce type est l'ajout du paramètre jeu + de caractères aux ressources comportant un contenu généré, comme les + scripts CGI hérités qui peuvent être vulnérables à des attaques de + type cross-site scripting à cause des données utilisateurs incluses + dans leur sortie. Notez cependant qu'une meilleur solution consiste + à corriger (ou supprimer) ces scripts, car la définition d'un jeu de + caractères par défaut ne protège pas les utilisateurs qui ont activé + la fonctionnalité "Détection automatique de l'encodage des + caractères" dans leur navigateur.

+ +

Voir aussi

+ +
+
top
+

Directive AllowEncodedSlashes

+ + + + + + + + +
Description:Détermine si les séparateurs de chemin encodés sont +autorisés à transiter dans les URLs tels quels
Syntaxe:AllowEncodedSlashes On|Off|NoDecode
Défaut:AllowEncodedSlashes Off
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
Compatibilité:L'option NoDecode est disponible depuis la version +2.3.12.
+

La directive AllowEncodedSlashes permet + l'utilisation des URLs contenant des séparateurs de chemin + encodés dans la partie chemin + (%2F pour / et même %5C pour + \ sur les systèmes concernés).

+ +

Avec la valeur par défaut, Off, de telles URLs sont + refusées et provoquent le renvoi d'une erreur 404 (Not found).

+ +

Avec la valeur On, ces URLs sont acceptées, et les + slashes encodés sont décodés comme tout autre caractère codé.

+ +

Avec la valeur NoDecode, ces URLs sont acceptées, + mais les slashes codés ne sont pas décodés et laissés dans leur état + codé.

+ +

Définir AllowEncodedSlashes à + On est surtout utile en association avec + PATH_INFO.

+ +

Note

+

Si le codage des slashes dans la partie chemin est nécessaire, + l'utilisation de l'option NoDecode est fortement + recommandée par mesure de sécurité. Permettre le décodage des + slashes pourrait éventuellement induire l'autorisation de chemins + non sûrs.

+
+ +

Voir aussi

+ +
+
top
+

Directive AllowOverride

+ + + + + + + +
Description:Types de directives autorisées dans les fichiers +.htaccess
Syntaxe:AllowOverride All|None|type directive +[type directive] ...
Défaut:AllowOverride None à partir de la version 2.3.9, AllowOverride +All pour les versions antérieures
Contexte:répertoire
Statut:Noyau httpd
Module:core
+

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.

+ +

Valable seulement dans les sections + <Directory>

+ La directive AllowOverride ne peut être + utilisée que dans les sections <Directory> définies sans expressions + rationnelles, et non dans les sections <Location>, <DirectoryMatch> ou + <Files>. +
+ +

Lorsque cette directive et la directive AllowOverrideList sont définies à None, les + fichiers .htaccess sont totalement + ignorés. Dans ce cas, le serveur n'essaiera même pas de lire les + fichiers .htaccess du système de fichiers.

+ +

Lorsque cette directive est définie à All, toute + directive valable dans le Contexte .htaccess sera + autorisée dans les fichiers .htaccess.

+ +

L'argument type directive peut contenir les + groupements de directives suivants (voir ce + document pour obtenir la liste à jour des directives activées pour + chaque type de directive) :

+ +
+
AuthConfig
+ +
+ + Permet l'utilisation des directives d'autorisation (AuthDBMGroupFile, + AuthDBMUserFile, + AuthGroupFile, + AuthName, + AuthType, AuthUserFile, Require, etc...).
+ +
FileInfo
+ +
+ Permet l'utilisation des directives qui contrôlent les types de + documents (directives ErrorDocument, ForceType, LanguagePriority, + SetHandler, SetInputFilter, SetOutputFilter, et directives du + module mod_mime Add* et Remove*), des metadonnées + des documents (Header, RequestHeader, SetEnvIf, SetEnvIfNoCase, BrowserMatch, CookieExpires, CookieDomain, CookieStyle, CookieTracking, CookieName), des directives du + module mod_rewrite directives (RewriteEngine, RewriteOptions, RewriteBase, RewriteCond, RewriteRule), des directives du + module mod_alias directives (Redirect, RedirectTemp, RedirectPermanent, RedirectMatch), et de la directive + Action du module + mod_actions. +
+ +
Indexes
+ +
+ Permet l'utilisation des directives qui contrôlent l'indexation + des répertoires (AddDescription, + AddIcon, AddIconByEncoding, + AddIconByType, + DefaultIcon, DirectoryIndex, FancyIndexing, + HeaderName, IndexIgnore, IndexOptions, ReadmeName, + etc...).
+ +
Limit
+ +
+ Permet l'utilisation des directives contrôlant l'accès au serveur + (Allow, Deny et Order).
+ +
Nonfatal=[Override|Unknown|All]
+ +
+ 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 : +
    +
  • Nonfatal=Override rend les directives + interdite par AllowOverride non fatales.
  • +
  • Nonfatal=Unknown rend les directives + inconnues non fatales. Sont concernées les erreurs de frappe + et les directives implémentées par un module non chargé.
  • +
  • Nonfatal=All rend toutes les directives + précédentes non fatales.
  • +
+

Notez qu'une erreur de syntaxe dans une directive valide + causera toujours une internal server error.

+

Sécurité

+ Les erreurs non fatales peuvent être à l'origine de problèmes + de sécurité pour les utilisateurs de fichiers .htaccess. Par + exemple, si AllowOverride interdit AuthConfig, toute + configuration utilisateur destinée à restreindre l'accès à un + site ne sera pas prise en compte. +
+
+ +
Options[=Option,...]
+ +
+ Permet l'utilisation des directives contrôlant les fonctionnalités + spécifiques d'un répertoire (Options et XBitHack). "Options" doit être + suivi d'un signe "égal", puis d'une liste d'options séparées par des + virgules (pas d'espaces) ; ces options doivent être définies à + l'aide de la commande Options. + +

Désactivation implicite des options

+

Bien que la liste des options disponibles dans les fichiers + .htaccess puisse être limitée par cette directive, tant qu'un + directive Options est + autorisée, toute autre option héritée peut être désactivée en + utilisant la syntaxe non-relative. En d'autres termes, ce + mécanisme ne peut pas forcer une option spécifique à rester + activée tout en permettant à toute autre option d'être + activée. +

+ +

+ AllowOverride Options=Indexes,MultiViews +

+ +
+
+ +

Exemple :

+ +
AllowOverride AuthConfig Indexes
+ + +

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

+ +

Pour des raisons de sécurité et de performance, ne + définissez pas AllowOverride à autre chose que + None dans votre bloc <Directory "/">. + Recherchez plutôt (ou créez) le bloc <Directory> + qui se réfère au répertoire où vous allez précisément placer un + fichier .htaccess.

+
+ +

Voir aussi

+ +
+
top
+

Directive AllowOverrideList

+ + + + + + + +
Description:Directives autorisées dans les fichiers .htaccess
Syntaxe:AllowOverrideList None|directive +[directive-type] ...
Défaut:AllowOverrideList None
Contexte:répertoire
Statut:Noyau httpd
Module:core
+

Lorsque le serveur trouve un fichier .htaccess + (comme spécifié par la directive AccessFileName), il doit savoir lesquelles + des directives déclarées dans ce fichier peuvent remplacer des + directives des fichiers de configuration du serveur.

+ +

Seulement disponible dans les sections <Directory>

+ La directive AllowOverrideList n'est + disponible que dans les sections <Directory> spécifiées sans expressions + rationnelles. +
+ +

Lorsque cette directive et la directive AllowOverride sont définies à + None, les fichiers .htaccess sont totalement ignorés. Dans + ce cas, le serveur ne cherchera même pas à lire des fichiers + .htaccess dans le système de fichiers.

+ +

Example:

+ +
AllowOverride None
+AllowOverrideList Redirect RedirectMatch
+ + +

Dans l'exemple ci-dessus, seules les directives + Redirect et RedirectMatch sont autorisées. + Toutes les autres provoqueront une erreur interne du serveur.

+ +

Example:

+ +
AllowOverride AuthConfig
+AllowOverrideList CookieTracking CookieName
+ + +

Dans l'exemple ci-dessus, la directive 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.

+ +

Voir aussi

+ +
+
top
+

Directive CGIMapExtension

+ + + + + + + + +
Description:Technique permettant de localiser l'interpréteur des +scripts CGI
Syntaxe:CGIMapExtension chemin CGI .extension
Contexte:répertoire, .htaccess
Surcharges autorisées:FileInfo
Statut:Noyau httpd
Module:core
Compatibilité:NetWare uniquement
+

Cette directive permet de contrôler la manière dont Apache httpd trouve + l'interpréteur servant à exécuter les scripts CGI. Par exemple, avec + la définition CGIMapExtension sys:\foo.nlm .foo, tous + les fichiers scripts CGI possédant une extension .foo + seront passés à l'interpréteur FOO.

+ +
+
top
+

Directive CGIPassAuth

+ + + + + + + + + +
Description:Active la transmission d'en-têtes d'autorisation HTTP aux scripts en +tant que variables CGI
Syntaxe:CGIPassAuth On|Off
Défaut:CGIPassAuth Off
Contexte:répertoire, .htaccess
Surcharges autorisées:AuthConfig
Statut:Noyau httpd
Module:core
Compatibilité:Disponible à partir de la version 2.4.13 du serveur HTTP +Apache
+

La directive CGIPassAuth permet aux + scripts d'accéder aux en-têtes d'autorisation HTTP tels que + Authorization, en-tête nécessaire aux scripts qui + implémente une authentification HTTP de base. Normalement, ces + en-têtes HTTP sont invisibles pour les scripts car ils leurs + permettraient de voir les identifiants et mots de passe + utilisés pour accéder au serveur lorsque l'authentification HTTP de + base est activée au niveau du serveur web. Cette directive doit être + définie à "On" lorsque des scripts sont autorisés à implémenter une + authentification HTTP de base.

+ +

Cette directive constitue une alternative à l'option de + compilation SECURITY_HOLE_PASS_AUTHORIZATION qui était + déjà disponible dans les versions précédentes du serveur HTTP + Apache.

+ +

Cette option est prise en compte par tout module qui utilise + ap_add_common_vars(), comme mod_cgi, + mod_cgid, mod_proxy_fcgi, + mod_proxy_scgi, etc... En particulier, elle affecte + les modules qui ne traitent pas à proprement parler les requêtes, + mais utilisent quand-même cette API, comme + mod_include ou mod_ext_filter. Les + modules tiers qui n'utilisent pas ap_add_common_vars() + peuvent aussi choisir de prendre en compte cette option.

+ +
+
top
+

Directive CGIVar

+ + + + + + + + +
Description:Contrôle la manière dont certaines variables CGI sont définies
Syntaxe:CGIVar variable rule
Contexte:répertoire, .htaccess
Surcharges autorisées:FileInfo
Statut:Noyau httpd
Module:core
Compatibilité:Disponible à partir de la version 2.4.21 du serveur HTTP Apache
+

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

+ +

règles REQUEST_URI :

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

Directive ContentDigest

+ + + + + + + + +
Description:Active la génération d'un en-tête Content-MD5 +dans la réponse HTTP
Syntaxe:ContentDigest On|Off
Défaut:ContentDigest Off
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:Options
Statut:Noyau httpd
Module:core
+

Cette directive active la génération d'un en-tête + Content-MD5 selon les définitions des RFC 1864 et + 2616.

+ +

MD5 est un algorithme permettant de générer un condensé (parfois + appelé "empreinte") à partir de données d'une taille aléatoire ; le + degré de précision est tel que la moindre altération des données + d'origine entraîne une altération de l'empreinte.

+ +

L'en-tête Content-MD5 permet de vérifier + l'intégrité de la réponse HTTP dans son ensemble. Un serveur mandataire + ou un client peut utiliser cet en-tête pour rechercher une + éventuelle modification accidentelle de la réponse au cours de sa + transmission. Exemple d'en-tête :

+ +

+ Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA== +

+ +

Notez que des problèmes de performances peuvent affecter votre + serveur, car l'empreinte est générée pour chaque requête (il n'y a + pas de mise en cache).

+ +

L'en-tête Content-MD5 n'est envoyé qu'avec les + documents servis par le module core, à l'exclusion + de tout autre module. Ainsi, les documents SSI, les sorties de + scripts CGI, et les réponses à des requêtes partielles (byte range) + ne comportent pas cet en-tête.

+ +
+
top
+

Directive DefaultRuntimeDir

+ + + + + + + + +
Description:Répertoire de base des fichiers créés au cours de l'exécution du serveur
Syntaxe:DefaultRuntimeDir chemin-répertoire
Défaut:DefaultRuntimeDir DEFAULT_REL_RUNTIMEDIR (logs/)
Contexte:configuration globale
Statut:Noyau httpd
Module:core
Compatibilité:Disponible depuis la version 2.4.2 du serveur HTTP Apache
+

La directive DefaultRuntimeDir permet de + définir le répertoire dans lequel le serveur va créer les différents + fichiers relatifs à son exécution (mémoire partagée, verrous, + etc...). Si le chemin spécifié est relatif, le chemin absolu sera + généré relativement à la valeur de la directive + ServerRoot

+ +

Example

+
DefaultRuntimeDir scratch/
+ + +

La valeur par défaut de la directive + DefaultRuntimeDir peut être modifiée en + changeant la valeur de la macro DEFAULT_REL_RUNTIMEDIR + définie à la compilation.

+ +

Note: si la valeur de ServerRoot n'a pas + été spécifiée avant d'utiliser cette directive, c'est la valeur par + défaut de ServerRoot qui sera utilisée pour + définir la base du répertoire.

+ + +

Voir aussi

+ +
+
top
+

Directive DefaultType

+ + + + + + + + + +
Description:Les seuls effets de cette directive sont des émissions +d'avertissements si sa valeur est différente de none. Dans +les versions précédentes, DefaultType permettait de spécifier un type de +média à assigner par défaut au contenu d'une réponse pour lequel aucun +autre type de média n'avait été trouvé. +
Syntaxe:DefaultType type média|none
Défaut:DefaultType none
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:FileInfo
Statut:Noyau httpd
Module:core
Compatibilité:L'argument none est disponible dans les +versions d'Apache httpd 2.2.7 et supérieures. Tous les autres choix sont +DESACTIVÉS à partir des version 2.3.x.
+

Cette directive a été désactivée. Pour la compatibilité + ascendante avec les anciens fichiers de configuration, elle peut + être spécifiée avec la valeur none, c'est à dire sans + type de médium par défaut. Par exemple :

+ +
DefaultType None
+ + +

DefaultType None n'est disponible que dans les + versions d'Apache 2.2.7 et supérieures.

+ +

Utilisez le fichier de configuration mime.types et la directive + AddType pour configurer + l'assignement d'un type de médium via les extensions de fichiers, ou + la directive ForceType pour + attribuer un type de médium à des ressources spécifiques. Dans le + cas contraire, le serveur enverra sa réponse sans champ d'en-tête + Content-Type, et le destinataire devra déterminer lui-même le type + de médium.

+ +
+
top
+

Directive Define

+ + + + + + +
Description:Permet de définir une variable
Syntaxe:Define nom-paramètre [valeur-paramètre]
Contexte:configuration globale, serveur virtuel, répertoire
Statut:Noyau httpd
Module:core
+

Avec un seul paramètre, l'effet de la directive + Define est identique à celui de l'argument + -D du programme httpd. Il permet de + modifier le comportement des sections <IfDefine> sans avoir à ajouter d'argument + -D au sein des scripts de démarrage.

+ +

De plus, le second paramètre permet d'affecter une valeur à la + variable définie par le premier. Cette variable peut être référencée + dans le fichier de configuration via la syntaxe ${VAR}. + La portée de la variable est toujours globale, et n'est jamais + limitée à la section de configuration courante.

+ +
<IfDefine TEST>
+  Define servername test.example.com
+</IfDefine>
+<IfDefine !TEST>
+  Define servername www.example.com
+  Define SSL
+</IfDefine>
+
+DocumentRoot "/var/www/${servername}/htdocs"
+ + +

Le caractère ":" est interdit dans les noms de variables afin + d'éviter les conflits avec la syntaxe de la directive RewriteMap.

+ +

Portée de la directive et pièges à éviter

+

Si cette directive est définie au sein d'un bloc VirtualHost, les + changements qu'elle induit sont visibles de toute directive + ultérieure, au delà de tout bloc VirtualHost.

+
+ +

Voir aussi

+ +
+
top
+

Directive <Directory>

+ + + + + + +
Description:Regroupe un ensemble de directives qui ne s'appliquent +qu'au répertoire concerné du système de fichiers, à ses +sous-répertoires, et à leur contenu.
Syntaxe:<Directory chemin répertoire> +... </Directory>
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
+

Les balises <Directory> et + </Directory> permettent de regrouper un ensemble + de directives qui ne s'appliquent qu'au répertoire précisé, + à ses sous-répertoires, et aux fichiers situés dans ces + sous-répertoires. Toute directive + autorisée dans un contexte de répertoire peut être utilisée. + chemin répertoire est soit le chemin absolu d'un + répertoire, soit une chaîne de caractères avec caractères génériques + utilisant la comparaison Unix de style shell. Dans une chaîne de + caractères avec caractères génériques, ? correspond à + un caractère quelconque, et * à toute chaîne de + caractères. Les intervalles de caractères [] sont aussi + autorisés. Aucun caractère générique ne peut remplacer le caractère + `/', si bien que l'expression <Directory + "/*/public_html"> ne conviendra pas pour le chemin + * /home/user/public_html, alors que <Directory + "/home/*/public_html"> conviendra. Exemple :

+ +
<Directory "/usr/local/httpd/htdocs">
+  Options Indexes FollowSymLinks
+</Directory>
+ + +

Les chemins de répertoires contenant des espaces doivent être + entourés de guillemets afin d'empêcher l'interprétation de ces + espaces comme fins d'arguments.

+ +
+

Soyez prudent avec l'argument chemin répertoire : il + doit correspondre exactement au chemin du système de fichier + qu'Apache httpd utilise pour accéder aux fichiers. Les directives + comprises dans une section <Directory> ne + s'appliqueront pas aux fichiers du même répertoire auxquels on + aura accédé via un chemin différent, per exemple via un lien + symbolique.

+
+ +

Les Expressions rationnelles + peuvent aussi être utilisées en ajoutant le caractère + ~. Par exemple :

+ +
<Directory ~ "^/www/[0-9]{3}">
+
+</Directory>
+ + +

pourra correspondre à tout répertoire situé dans /www/ et dont le + nom se compose de trois chiffres.

+ +

Si plusieurs sections <Directory> (sans expression rationnelle) + correspondent au répertoire (ou à un de ses parents) qui contient le + document, les directives de la section <Directory> dont le chemin est le plus + court sont appliquées en premier, en s'intercalant avec les + directives des fichiers .htaccess. Par + exemple, avec

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

l'accès au document /home/web/dir/doc.html emprunte + le chemin suivant :

+ +
    +
  • Aplication de la directive AllowOverride None + (qui désactive les fichiers .htaccess).
  • + +
  • Application de la directive AllowOverride + FileInfo (pour le répertoire /home).
  • + +
  • Application de toute directive FileInfo qui se + trouverait dans d'éventuels fichiers /home/.htaccess, + /home/web/.htaccess ou + /home/web/dir/.htaccess, dans cet ordre.
  • +
+ +

Les directives associées aux répertoires sous forme d'expressions + rationnelles ne sont prises en compte qu'une fois toutes les + directives des sections sans expressions rationnelles appliquées. + Alors, tous les répertoires avec expressions rationnelles sont + testés selon l'ordre dans lequel ils apparaissent dans le fichier de + configuration. Par exemple, avec

+ +
<Directory ~ "abc$">
+  # ... directives ici ...
+</Directory>
+ + +

la section avec expression rationnelle ne sera prise en compte + qu'après les sections <Directory> sans expression rationnelle + et les fichiers .htaccess. Alors, l'expression + rationnelle conviendra pour /home/abc/public_html/abc + et la section <Directory> + correspondante s'appliquera.

+ +

Notez que 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

+ +
<Directory "/">
+  Require all denied
+</Directory>
+ + +

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.

+ +

Les sections <Directory> se situent + dans le fichier httpd.conf. Les directives <Directory> ne peuvent pas être imbriquées + et ne sont pas autorisées dans les sections <Limit> ou <LimitExcept>.

+ +

Voir aussi

+ +
+
top
+

Directive <DirectoryMatch>

+ + + + + + +
Description:Regroupe des directives qui s'appliquent au contenu de répertoires +du système de fichiers correspondant à une expression rationnelle
Syntaxe:<DirectoryMatch regex> +... </DirectoryMatch>
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
+

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 :

+ +
<DirectoryMatch "^/www/(.+/)?[0-9]{3}/">
+    # ...
+</DirectoryMatch>
+ + +

convient pour les sous-répertoires de /www/ dont + le nom se compose de trois chiffres.

+ +

Compatibilité

+ Avant la version 2.3.9, cette directive s'appliquait aussi aux + sous-répertoires (comme la directive <Directory>), et ne tenait pas compte du + symbole de fin de ligne ($). Depuis la version 2.3.9, seuls les + répertoires qui correspondent à l'expression sont affectés par les + directives contenues dans la section. +
+ +

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

A partir de la version 2.4.8, les groupes nommés et les + références arrières sont extraits et enregistrés dans + l'environnement avec leur nom en majuscules et préfixé + par "MATCH_". Ceci permet + de référencer des URLs dans des expressions + ou au sein de modules comme mod_rewrite. Pour + éviter toute confusion, les références arrières numérotées (non + nommées) sont ignorées. Vous devez utiliser à la place des groupes + nommés.

+ +
<DirectoryMatch "^/var/www/combined/(?<sitename>[^/]+)">
+    Require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
+</DirectoryMatch>
+ + + +

Voir aussi

+ +
+
top
+

Directive DocumentRoot

+ + + + + + + +
Description:Racine principale de l'arborescence des documents visible +depuis Internet
Syntaxe:DocumentRoot chemin répertoire
Défaut:DocumentRoot "/usr/local/apache/htdocs"
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
+

Cette directive permet de définir le répertoire à partir duquel + httpd va servir les fichiers. S'il ne correspond + pas à un Alias, le chemin + de l'URL sera ajouté par le serveur à la racine des documents afin + de construire le chemin du document recherché. Exemple :

+ +
DocumentRoot "/usr/web"
+ + +

un accès à http://my.example.com/index.html se + réfère alors à /usr/web/index.html. Si chemin + répertoire n'est pas un chemin absolu, il est considéré comme + relatif au chemin défini par la directive ServerRoot.

+ +

Le répertoire défini par la directive + DocumentRoot ne doit pas comporter de slash + final.

+ +

Voir aussi

+ +
+
top
+

Directive <Else>

+ + + + + + + + +
Description:Contient des directives qui ne s'appliquent que si la +condition correspondant à la section <If> ou <ElseIf> précédente n'est pas satisfaite par la +requête à l'exécution
Syntaxe:<Else> ... </Else>
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:All
Statut:Noyau httpd
Module:core
Compatibilité:Les conditions imbriquées sont supportées à partir de la version +2.4.26 du serveur HTTP Apache
+

La section <Else> applique + les directives qu'elle contient si et seulement si les conditions + correspondant à la section <If> + ou <ElseIf> immédiatement + supérieure et dans la même portée n'ont pas été satisfaites. Par + exemple, dans :

+ +
<If "-z req('Host')">
+  # ...
+</If>
+<Else>
+  # ...
+</Else>
+ + +

La condition de la section <If> serait satisfaite pour les requêtes + HTTP/1.0 sans en-tête Host:, alors que celle de la section + <Else> le serait pour les + requêtes comportant un en-tête Host:.

+ + +

Voir aussi

+ +
+
top
+

Directive <ElseIf>

+ + + + + + + + +
Description:Contient des directives qui ne s'appliquent que si la +condition correspondante est satisfaite par une requête à l'exécution, +alors que la condition correspondant à la section <If> ou <ElseIf> précédente ne l'était pas.
Syntaxe:<ElseIf expression> ... </ElseIf>
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:All
Statut:Noyau httpd
Module:core
Compatibilité:Les conditions imbriquées sont supportées à partir de la version +2.4.26 du serveur HTTP Apache
+

La section <ElseIf> applique + les directives qu'elle contient si et seulement si d'une part la + condition correspondante est satisfaite, et d'autre part la condition + correspondant à la section <If> + ou <ElseIf> de la même portée ne + l'est pas. Par exemple, dans :

+ +
<If "-R '10.1.0.0/16'">
+  #...
+</If>
+<ElseIf "-R '10.0.0.0/8'">
+  #...
+</ElseIf>
+<Else>
+  #...
+</Else>
+ + +

La condition correspondant à la section <ElseIf> est satisfaite si l'adresse + distante de la requête appartient au sous-réseau 10.0.0.0/8, mais + pas si elle appartient au sous-réseau 10.1.0.0/16.

+ + +

Voir aussi

+ +
+
top
+

Directive EnableMMAP

+ + + + + + + + +
Description:Utilise la projection en mémoire (Memory-Mapping) pour +lire les fichiers pendant qu'ils sont servis
Syntaxe:EnableMMAP On|Off
Défaut:EnableMMAP On
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:FileInfo
Statut:Noyau httpd
Module:core
+

Cette directive définit si httpd peut utiliser + la projection en mémoire (Memory-Mapping) quand il doit lire le contenu + d'un fichier pendant qu'il est servi. Par défaut, lorsque le + traitement d'une requête requiert l'accès aux données contenues dans + un fichier -- par exemple, pour servir un fichier interprété par le + serveur à l'aide de mod_include -- Apache httpd projette + le fichier en mémoire si le système d'exploitation le permet.

+ +

Cette projection en mémoire induit parfois une amélioration des + performances. Sur certains systèmes cependant, il est préférable de + désactiver la projection en mémoire afin d'éviter certains problèmes + opérationnels :

+ +
    +
  • Sur certains systèmes multi-processeurs, la projection en + mémoire peut dégrader les performances du programme + httpd.
  • +
  • S'il fait l'objet d'une projection en mémoire par + httpd, la suppression ou la troncature d'un + fichier peut provoquer un crash de httpd avec une + erreur de segmentation.
  • +
+ +

Pour les configurations de serveur sujettes à ce genre de + problème, il est préférable de désactiver la projection en mémoire + des fichiers servis en spécifiant :

+ +
EnableMMAP Off
+ + +

Pour les montages NFS, cette fonctionnalité peut être + explicitement désactivée pour les fichiers concernés en spécifiant + :

+ +
<Directory "/path-to-nfs-files">
+  EnableMMAP Off
+</Directory>
+ + +
+
top
+

Directive EnableSendfile

+ + + + + + + + + +
Description:Utilise le support sendfile du noyau pour servir les +fichiers aux clients
Syntaxe:EnableSendfile On|Off
Défaut:EnableSendfile Off
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:FileInfo
Statut:Noyau httpd
Module:core
Compatibilité:Par défaut à Off depuis la version 2.3.9.
+

Cette directive définit si le programme httpd + peut utiliser le support sendfile du noyau pour transmettre le + contenu des fichiers aux clients. Par défaut, lorsque le traitement + d'une requête ne requiert pas l'accès aux données contenues dans un + fichier -- par exemple, pour la transmission d'un fichier statique + -- Apache httpd utilise sendfile pour transmettre le contenu du fichier + sans même lire ce dernier, si le système d'exploitation le + permet.

+ +

Ce mécanisme sendfile évite la séparation des opérations de + lecture et d'envoi, ainsi que les réservations de tampons. sur + certains systèmes cependant, ou sous certains systèmes de fichiers, + il est préférable de désactiver cette fonctionnalité afin d'éviter + certains problèmes opérationnels :

+ +
    +
  • Certains systèmes peuvent présenter un support sendfile + défectueux que le système de compilation n'a pas détecté, en + particulier si les exécutables ont été compilés sur une autre + machine, puis copiés sur la première avec un support sendfile + défectueux.
  • +
  • Sous Linux, l'utilisation de sendfile induit des bogues lors de + la récupération des paquets de vérification TCP (TCP-checksum) avec + certaines cartes réseau lorsqu'on utilise IPv6.
  • +
  • Sous Linux sur Itanium, sendfile peut s'avérer incapable de + traiter les fichiers de plus de 2 Go.
  • +
  • Avec un montage réseau de DocumentRoot (par exemple NFS, SMB, CIFS, + FUSE), le + noyau peut s'avérer incapable de servir un fichier de ce montage + réseau en passant par son propre cache.
  • +
+ +

Pour les configurations de serveur non sujettes à ce genre de + problème, vous pouvez activer cette fonctionnalité en + spécifiant :

+ +
EnableSendfile On
+ + +

Pour les montages réseau, cette fonctionnalité peut être + explicitement désactivée pour les fichiers concernés en spécifiant + :

+ +
<Directory "/path-to-nfs-files">
+  EnableSendfile Off
+</Directory>
+ +

Veuillez noter que la configuration de la directive + EnableSendfile dans un contexte de répertoire + ou de fichier .htaccess n'est pas supportée par + mod_cache_disk. Le module ne prend en compte la + définition de EnableSendfile que dans un + contexte global. +

+ +
+
top
+

Directive Error

+ + + + + + + +
Description:Interrompt la lecture de la configuration avec un message +d'erreur personnalisé
Syntaxe:Error message
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Statut:Noyau httpd
Module:core
Compatibilité:à partir de la version 2.3.9
+

Si une erreur peut être détectée dans la configuration, souvent + un module manquant, cette + directive peut être utilisée pour générer un message d'erreur + personnalisé, et interrompre la lecture de la configuration.

+ +
# Exemple
+# vérification du chargement de mod_include
+<IfModule !include_module>
+  Error "mod_include is required by mod_foo.  Load it with LoadModule."
+</IfModule>
+
+# vérification de la définition de SSL ou (exclusif) NOSSL
+<IfDefine SSL>
+<IfDefine NOSSL>
+  Error "Both SSL and NOSSL are defined.  Define only one of them."
+</IfDefine>
+</IfDefine>
+<IfDefine !SSL>
+<IfDefine !NOSSL>
+  Error "Either SSL or NOSSL must be defined."
+</IfDefine>
+</IfDefine>
+ + +

Note

+

Cette directive est évaluée lors du traitement de la configuration, + et non à l'exécution. Par conséquent, elle ne peut pas être évaluée de + manière conditionnelle en l'incluant dans une section <If>.

+
+ + +
+
top
+

Directive ErrorDocument

+ + + + + + + +
Description:Document que le serveur renvoie au client en cas +d'erreur
Syntaxe:ErrorDocument code erreur document
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:FileInfo
Statut:Noyau httpd
Module:core
+

Apache httpd peut traiter les problèmes et les erreurs de quatre + manières,

+ +
    +
  1. afficher un simple message d'erreur au contenu fixe
  2. + +
  3. afficher un message personnalisé
  4. + +
  5. rediriger en interne vers un chemin d'URL local pour traiter + le problème ou l'erreur
  6. + +
  7. rediriger vers une URL externe pour traiter + le problème ou l'erreur
  8. +
+ +

La première option constitue le comportement par défaut; pour + choisir une des trois autres options, il faut configurer Apache à + l'aide de la directive ErrorDocument, suivie + du code de la réponse HTTP et d'une URL ou d'un message. Apache + httpd fournit parfois des informations supplémentaires à propos du + problème ou de l'erreur.

+ +

A partir de la version 2.4.13, il est possible d'utiliser la syntaxe des expressions dans cette directive + afin de générer des chaînes et URLs dynamiques.

+ +

Les URLs peuvent commencer par un slash (/) pour les chemins web + locaux (relatifs au répertoire défini par la directive DocumentRoot), ou se présenter sous la + forme d'une URL complète que le client pourra résoudre. + Alternativement, un message à afficher par le navigateur pourra être + fourni. Notez que la décision de considérer le paramètre comme URL, + chemin ou message intervient avant toute interprètation + d'expression. Exemples :

+ +
ErrorDocument 500 http://example.com/cgi-bin/server-error.cgi
+ErrorDocument 404 /errors/bad_urls.php
+ErrorDocument 401 /subscription_info.html
+ErrorDocument 403 "Sorry can't allow you access today"
+ErrorDocument 403 Forbidden!
+ErrorDocument 403 /errors/forbidden.py?referrer=%{escape:%{HTTP_REFERER}}
+ + +

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 + spécification de la valeur default va permettre de + rétablir l'utilisation du simple message d'Apache httpd codé en dur pour + les configurations qui sans cela, hériteraient d'une directive + ErrorDocument existante.

+ +
ErrorDocument 404 /cgi-bin/bad_urls.pl
+
+<Directory "/web/docs">
+  ErrorDocument 404 default
+</Directory>
+ + +

Notez que lorsque vous spécifiez une directive + ErrorDocument pointant vers une URL distante + (c'est à dire tout ce qui commence par le préfixe http), le serveur + HTTP Apache va + envoyer une redirection au client afin de lui indiquer où trouver le + document, même dans le cas où ce document se trouve sur le serveur + local. Ceci a de nombreuses conséquences dont la plus importante + réside dans le fait que le client ne recevra pas le code d'erreur + original, mais au contraire un code de statut de redirection. Ceci + peut en retour semer la confusion chez les robots web et divers + clients qui tentent de déterminer la validité d'une URL en examinant + le code de statut. De plus, si vous utilisez une URL distante avec + ErrorDocument 401, le client ne saura pas qu'il doit + demander un mot de passe à l'utilisateur car il ne recevra pas le + code de statut 401. C'est pourquoi, si vous utilisez une + directive ErrorDocument 401, elle devra faire référence + à un document par le biais d'un chemin local.

+ +

Microsoft Internet Explorer (MSIE) ignore par défaut les messages + d'erreur générés par le serveur lorsqu'ils sont trop courts et + remplacent ses propres messages d'erreur "amicaux". Le seuil de + taille varie en fonction du type d'erreur, mais en général, si la + taille de votre message d'erreur est supérieure à 512 octets, il y a + peu de chances pour que MSIE l'occulte, et il sera affiché par ce + dernier. Vous trouverez d'avantage d'informations dans l'article de + la base de connaissances Microsoft Q294807.

+ +

Bien que la plupart des messages d'erreur internes originaux + puissent être remplacés, ceux-ci sont cependant conservés dans + certaines circonstances sans tenir compte de la définition de la + directive ErrorDocument. En + particulier, en cas de détection d'une requête mal formée, le + processus de traitement normal des requêtes est immédiatement + interrompu, et un message d'erreur interne est renvoyé, ceci afin de + se prémunir contre les problèmes de sécurité liés aux requêtes mal + formées.

+ +

Si vous utilisez mod_proxy, il est en général préférable + d'activer ProxyErrorOverride afin d'être en + mesure de produire des messages d'erreur personnalisés pour le + compte de votre serveur d'origine. Si vous n'activez pas + ProxyErrorOverride, Apache httpd ne générera pas de messages d'erreur + personnalisés pour le contenu mandaté.

+ + +

Voir aussi

+ +
+
top
+

Directive ErrorLog

+ + + + + + + +
Description:Définition du chemin du journal des erreurs
Syntaxe: ErrorLog file-path|syslog[:[facility][:tag]]
Défaut:ErrorLog logs/error_log (Unix) ErrorLog logs/error.log (Windows and OS/2)
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
+

La directive ErrorLog permet de définir le + nom du fichier dans lequel le serveur va journaliser toutes les + erreurs qu'il rencontre. Si le file-path n'est pas + absolu, il est considéré comme relatif au chemin défini par la + directive ServerRoot.

+ +
ErrorLog "/var/log/httpd/error_log"
+ + +

Si le file-path commence par une barre verticale + "(|)", il est considéré comme une commande à lancer pour traiter la + journalisation de l'erreur.

+ +
ErrorLog "|/usr/local/bin/httpd_errors"
+ + +

Voir les notes à propos des journaux + redirigés pour plus d'informations.

+ +

L'utilisation de syslog à la place d'un nom de + fichier active la journalisation via syslogd(8) si le système le + supporte. Le dispositif syslog par défaut est local7, + mais vous pouvez le modifier à l'aide de la syntaxe + syslog:facility, où facility peut + être remplacé par un des noms habituellement documentés dans la page + de man syslog(1). Le dispositif syslog local7 est + global, et si il est modifié dans un serveur virtuel, le dispositif + final spécifié affecte l'ensemble du serveur. La même règle s'applique au + tag syslog qui utilise par défaut le nom du binaire du serveur HTTP Apache + httpd dans la plupart des cas. Vous pouvez aussi modifier cette + valeur en utilisant la syntaxe syslog::tag.

+ +
ErrorLog syslog:user
+ErrorLog syslog:user:httpd.srv1
+ErrorLog syslog::httpd.srv2
+ + +

SECURITE : Voir le document conseils à propos de + sécurité pour des détails sur les raisons pour lesquelles votre + sécurité peut être compromise si le répertoire contenant les + fichiers journaux présente des droits en écriture pour tout autre + utilisateur que celui sous lequel le serveur est démarré.

+

Note

+

Lors de la spécification d'un chemin de fichier sur les + plates-formes non-Unix, on doit veiller à n'utiliser que des + slashes (/), même si la plate-forme autorise l'utilisation des + anti-slashes (\). Et d'une manière générale, il est recommandé de + n'utiliser que des slashes (/) dans les fichiers de + configuration.

+
+ +

Voir aussi

+ +
+
top
+

Directive ErrorLogFormat

+ + + + + + +
Description:Spécification du format des entrées du journal des erreurs
Syntaxe: ErrorLogFormat [connection|request] format
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
+

La directive ErrorLogFormat permet de + spécifier quelles informations supplémentaires vont être enregistrées + dans le journal des erreurs en plus du message habituel.

+ +
# Exemple simple
+ErrorLogFormat "[%t] [%l] [pid %P] %F: %E: [client %a] %M"
+ + +

La spécification de connection ou + request comme premier paramètre permet de définir des + formats supplémentaires, ce qui a pour effet de journaliser des + informations additionnelles lorsque le premier message est + enregistré respectivement pour une connexion ou une requête + spécifique. Ces informations additionnelles ne sont enregistrées + qu'une seule fois par connexion/requête. Si le traitement d'une + 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 + 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 + 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, + 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 + enregistrés. Il est possible d'échapper les espaces par un anti-slash + afin qu'ils ne soient pas considérés comme séparateurs de champs. + La combinaison '% ' (pourcentage espace) est un délimiteur de + champ de taille nulle qui ne génère aucune sortie.

+ +

Ce comportement peut être changé en ajoutant des modificateurs à + l'item de la chaîne de format. Le modificateur - + (moins) provoque l'enregistrement d'un signe moins si l'item + considéré ne génère aucune sortie. Pour les formats à enregistrement + unique par connexion/requête, il est aussi possible d'utiliser le + modificateur + (plus). Si un item ne générant aucune + sortie possède le modificateur plus, la ligne dans son ensemble est + omise.

+ +

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 + valeurs possibles vont de 1 (alert) à 15 (trace8), en passant par 4 + (warn) ou 7 (debug).

+ +

Par exemple, voici ce qui arriverait si vous ajoutiez des + modificateurs à l'item %{Referer}i qui enregistre le + contenu de l'en-tête Referer.

+ + + + + + + + + + + + + + +
Item modifiéSignification
%-{Referer}iEnregistre le caractère - si l'en-tête + Referer n'est pas défini.
%+{Referer}iN'enregistre rien si l'en-tête + Referer n'est pas défini.
%4{Referer}iN'enregistre le contenu de l'en-tête Referer que si + la sévérité du message de journalisation est supérieure à 4.
+ +

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

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Chaîne de format Description
%%Le signe pourcentage
%aAdresse IP et port clients
%{c}aPort et adresse IP sous-jacents du correspondant pour la + connexion (voir le module + mod_remoteip)
%AAdresse IP et port locaux
%{name}eVariable d'environnement de requête name
%EEtat d'erreur APR/OS et chaîne
%FNom du fichier source et numéro de ligne de l'appel du + journal
%{name}iEn-tête de requête name
%kNombre de requêtes persistantes pour cette connexion
%lSévérité du message
%LIdentifiant journal de la requête
%{c}LIdentifiant journal de la connexion
%{C}LIdentifiant journal de la connexion si utilisé dans la + portée de la connexion, vide sinon
%mNom du module qui effectue la journalisation du message
%MLe message effectif
%{name}nNote de requête name
%PIdentifiant du processus courant
%TIdentifiant du thread courant
%{g}TIdentifiant unique de thread système du thread courant + (l'identifiant affiché par la commande top par + exemple ; seulement sous Linux pour l'instant)
%tL'heure courante
%{u}tL'heure courante avec les microsecondes
%{cu}tL'heure courante au format compact ISO 8601, avec les + microsecondes
%vLe nom de serveur canonique ServerName du serveur courant.
%VLe nom de serveur du serveur qui sert la requête en accord + avec la définition de la directive UseCanonicalName.
(anti-slash espace)Espace non délimiteur
(pourcentage espace)Délimiteur de champ (aucune sortie)
+ +

L'item de format identifiant journal %L génère un + identifiant unique pour une connexion ou une requête. Il peut servir + à déterminer quelles lignes correspondent à la même connexion ou + requête ou quelle requête est associée à tel connexion. Un item de + format %L est aussi disponible dans le module + mod_log_config, mais il permet dans ce contexte de + corréler les entrées du journal des accès avec celles du journal des + erreurs. Si le module mod_unique_id est chargé, + c'est son identifiant unique qui sera utilisé comme identifiant de + journal pour les requêtes.

+ +
# Exemple (format par défaut pour les MPMs threadés)
+ErrorLogFormat "[%{u}t] [%-m:%l] [pid %P:tid %T] %7F: %E: [client\ %a] %M% ,\ referer\ %{Referer}i"
+ + +

Cet exemple renverrait un message d'erreur du style :

+ +

+ [Thu May 12 08:28:57.652118 2011] [core:error] [pid 8777:tid 4326490112] [client ::1:58619] File does not exist: /usr/local/apache2/htdocs/favicon.ico +

+ +

Notez que, comme indiqué plus haut, certains champs sont + totalement supprimés s'ils n'ont pas été définis.

+ +
# Exemple (similaire au format 2.2.x)
+ErrorLogFormat "[%t] [%l] %7F: %E: [client\ %a] %M% ,\ referer\ %{Referer}i"
+ + +
# Exemple avancé avec identifiants journal de requête/connexion
+ErrorLogFormat "[%{uc}t] [%-m:%-l] [R:%L] [C:%{C}L] %7F: %E: %M"
+ErrorLogFormat request "[%{uc}t] [R:%L] Request %k on C:%{c}L pid:%P tid:%T"
+ErrorLogFormat request "[%{uc}t] [R:%L] UA:'%+{User-Agent}i'"
+ErrorLogFormat request "[%{uc}t] [R:%L] Referer:'%+{Referer}i'"
+ErrorLogFormat connection "[%{uc}t] [C:%{c}L] remote\ %a local\ %A"
+ + + +

Voir aussi

+ +
+
top
+

Directive ExtendedStatus

+ + + + + + + +
Description:Extrait des informations d'état étendues pour chaque +requête
Syntaxe:ExtendedStatus On|Off
Défaut:ExtendedStatus Off
Contexte:configuration globale
Statut:Noyau httpd
Module:core
+ +

Cette option permet d'extraire des données supplémentaires + concernant la requête en cours de traitement pour un processus + donné, et crée un résumé d'utilisation ; vous pouvez accéder à + ces variables pendant l'exécution en configurant + mod_status. Notez que d'autres modules sont + susceptibles de s'appuyer sur ce tableau de bord.

+ +

Cette directive s'applique au serveur dans son ensemble, et ne + peut pas être activée/désactivée pour un serveur virtuel + particulier. Notez que l'extraction des informations d'état étendues + peut ralentir le serveur. Notez aussi que cette définition ne peut + pas être modifiée au cours d'un redémarrage graceful.

+ +
+

Notez que le chargement de mod_status définit + automatiquement ExtendedStatus à On, et que d'autres modules tiers + sont susceptibles d'en faire de même. De tels modules ont besoin + d'informations détaillées à propos de l'état de tous les processus. + Depuis la version 2.3.6, mod_status a définit la + valeur par défaut à On, alors qu'elle était à Off dans les versions + antérieures.

+
+ + +
+
top
+

Directive FileETag

+ + + + + + + + + +
Description:Caractéristiques de fichier utilisées lors de la génération +de l'en-tête de réponse HTTP ETag pour les fichiers statiques
Syntaxe:FileETag composant ...
Défaut:FileETag MTime Size
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:FileInfo
Statut:Noyau httpd
Module:core
Compatibilité:La valeur par défaut était "INode MTime Size" +dans les versions 2.3.14 et antérieures.
+

+ La directive FileETag définit les + caractéristiques de fichier utilisées lors de la génération de + l'en-tête de réponse HTTP ETag (entity tag) quand le + document est contenu dans un fichier statique (la valeur de + ETag + est utilisée dans le cadre de la gestion du cache pour préserver la + bande passante réseau). La directive + FileETag vous permet maintenant de choisir + quelles caractéristiques du fichier vont être utilisées, le cas + échéant. Les mots-clés reconnus sont : +

+ +
+
INode
+
Le numéro d'i-node du fichier sera inclus dans le processus de + génération
+
MTime
+
La date et l'heure auxquelles le fichier a été modifié la + dernière fois seront incluses
+
Size
+
La taille du fichier en octets sera incluse
+
All
+
Tous les champs disponibles seront utilisés. Cette définition + est équivalente à : +
FileETag INode MTime Size
+
+
Digest
+
Si un document est à base de fichier, le champ ETag sera + généré à partir du condensé du fichier.
+
None
+
Si le document se compose d'un fichier, aucun champ + ETag ne sera inclus dans la réponse
+
+ +

Les mots-clés INode, MTime, + Size et Digest peuvent être préfixés par + ou + -, ce qui permet de modifier les valeurs par défaut + héritées d'un niveau de configuration plus général. Tout mot-clé + apparaissant sans aucun préfixe annule entièrement et immédiatement + les configurations héritées.

+ +

Si la configuration d'un répertoire contient + FileETag INode MTime Size, et si un de + ses sous-répertoires contient FileETag -INode, la + configuration de ce sous-répertoire (qui sera propagée vers tout + sous-répertoire qui ne la supplante pas), sera équivalente à + FileETag MTime Size.

+

Inclusions côté serveur

+ Aucun champ ETag n'est généré pour les réponses interprétées par + mod_include, car l'entité de la réponse peut + changer sans modification de l'INode, MTime, Size ou Digest du + fichier statique contenant les directives SSI. +
+ + + +
+
top
+

Directive <Files>

+ + + + + + + +
Description:Contient des directives qui s'appliquent aux fichiers +précisés
Syntaxe:<Files nom fichier> ... </Files>
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:All
Statut:Noyau httpd
Module:core
+

La directive <Files> limite + la portée des directives qu'elle contient aux fichiers précisés. + Elle est comparable aux directives <Directory> et <Location>. Elle doit se terminer par une + balise </Files>. Les directives contenues dans + cette section s'appliqueront à tout objet dont le nom de base (la + dernière partie du nom de fichier) correspond au fichier spécifié. + Les sections <Files> sont + traitées selon l'ordre dans lequel elles apparaissent dans le + fichier de configuration, après les sections <Directory> et la lecture des fichiers + .htaccess, mais avant les sections <Location>. Notez que les + sections <Files> peuvent être + imbriquées dans les sections <Directory> afin de restreindre la portion + du système de fichiers à laquelle ces dernières vont + s'appliquer.

+ +

L'argument filename peut contenir un nom de fichier + ou une chaîne de caractères avec caractères génériques, où + ? remplace un caractère, et * toute chaîne + de caractères.

+
<Files "cat.html">
+    # Insérer ici des directives qui s'appliquent au fichier cat.html
+</Files>
+
+<Files "?at.*">
+    # Les directives insérées ici s'appliqueront aux fichiers
+    # cat.html, bat.html, hat.php, et ainsi de suite.
+</Files>
+ + +

On peut aussi utiliser les Expressions rationnelles en ajoutant la + caractère ~. Par exemple :

+ +
<Files ~ "\.(gif|jpe?g|png)$">
+    #...
+</Files>
+ + +

correspondrait à la plupart des formats graphiques de l'Internet. + Il est cependant préférable d'utiliser la directive <FilesMatch>.

+ +

Notez qu'à la différence des sections <Directory> et <Location>, les sections <Files> peuvent être utilisées dans les + fichiers .htaccess. Ceci permet aux utilisateurs de + contrôler l'accès à leurs propres ressources, fichier par + fichier.

+ + +

Voir aussi

+ +
+
top
+

Directive <FilesMatch>

+ + + + + + + +
Description:Contient des directives qui s'appliquent à des fichiers +spécifiés sous la forme d'expressions rationnelles
Syntaxe:<FilesMatch expression rationnelle> ... +</FilesMatch>
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:All
Statut:Noyau httpd
Module:core
+

La section <FilesMatch> + limite la portée des directives qu'elle contient aux fichiers + spécifiés, tout comme le ferait une section <Files>. Mais elle accepte aussi les + expressions rationnelles. Par + exemple :

+ +
<FilesMatch ".+\.(gif|jpe?g|png)$">
+    # ...
+</FilesMatch>
+ + +

correspondrait à la plupart des formats graphiques de + l'Internet.

+ +
Les caractères .+ au début de l'expression + rationnelle permettent de s'assurer que les fichiers de nom + .png, ou .gif, par exemple, ne seront pas + pris en compte.
+ +

A partir de la version 2.4.8, les groupes nommés et les + références arrières sont extraits et enregistrés dans + l'environnement avec leur nom en majuscules et préfixé + par "MATCH_". Ceci permet + de référencer des URLs dans des expressions + ou au sein de modules comme mod_rewrite. Pour + éviter toute confusion, les références arrières numérotées (non + nommées) sont ignorées. Vous devez utiliser à la place des groupes + nommés.

+ +
<FilesMatch "^(?<sitename>[^/]+)">
+    Require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
+</FilesMatch>
+ + + +

Voir aussi

+ +
+
top
+

Directive FlushMaxPipelined

+ + + + + + + + +
Description:Nombre maximal de réponses en attente (pipelined) au-delà duquel +elles sont envoyées sur le réseau
Syntaxe:FlushMaxPipelined number
Défaut:FlushMaxPipelined 5
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
Compatibilité:Disponible à partir de la version 2.4.47 du serveur HTTP Apache
+

Cette directive permet de définir le nombre maximal de réponses + "pipelinées" qui restent en attente tant que des requêtes "pipelinées" sont + reçues. Lorsque cette limite est dépassée, l'envoi des réponses sur le + réseau est forcé en mode bloqué jusqu'à ce que leur nombre repasse en + dessous de la limite.

+ +

La directive FlushMaxPipelined permet de limiter + la consommation de mémoire. Lorsqu'elle est définie à 0, le + pipelining est désactivé, et lorsqu'elle est définie à -1, il n'y + a plus de limite (mais la directive FlushMaxThreshold + s'applique quand-même).

+ +
+
top
+

Directive FlushMaxThreshold

+ + + + + + + + +
Description:Seuil au-delà duquel les données en attente sont envoyées sur le +réseau
Syntaxe:FlushMaxThreshold number-of-bytes
Défaut:FlushMaxThreshold 65536
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
Compatibilité:Disponible à partir de la version 2.4.47 du serveur HTTP Apache
+

Cette directive permet de définir le seuil maximal de données en attente + d'envoi (en octets). Lorsque cette limite est dépassée, l'envoi des données sur le + réseau est forcé en mode bloqué jusqu'à ce que leur quantité repasse en + dessous du seuil spécifié.

+ +

La directive FlushMaxThreshold permet de limiter + la consommation de mémoire. Lorsqu'elle est définie à 0 ou à une + valeur trop petite, aucune donnée n'est mise en attente, mais dans le cas + des MPMs threadés, il peut alors y avoir plus de threads occupés en attente du + réseau, ce qui diminue d'autant le nombre de threads disponibles pour + traiter les autres connexions simultanées.

+ +
+
top
+

Directive ForceType

+ + + + + + + +
Description:Force le type de médium spécifié dans le champ d'en-tête +HTTP Content-Type pour les fichiers correspondants
Syntaxe:ForceType type médium|None
Contexte:répertoire, .htaccess
Surcharges autorisées:FileInfo
Statut:Noyau httpd
Module:core
+

Lorsqu'elle est placée dans un fichier .htaccess ou + une section <Directory>, <Location>, ou <Files>, cette directive force + l'identification du type MIME des fichiers spécifiés à la valeur de + l'argument type médium. Par exemple, si vous possédez un + répertoire ne contenant que des fichiers GIF, et si vous ne voulez + pas leur ajouter l'extension .gif, vous pouvez utiliser + :

+ +
ForceType image/gif
+ + +

Notez que cette directive l'emporte sur d'autres associations de + type de médium indirectes définies dans mime.types ou via la + directive AddType.

+ +

Vous pouvez aussi annuler toute définition plus générale de + ForceType en affectant la valeur + None à l'argument type médium :

+ +
# force le type MIME de tous les fichiers à image/gif:
+<Location "/images">
+  ForceType image/gif
+</Location>
+
+# mais utilise les méthodes classiques d'attribution du type MIME
+# dans le sous-répertoire suivant :
+<Location "/images/mixed">
+  ForceType None
+</Location>
+ + +

A la base, cette directive écrase le type de contenu généré pour + les fichiers statiques servis à partir du sytème de fichiers. Pour + les ressources autres que les fichiers statiques pour lesquels le + générateur de réponse spécifie en général un type de contenu, cette + directive est ignorée.

+ +

Note

+

Lorsque des directives explicites comme SetHandler ou + module="mod_mime">AddHandler ne s'appliquent + pas à la requête courante, le nom du gestionnaire interne + normalement défini par ces directives correspondra alors au type de + contenu spécifié par cette directive. Il s'agit d'un + comportement historique que certains modules + tiers, comme mod_php, peuvent interpréter comme un type de contenu + artificiel ne servant qu'à indiquer le module qui doit prendre en + compte la requête considérée. Dans la mesure du + possible, il est conseillé d'éviter les + configurations qui comportent de tels types artificiels en utilisant + les directives SetHandler ou + AddHandler.

+
+ + +
+
top
+

Directive GprofDir

+ + + + + + +
Description:Répertoire dans lequel écrire les données de profiling +gmon.out.
Syntaxe:GprofDir /tmp/gprof/|/tmp/gprof/%
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
+

Lorsque le serveur a été compilé avec le support du profiling + gprof, la directive GprofDir permet de + spécifier dans quel répertoire les fichiers gmon.out + doivent être écrits lorsque le processus s'arrête. Si l'argument se + termine par un caractère pourcentage ('%'), des sous-répertoires + sont créés pour chaque identifiant de processus.

+ +

Cette directive ne fonctionne actuellement qu'avec le MPM + prefork.

+ +
+
top
+

Directive HostnameLookups

+ + + + + + + +
Description:Active la recherche DNS sur les adresses IP des +clients
Syntaxe:HostnameLookups On|Off|Double
Défaut:HostnameLookups Off
Contexte:configuration globale, serveur virtuel, répertoire
Statut:Noyau httpd
Module:core
+

Cette directive active la recherche DNS afin de pouvoir + journaliser les nom d'hôtes (et les passer aux programmes CGI et aux + inclusions SSI via la variable REMOTE_HOST). La valeur + Double déclenche une double recherche DNS inverse. En + d'autres termes, une fois la recherche inverse effectuée, on lance + une recherche directe sur le résultat de cette dernière. Au moins + une des adresses IP fournies par la recherche directe doit + correspondre à l'adresse originale (ce que l'on nomme + PARANOID dans la terminologie "tcpwrappers").

+ +

Quelle que soit la configuration, lorsqu'on utilise + mod_authz_host pour contrôler l'accès en fonction + du nom d'hôte, une double recherche DNS inverse est effectuée, + sécurité oblige. Notez cependant que le résultat de cette double + recherche n'est en général pas accessible, à moins que vous n'ayez + spécifié HostnameLookups Double. Par exemple, si vous + n'avez spécifié que HostnameLookups On, et si une + requête concerne un objet protégé par des restrictions en fonction + du nom d'hôte, quel que soit le résultat de la double recherche + inverse, les programmes CGI ne recevront que le résultat de la + recherche inverse simple dans la variable + REMOTE_HOST.

+ +

La valeur par défaut est Off afin de préserver le + traffic réseau des sites pour lesquels la recherche inverse n'est + pas vraiment nécessaire. Cette valeur par défaut est aussi bénéfique + pour les utilisateurs finaux car il n'ont ainsi pas à subir de temps + d'attente supplémentaires dus aux recherches DNS. Les sites + fortement chargés devraient laisser cette directive à + Off, car les recherches DNS peuvent prendre des temps + très longs. Vous pouvez éventuellement utiliser hors ligne + l'utilitaire logresolve, compilé par défaut dans + le sous-répertoire bin de votre répertoire + d'installation, afin de déterminer les noms d'hôtes associés aux + adresses IP journalisées.

+ +

Enfin, si vous avez des directives Require à base de + nom, une recherche de nom d'hôte sera effectuée quelle que soit + la définition de la directive HostnameLookups.

+ +
+
top
+

Directive HttpProtocolOptions

+ + + + + + + + +
Description:Modifie les contraintes sur les messages des requêtes HTTP
Syntaxe:HttpProtocolOptions [Strict|Unsafe] [RegisteredMethods|LenientMethods] + [Allow0.9|Require1.0]
Défaut:HttpProtocolOptions Strict LenientMethods Allow0.9
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
Compatibilité:Disponible à partir des versions 2.2.32 et 2.4.24 du serveur HTTP +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 + 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.

+ +

Cette directive accepte trois paramètres issus de la liste suivante, ceux + qui ne sont pas spécifiés prenant leur valeur par défaut :

+ +
+
Strict|Unsafe
+
+

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.

+ +

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

+

Il est fortement déconseillé aux utilisateurs d'utiliser le mode + d'opération Unsafe, ou + UnsafeWhitespace, 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é.

+
+ +

Exemple de requête provoquant l'envoi d'un message HTTP 400 en + mode Strict

+ + # Missing CRLF
+ GET / HTTP/1.0\n\n +

+

Utilitaires en ligne de commande et CRLF

+

Il peut s'avérer nécessaire de forcer certains utilitaires à utiliser + CRLF ; si ce n'est pas le cas, httpd reverra une réponse HTTP 400 comme + dans le cas précédent. Par exemple, le client OpenSSL s_client + doit utiliser le paramètre -crlf pour fonctionner correctement.

+

Pour détecter des problèmes tels que l'absence de CRLF, vous pouvez + utiliser la directive DumpIOInput qui permet de décortiquer + les requêtes HTTP.

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

+ +

Compatibilité avec le mandat direct

+

L'option + RegisteredMethods ne doit pas être utilisée + pour les serveurs mandataires car ces derniers ne connaissent pas les + méthodes supportées par les serveurs originaux.

+
+ +

Exemple de requête provoquant l'envoi d'un message HTTP 501 en + mode LenientMethods

+ + # Méthode HTTP inconnue
+ WOW / HTTP/1.0\r\n\r\n

+ # Méthode HTTP spécifiée en minuscules
+ get / HTTP/1.0\r\n\r\n
+

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

+ +

Exemple de requête provoquant l'envoi d'un message HTTP 400 en + mode Require1.0

+ + # Version HTTP non supportée
+ GET /\r\n\r\n +

+
+
+ +

La consultation des messages enregistrés dans le journal + ErrorLog, configuré via la directive + LogLevel avec un niveau info, 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.

+ +
+
top
+

Directive <If>

+ + + + + + + + +
Description:Contient des directives qui ne s'appliquent que si une +condition est satisfaite au cours du traitement d'une +requête
Syntaxe:<If expression> ... </If>
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:All
Statut:Noyau httpd
Module:core
Compatibilité:Les conditions imbriquées sont supportées à partir de la version +2.4.26 du serveur HTTP Apache
+

La directive <If> évalue une + expression à la volée, et applique les directives qu'elle contient + si et seulement si l'expression renvoie la valeur "vrai". Par + exemple :

+ +
<If "-z req('Host')">
+ + +

serait satisfaite pour les requêtes HTTP/1.0 sans en-tête + Host:. Les expressions peuvent contenir différents + opérateurs de type shell pour la comparaison de chaînes + (==, !=, <, ...), la + comparaison d'entiers (-eq, -ne, ...), ou + à usages divers (-n, -z, -f, + ...). Les expressions rationnelles sont aussi supportées,

+ +
<If "%{QUERY_STRING} =~ /(delete|commit)=.*?elem/">
+ + +

ainsi que les comparaison de modèles de type shell et de + nombreuses autres opérations. Ces opérations peuvent être effectuées + sur les en-têtes de requêtes (req), les variables + d'environnement (env), et un grand nombre d'autres + propriétés. La documentation complète est disponible dans Les expressions dans le serveur HTTP Apache.

+ +

Cette section de configuration ne peut contenir que des + directives qui supportent le contexte de répertoire.

+ +
+ Certain variables, such as CONTENT_TYPE and other + response headers, are set after <If> conditions have already + been evaluated, and so will not be available to use in this + directive. +
+ +
+ Les directives qui sont évaluées lors du traitement de la configuration + comme Define, Include et + Error ne peuvent pas être traitées de manière + conditionnelle en les incluant dans une section de configuration <If>. Ces sections font en effet toujours partie de + la configuration, quelle soit la manière dont elles sont évaluées à + l'exécution. +
+ + +

Voir aussi

+ +
+
top
+

Directive <IfDefine>

+ + + + + + + +
Description:Contient des directives qui ne s'appliqueront que si un +test retourne "vrai" au démarrage du serveur
Syntaxe:<IfDefine [!]paramètre> ... + </IfDefine>
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:All
Statut:Noyau httpd
Module:core
+

La section <IfDefine + test>...</IfDefine> permet de + conférer un caractère conditionnel à un ensemble de directives. Les + directives situées à l'intérieur d'une section <IfDefine> ne s'appliquent que si + test est vrai. Si test est faux, tout ce qui + se trouve entre les balises de début et de fin est ignoré.

+ +

test peut se présenter sous deux formes :

+ +
    +
  • nom paramètre
  • + +
  • !nom paramètre
  • +
+ +

Dans le premier cas, les directives situées entre les balises de + début et de fin ne s'appliqueront que si le paramètre nommé nom + paramètre est défini. Le second format inverse le test, et + dans ce cas, les directives ne s'appliqueront que si nom + paramètre n'est pas défini.

+ +

L'argument nom paramètre est une définition qui peut + être effectuée par la ligne de commande + httpd via le paramètre + -Dparamètre au démarrage du serveur, ou via la + directive Define.

+ +

Les sections <IfDefine> + peuvent être imbriquées, ce qui permet d'implémenter un test + multi-paramètres simple. Exemple :

+ +

httpd -DReverseProxy -DUseCache -DMemCache ...

+
<IfDefine ReverseProxy>
+  LoadModule proxy_module   modules/mod_proxy.so
+  LoadModule proxy_http_module   modules/mod_proxy_http.so
+  <IfDefine UseCache>
+    LoadModule cache_module   modules/mod_cache.so
+    <IfDefine MemCache>
+      LoadModule mem_cache_module   modules/mod_mem_cache.so
+    </IfDefine>
+    <IfDefine !MemCache>
+      LoadModule cache_disk_module   modules/mod_cache_disk.so
+    </IfDefine>
+  </IfDefine>
+</IfDefine>
+ + +
+
top
+

Directive <IfDirective>

+ + + + + + + + +
Description:Regroupe des directives dont le traitement est conditionné par la +présence ou l'absence d'une directive particulière
Syntaxe:<IfDirective [!]directive-name> ... + </IfDirective>
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:All
Statut:Noyau httpd
Module:core
Compatibilité:Disponible à partir de la version 2.4.34 du serveur HTTP Apache
+

La section <IfDirective + test>...</IfDirective> permet de regrouper des + directives dont le traitement n'est effectué que si une directive + particulière est présente, autrement dit si l'expression test est + évaluée à true. Si l'expression test est évaluée à false, toutes + les lignes qui se trouvent entre les balises de début et de fin de la + section sont ignorées.

+ +

L'expression test de la section <IfDirective> peut prendre les deux formes + suivantes :

+ +
    +
  • directive-name
  • + +
  • !directive-name
  • +
+ +

Dans le premier cas, les directives qui se situent entre les balises de + début et de fin de la section ne sont traitées que si une directive de nom + directive-name est disponible à cet instant. Dans le second cas, la condition est + inversée, et les directives ne sont traitées que si + directive-name n'est pas disponible.

+ +
Cette section ne doit être utilisée que si vous devez partager le même + fichier de configuration entre plusieurs versions de + httpd, sans tenir compte de la disponibilité de telle ou + telle directive. Dans une configuration standard, il est inutile de placer + les directives dans des sections <IfDirective>.
+ +

Voir aussi

+ +
+
top
+

Directive <IfFile>

+ + + + + + + + +
Description:Regroupe des directives qui ne seront traitées que si un fichier +existe au démarrage
Syntaxe:<IfFile [!]filename> ... + </IfFile>
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:All
Statut:Noyau httpd
Module:core
Compatibilité:Disponible à partir de la version 2.4.34 du serveur HTTP Apache
+

La section <IfFile filename>...</IfFile> + permet de conditionner le traitement de directives à + l'existence d'un fichier sur disque. Ainsi, les directives définies au sein + d'une section <IfFile> ne seront + traitées que si le fichier filename existe. Si le fichier + filename n'existe pas, tout ce qui se trouve entre les marqueurs + start et end sera ignoré. filename peut être un chemin absolu ou + relatif au chemin défini par la directive ServerRoot.

+ +

Le paramètre filename de l'en-tête d'une section <IfFile> peut prendre la même forme que la variable + test de la section <IfDefine> ; à ce titre, le résultat du test peut + être inversé en plaçant le caractère ! juste avant + filename. +

+ +

Si filename est un chemin relatif, il sera généré par rapport + au chemin défini par la directive ServerRoot. Lorsque la directive <IfFile> intervient avant la définition de la + directive ServerRoot, + filename 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 + -d.

+ +

Avertissement

+ Avec la version 2.4.34, il est interdit de spécifier un filename + entouré de guillemets. Ceci provoquerait une erreur de syntaxe au démarrage. + Il est donc impossible de spécifier des noms de fichiers contenant des + espaces, mais ce défaut a été corrigé à partir de la version 2.4.35.
+ + +
+
top
+

Directive <IfModule>

+ + + + + + + + +
Description:Contient des directives qui ne s'appliquent qu'en fonction +de la présence ou de l'absence d'un module spécifique
Syntaxe:<IfModule [!]fichier module|identificateur +module> ... </IfModule>
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:All
Statut:Noyau httpd
Module:core
Compatibilité:Les identificateurs de modules sont disponibles dans les +versions 2.1 et supérieures.
+

La section <IfModule + test>...</IfModule> permet de conférer à + des directives un caractère conditionnel basé sur la présence d'un + module spécifique. Les directives situées dans une section + <IfModule> ne s'appliquent que + si test est vrai. Si test est faux, tout ce + qui se trouve entre les balises de début et de fin est ignoré.

+ +

test peut se présenter sous deux formes :

+ +
    +
  • module
  • + +
  • !module
  • +
+ +

Dans le premier cas, les directives situées entre les balises de + début et de fin ne s'appliquent que si le module module + est présent -- soit compilé avec le binaire Apache httpd, soit chargé + dynamiquement via la directive LoadModule. Le second format inverse le test, et dans + ce cas, les directives ne s'appliquent que si module + n'est pas présent.

+ +

L'argument module peut contenir soit l'identificateur + du module, soit le nom du fichier source du module. Par exemple, + rewrite_module est un identificateur et + mod_rewrite.c le nom du fichier source + correspondant. Si un module comporte plusieurs fichiers sources, + utilisez le nom du fichier qui contient la chaîne de caractères + STANDARD20_MODULE_STUFF.

+ +

Les sections <IfModule> + peuvent être imbriquées, ce qui permet d'implémenter des tests + multi-modules simples.

+ +
Cette section ne doit être utilisée que si votre fichier de + configuration ne fonctionne qu'en fonction de la présence ou de + l'absence d'un module spécifique. D'une manière générale, il n'est + pas nécessaire de placer les directives à l'intérieur de sections + <IfModule>.
+ +
+
top
+

Directive <IfSection>

+ + + + + + + + +
Description:Regroupe des directives dont le traitement est conditionné par la +présence ou l'absence d'une section particulière
Syntaxe:<IfSection [!]section-name> ... + </IfSection>
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:All
Statut:Noyau httpd
Module:core
Compatibilité:Disponible à partir de la version 2.4.34 du serveur HTTP Apache
+

La section <IfSection + test>...</IfSection> permet de regrouper des + directives dont le traitement n'est effectué que si une section de + configuration particulière est présente. Une section, par exemple <VirtualHost>, permet de regrouper des directives + et possède un nom précédé du caractère "<".

+ +

Les directives situées à l'intérieur d'une section <IfSection> ne sont traitées que si l'expression + test est évaluée à true. Si l'expression test est + évaluée à false, toutes les lignes situées entre les balises de début et de + fin de la section sont ignorées.

+ +

section-name doit être spécifié sans les caractères de début + "<" ou fin ">". L'expression test de la section <IfSection> peut prendre deux formes :

+ +
    +
  • section-name
  • +
  • !section-name
  • +
+ +

Dans le premier cas, les directives qui se situent entre les balises de + début et de fin de la section ne sont traitées que si une section de nom + section-name est disponible à cet instant. Dans le second cas, la condition est + inversée, et les directives ne sont traitées que si + section-name n'est pas disponible.

+ +

Par exemple :

+ +
<IfSection VirtualHost>
+   ...
+</IfSection>
+ + +
Cette section ne doit être utilisée que si vous devez partager le même + fichier de configuration entre plusieurs versions de + httpd, sans tenir compte de la disponibilité de telle ou + telle section. Dans une configuration standard, il est inutile de placer + les directives dans des sections <IfSection>.
+ +

Voir aussi

+ +
+
top
+

Directive Include

+ + + + + + + +
Description:Inclut d'autres fichiers de configuration dans un des +fichiers de configuration du serveur
Syntaxe:Include chemin-fichier|chemin-répertoire|wildcard
Contexte:configuration globale, serveur virtuel, répertoire
Statut:Noyau httpd
Module:core
Compatibilité:Utilisation des caractères génériques dans la partie chemin depuis la +version 2.3.6
+

Cette directive permet l'inclusion d'autres fichiers de + configuration dans un des fichiers de configuration du serveur.

+ +

On peut utiliser des caractères génériques de style Shell + (fnmatch()) aussi bien dans la partie nom de fichier du + chemin que dans la partie répertoires pour inclure plusieurs + fichiers en une + seule fois, selon leur ordre alphabétique. De plus, si la directive + Include pointe vers un répertoire, Apache + httpd inclura tous les fichiers de ce répertoire et de tous ces + sous-répertoires. L'inclusion de répertoires entiers est cependant + déconseillée, car il est fréquent d'oublier des fichiers + temporaires dans un répertoire, ce qui causerait une erreur + httpd en cas d'inclusion. Pour inclure des + fichiers qui correspondent à un certain modèle, comme *.conf par + exemple, nous vous recommandons d'utiliser plutôt la syntaxe avec + caractères génériques comme ci-dessous.

+ +

La directive Include + échouera avec un code d'erreur si une expression + contenant des caractères génériques ne correspond à aucun fichier. + Pour ignorer les expressions contenant des caractères génériques ne + correspondant à aucun fichier, utilisez la directive IncludeOptional.

+ +

Le chemin fichier spécifié peut être soit un chemin absolu, soit + un chemin relatif au répertoire défini par la directive ServerRoot.

+ +

Exemples :

+ +
Include /usr/local/apache2/conf/ssl.conf
+Include /usr/local/apache2/conf/vhosts/*.conf
+ + +

ou encore, avec des chemins relatifs au répertoire défini par la + directive ServerRoot :

+ +
Include conf/ssl.conf
+Include conf/vhosts/*.conf
+ + +

On peut aussi insérer des caractères génériques dans la partie + répertoires du chemin. Dans l'exemple suivant, la directive + échouera si aucun sous-répertoire de conf/vhosts ne contient au + moins un fichier *.conf :

+ +
Include conf/vhosts/*/*.conf
+ + +

Par contre, dans l'exemple suivant, la directive sera simplement + ignorée si aucun sous-répertoire de conf/vhosts ne contient au + moins un fichier *.conf :

+ +
IncludeOptional conf/vhosts/*/*.conf
+ + + +

Voir aussi

+ +
+
top
+

Directive IncludeOptional

+ + + + + + + +
Description:Inclusion de fichiers dans le fichier de configuration
Syntaxe:IncludeOptional +file-path|directory-path|wildcard
Contexte:configuration globale, serveur virtuel, répertoire
Statut:Noyau httpd
Module:core
Compatibilité:Disponible à partir de la version 2.3.6 du serveur HTTP +Apache. Après la version 2.4.30, les chemins de fichiers non existants et +ne comportant pas de caractères génériques ne génèrent plus d'erreurs de syntaxe
+

Cette directive permet d'inclure des fichiers dans les fichiers + de configuration du serveur. Elle fonctionne de manière identique à + la directive Include, mais au lieu de + générer une erreur, elle sera ignorée silensieusement si malgré + l'utilisation de caractères génériques, le chemin de fichier ou de + répertoire spécifié n'existe pas dans le système de fichiers.

+ + +

Voir aussi

+ +
+
top
+

Directive KeepAlive

+ + + + + + + +
Description:Active les connexions HTTP persistantes
Syntaxe:KeepAlive On|Off
Défaut:KeepAlive On
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
+

L'extension Keep-Alive de HTTP/1.0 et l'implémentation des + connexions persistantes dans HTTP/1.1 ont rendu possibles des + sessions HTTP de longue durée, ce qui permet de transmettre + plusieurs requêtes via la même connexion TCP. Dans certains cas, le + gain en rapidité pour des documents comportant de nombreuses images + peut atteindre 50%. Pour activer les connexions persistantes, + définissez KeepAlive On.

+ +

Pour les clients HTTP/1.0, les connexions persistantes ne seront + mises en oeuvre que si elles ont été spécialement demandées par un + client. De plus, une connexion persistante avec un client HTTP/1.0 + ne peut être utilisée que si la taille du contenu est connue + d'avance. Ceci implique que les contenus dynamiques comme les + sorties CGI, les pages SSI, et les listings de répertoires générés + par le serveur n'utiliseront en général pas les connexions + persistantes avec les clients HTTP/1.0. Avec les clients HTTP/1.1, + les connexions persistantes sont utilisées par défaut, sauf + instructions contraires. Si le client le demande, le transfert par + tronçons de taille fixe (chunked encoding) sera utilisé afin de + transmettre un contenu de longueur inconnue via une connexion + persistante.

+ +

Lorsqu'un client utilise une connexion persistante, elle comptera + pour une seule requête pour la directive MaxConnectionsPerChild, quel + que soit le nombre de requêtes transmises via cette connexion.

+ +

Voir aussi

+ +
+
top
+

Directive KeepAliveTimeout

+ + + + + + + +
Description:Durée pendant laquelle le serveur va attendre une requête +avant de fermer une connexion persistante
Syntaxe:KeepAliveTimeout nombre[ms]
Défaut:KeepAliveTimeout 5
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
+

Le nombre de secondes pendant lesquelles Apache httpd va attendre une + requête avant de fermer la connexion. Le délai peut être défini en + millisecondes en suffixant sa valeur par ms. La valeur du délai + spécifiée par la directive Timeout s'applique dès qu'une requête a + été reçue.

+ +

Donner une valeur trop élévée à + KeepAliveTimeout peut induire des problèmes + de performances sur les serveurs fortement chargés. Plus le délai + est élévé, plus nombreux seront les processus serveur en attente de + requêtes de la part de clients inactifs.

+ +

Si la directive KeepAliveTimeout n'est + pas définie pour un serveur virtuel à base de nom, c'est + la valeur de la paire adresse IP/port du serveur virtuel qui + correspond le mieux qui sera utilisée.

+ +
+
top
+

Directive <Limit>

+ + + + + + + +
Description:Limite les contrôles d'accès que la section contient à +certaines méthodes HTTP
Syntaxe:<Limit méthode [méthode] ... > ... + </Limit>
Contexte:répertoire, .htaccess
Surcharges autorisées:AuthConfig, Limit
Statut:Noyau httpd
Module:core
+

Les contrôles d'accès s'appliquent normalement à + toutes les méthodes d'accès, et c'est en général le + comportement souhaité. Dans le cas général, les directives + de contrôle d'accès n'ont pas à être placées dans une section + <Limit>.

+ +

La directive <Limit> a pour + but de limiter les effets des contrôles d'accès aux méthodes HTTP + spécifiées. Pour toutes les autres méthodes, les restrictions + d'accès contenues dans la section <Limit> n'auront aucun + effet. L'exemple suivant n'applique les contrôles d'accès + qu'aux méthodes POST, PUT, et + DELETE, en laissant les autres méthodes sans protection + :

+ +
<Limit POST PUT DELETE>
+  Require valid-user
+</Limit>
+ + +

La liste des noms de méthodes peut contenir une ou plusieurs + valeurs parmi les suivantes : GET, POST, + PUT, DELETE, CONNECT, + OPTIONS, PATCH, PROPFIND, + PROPPATCH, MKCOL, COPY, + MOVE, LOCK, et UNLOCK. + Le nom de méthode est sensible à la casse. Si la + valeur GET est présente, les requêtes HEAD + seront aussi concernées. La méthode TRACE ne peut pas + être limitée (voir la directive TraceEnable).

+ +
Une section <LimitExcept> doit toujours être préférée à + une section <Limit> pour la + restriction d'accès, car une section <LimitExcept> fournit une protection contre + les méthodes arbitraires.
+ +

Les directives <Limit> et + <LimitExcept> + peuvent être imbriquées. Dans ce cas, pour chaque niveau des + directives <Limit> ou <LimitExcept>, ces dernières + doivent restreindre l'accès pour les méthodes auxquelles les + contrôles d'accès s'appliquent.

+ +
Lorsqu'on utilise les directives <Limit> ou <LimitExcept> avec la directive Require, la première directive + Require dont la + condition est satisfaite autorise la requête, sans tenir compte de + la présence d'autres directives Require.
+ +

Par exemple, avec la configuration suivante, tous les + utilisateurs seront autorisés à effectuer des requêtes + POST, et la directive Require group + editors sera ignorée dans tous les cas :

+ +
<LimitExcept GET>
+  Require valid-user
+</LimitExcept>
+<Limit POST>
+  Require group editors
+</Limit>
+ + +
+
top
+

Directive <LimitExcept>

+ + + + + + + +
Description:Applique les contrôles d'accès à toutes les méthodes HTTP, +sauf celles qui sont spécifiées
Syntaxe:<LimitExcept méthode [méthode] ... > ... + </LimitExcept>
Contexte:répertoire, .htaccess
Surcharges autorisées:AuthConfig, Limit
Statut:Noyau httpd
Module:core
+

<LimitExcept> et + </LimitExcept> permettent de regrouper des + directives de contrôle d'accès qui s'appliqueront à toutes les + méthodes d'accès HTTP qui ne font pas partie de la + liste des arguments ; en d'autres termes, elles ont un comportement + opposé à celui de la section <Limit>, et on peut les utiliser pour + contrôler aussi bien les méthodes standards que les méthodes non + standards ou non reconnues. Voir la documentation de la section + <Limit> pour plus + de détails.

+ +

Par exemple :

+ +
<LimitExcept POST GET>
+  Require valid-user
+</LimitExcept>
+ + + +
+
top
+

Directive LimitInternalRecursion

+ + + + + + + +
Description:Détermine le nombre maximal de redirections internes et de +sous-requêtes imbriquées
Syntaxe:LimitInternalRecursion nombre [nombre]
Défaut:LimitInternalRecursion 10
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
+

Une redirection interne survient, par exemple, quand on utilise + la directive Action qui + redirige en interne la requête d'origine vers un script CGI. Une + sous-requête est le mécanisme qu'utilise Apache httpd pour déterminer ce + qui se passerait pour un URI s'il faisait l'objet d'une requête. Par + exemple, mod_dir utilise les sous-requêtes pour + rechercher les fichiers listés dans la directive DirectoryIndex.

+ +

La directive LimitInternalRecursion permet + d'éviter un crash du serveur dû à un bouclage infini de redirections + internes ou de sous-requêtes. De tels bouclages sont dus en général + à des erreurs de configuration.

+ +

La directive accepte, comme arguments, deux limites qui sont + évaluées à chaque requête. Le premier nombre est le + nombre maximum de redirections internes qui peuvent se succéder. Le + second nombre détermine la profondeur d'imbrication + maximum des sous-requêtes. Si vous ne spécifiez qu'un seul + nombre, il sera affecté aux deux limites.

+ +
LimitInternalRecursion 5
+ + +
+
top
+

Directive LimitRequestBody

+ + + + + + + + + +
Description:limite la taille maximale du corps de la requête HTTP +envoyée par le client
Syntaxe:LimitRequestBody octets
Défaut:LimitRequestBody 1073741824
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:All
Statut:Noyau httpd
Module:core
Compatibilité:Dans les versions 2.4.53 et antérieures du serveur HTTP Apache, +la valeur par défaut était 0 (aucune limite)
+

Cette directive permet de spécifier la taille maximale d'un corps de + requête, en octets. Une valeur de 0 signifie « sans + limites ».

+ +

La directive LimitRequestBody permet de + définir une limite pour la taille maximale autorisée du corps d'une + requête HTTP en tenant compte du contexte dans lequel la directive + a été placée (c'est à dire au niveau du serveur, d'un répertoire, + d'un fichier ou d'une localisation). Si la requête du client dépasse + cette limite, le serveur répondra par un message d'erreur et ne + traitera pas la requête. La taille du corps d'une requête normale va + varier de manière importante en fonction de la nature de la + ressource et des méthodes autorisées pour cette dernière. Les + scripts CGI utilisent souvent le corps du message pour extraire les + informations d'un formulaire. Les implémentations de la méthode + PUT nécessitent une valeur au moins aussi élevée que la + taille maximale des représentations que le serveur désire accepter + pour cette ressource.

+ +

L'administrateur du serveur peut utiliser cette directive pour + contrôler plus efficacement les comportements anormaux des requêtes + des clients, ce qui lui permettra de prévenir certaines formes + d'attaques par déni de service.

+ +

Si par exemple, vous autorisez le chargement de fichiers vers une + localisation particulière, et souhaitez limiter la taille des + fichiers chargés à 100Ko, vous pouvez utiliser la directive suivante + :

+ +
LimitRequestBody 102400
+ + + +
+
top
+

Directive LimitRequestFields

+ + + + + + + +
Description:Limite le nombre de champs d'en-tête autorisés dans une +requête HTTP
Syntaxe:LimitRequestFields nombre
Défaut:LimitRequestFields 100
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
+

nombre est un entier de 0 à 32767. La valeur 0 signifie un + nombre de champs illimité. La valeur par défaut est définie à la compilation + par la constante DEFAULT_LIMIT_REQUEST_FIELDS (100 selon la + distribution).

+ +

La directive LimitRequestFields permet à + l'administrateur du serveur de modifier le nombre maximum de champs + d'en-tête autorisés dans une requête HTTP. Pour un serveur, cette + valeur doit être supérieure au nombre de champs qu'une requête + client normale peut contenir. Le nombre de champs d'en-tête d'une + requête qu'un client utilise dépasse rarement 20, mais ce nombre + peut varier selon les implémentations des clients, et souvent en + fonction des extensions que les utilisateurs configurent dans leurs + navigateurs pour supporter la négociation de contenu détaillée. Les + extensions HTTP optionnelles utilisent souvent les + champs d'en-tête des requêtes.

+ +

L'administrateur du serveur peut utiliser cette directive pour + contrôler plus efficacement les comportements anormaux des requêtes + des clients, ce qui lui permettra de prévenir certaines formes + d'attaques par déni de service. La valeur spécifiée doit être + augmentée si les clients standards reçoivent une erreur du serveur + indiquant que la requête comportait un nombre d'en-têtes trop + important.

+ +

Par exemple :

+ +
LimitRequestFields 50
+ + +

Avertissement

+

Dans le cas des serveurs virtuels à base de noms, la valeur de + cette directive est extraite du serveur virtuel par défaut (le + premier de la liste) pour la paire adresse IP/port.

+
+ + +
+
top
+

Directive LimitRequestFieldSize

+ + + + + + + +
Description:Dédinit la taille maximale autorisée d'un en-tête de +requête HTTP
Syntaxe:LimitRequestFieldSize octets
Défaut:LimitRequestFieldSize 8190
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
+

Cette directive permet de définir le nombre maximum + d'octets autorisés dans un en-tête de requête HTTP.

+ +

La directive LimitRequestFieldSize permet + à l'administrateur du serveur de définir la taille + maximale autorisée d'un en-tête de requête HTTP. Pour un serveur, + cette valeur doit être suffisamment grande pour contenir tout + en-tête d'une requête client normale. La taille d'un champ d'en-tête + de requête normal va varier selon les implémentations des clients, + et en fonction des extensions que les utilisateurs + configurent dans leurs navigateurs pour supporter la négociation de + contenu détaillée. Les en-têtes d'authentification SPNEGO peuvent + atteindre une taille de 12392 octets.

+ +

L'administrateur du serveur peut utiliser cette directive pour + contrôler plus efficacement les comportements anormaux des requêtes + des clients, ce qui lui permettra de prévenir certaines formes + d'attaques par déni de service.

+ +

Par exemple :

+ +
LimitRequestFieldSize 4094
+ + +
Dans des conditions normales, la valeur par défaut de cette + directive ne doit pas être modifiée.
+ +

Avertissement

+

Dans le cas des serveurs virtuels à base de noms, la valeur de + cette directive est extraite du serveur virtuel par défaut (le + premier de la liste) pour lequel la paire adresse IP/port + correspond le mieux.

+
+ +
+
top
+

Directive LimitRequestLine

+ + + + + + + +
Description:Définit la taille maximale d'une ligne de requête +HTTP
Syntaxe:LimitRequestLine octets
Défaut:LimitRequestLine 8190
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
+

Cette directive permet de définir la taille maximale autorisée + pour une ligne de requête HTTP en octets.

+ +

La directive LimitRequestLine permet à + l'administrateur du serveur de définir la taille + maximale autorisée d'une ligne de requête HTTP client. Comme une + requête comporte une méthode HTTP, un URI, et une version de + protocole, la directive LimitRequestLine + impose une restriction sur la longueur maximale autorisée pour un + URI dans une requête au niveau du serveur. Pour un serveur, cette + valeur doit être suffisamment grande pour référencer les noms de + toutes ses ressources, y compris toutes informations pouvant être + ajoutées dans la partie requête d'une méthode GET.

+ +

L'administrateur du serveur peut utiliser cette directive pour + contrôler plus efficacement les comportements anormaux des requêtes + des clients, ce qui lui permettra de prévenir certaines formes + d'attaques par déni de service.

+ +

Par exemple :

+ +
LimitRequestLine 4094
+ + +
Dans des conditions normales, cette directive doit conserver + sa valeur par défaut.
+ +

Avertissement

+

Dans le cas des serveurs virtuels à base de noms, la valeur de + cette directive est extraite du serveur virtuel par défaut (le + premier de la liste) pour lequel la paire adresse IP/port + correspond le mieux.

+
+ + +
+
top
+

Directive LimitXMLRequestBody

+ + + + + + + + +
Description:Définit la taille maximale du corps d'une requête au format +XML
Syntaxe:LimitXMLRequestBody octets
Défaut:LimitXMLRequestBody 1000000
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:All
Statut:Noyau httpd
Module:core
+

Taille maximale (en octets) du corps d'une requête au format XML. Une + valeur de 0 appliquera une limite physique (différente selon + que le système est sur 32 ou 64 bits) permettant à XML de s'étaler jusqu'aux + limites de la mémoire adressable du système, mais elle n'existe qu'à des + fins de compatibilité et il est déconseillé de l'utiliser car elle ne tient + pas compte de la mémoire consommée ailleurs et des requêtes simultanées, ce + qui pourrait provoquer un dépassement de mémoire global du système. +

+ +

Exemple :

+ +
# Limitation à 1 Mo
+LimitXMLRequestBody 1073741824
+ + + +
+
top
+

Directive <Location>

+ + + + + + +
Description:N'applique les directives contenues qu'aux URLs +spécifiées
Syntaxe:<Location + chemin URL|URL> ... </Location>
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
+

La directive <Location> + limite la portée des directives contenues aux URLs définies par + l'argument URL. Elle est similaire à la directive <Directory>, et marque le + début d'une section qui se termine par une directive + </Location>. Les sections <Location> sont traitées selon l'ordre dans + lequel elles apparaissent dans le fichier de configuration, mais + après les sections <Directory> et la lecture des + fichiers .htaccess, et après les sections <Files>.

+ +

Les sections <Location> + agissent complètement en dehors du système de fichiers. Ceci a de + nombreuses conséquences. Parmi les plus importantes, on ne doit pas + utiliser les sections <Location> + pour contrôler l'accès aux répertoires du système de fichiers. Comme + plusieurs URLs peuvent correspondre au même répertoire du système de + fichiers, un tel contrôle d'accès pourrait être contourné.

+ +

Les directives que contient cette section seront appliquées aux + requêtes si la partie chemin de l'URL satisfait à l'un au moins de + ces critères : +

+
    +
  • Le chemin spécifié correspond exactement à la partie chemin de + l'URL. +
  • +
  • Le chemin spécifié, qui se termine par un slash, est un + préfixe de la partie chemin de l'URL (traité comme une racine du + contexte). +
  • +
  • Le chemin spécifié, si on lui ajoute un slash de fin, est un + préfixe de la partie chemin de l'URL (aussi traité comme une racine du + contexte). +
  • +
+

+ Dans l'exemple ci-dessous, où aucun slash de fin n'est utilisé, les + directives contenues dans la section s'appliqueront à /private1, + /private1/ et /private1/file.txt, mais pas à /private1other. +

+
<Location "/private1">
+    #  ...
+</Location>
+ +

+ De même, dans l'exemple ci-dessous, où l'on utilise un slash de fin, les + directives contenues dans la section s'appliqueront à /private2/ et + à /private2/file.txt, mais pas à /private2other. +

+
<Location "/private2/">
+    # ...
+</Location>
+ + +

Quand utiliser la section <Location>

+ +

Vous pouvez utiliser une section <Location> pour appliquer des directives à + des contenus situés en dehors du système de fichiers. Pour les + contenus situés à l'intérieur du système de fichiers, utilisez + plutôt les sections <Directory> et <Files>. <Location + "/"> constitue une exception et permet d'appliquer aisément + une configuration à l'ensemble du serveur.

+
+ +

Pour toutes les requêtes originales (non mandatées), l'argument + 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 + protocole://nom_serveur/chemin, et vous devez inclure + le préfixe.

+ +

L'URL peut contenir des caractères génériques. Dans une chaîne + avec caractères génériques, ? correspond à un caractère + quelconque, et * à toute chaîne de caractères. Les + caractères génériques ne peuvent pas remplacer un / dans le chemin + URL.

+ +

On peut aussi utiliser les Expressions + rationnelles, moyennant l'addition d'un caractère + ~. Par exemple :

+ +
<Location ~ "/(extra|special)/data">
+    #...
+</Location>
+ + +

concernerait les URLs contenant les sous-chaîne + /extra/data ou /special/data. La directive + <LocationMatch> + présente un comportement identique à la version avec expressions + rationnelles de la directive <Location>, et son utilisation est + préférable à l'utilisation de cette dernière pour la simple raison + qu'il est difficile de distinguer ~ de - + dans la plupart des fontes.

+ +

La directive <Location> + s'utilise principalement avec la directive SetHandler. Par exemple, pour activer les + requêtes d'état, mais ne les autoriser que depuis des navigateurs + appartenant au domaine example.com, vous pouvez + utiliser :

+ +
<Location "/status">
+  SetHandler server-status
+  Require host example.com
+</Location>
+ + +

Note à propos du slash (/)

La signification du + caractère slash dépend de l'endroit où il se trouve dans l'URL. Les + utilisateurs peuvent être habitués à son comportement dans le système de + fichiers où plusieurs slashes successifs sont souvent réduits à un slash + unique (en d'autres termes, /home///foo est identique à + /home/foo). Dans l'espace de nommage des URLs, ce n'est + cependant pas toujours vrai si la directive MergeSlashes a été définie à "OFF". Pour la + directive <LocationMatch> + et la version avec expressions rationnelles de la directive <Location>, vous devez spécifier explicitement les + slashes multiples si les slashes ne sont pas fusionnés.

+ +

Par exemple, <LocationMatch "^/abc"> va + correspondre à l'URL /abc mais pas à l'URL + //abc. La directive <Location> sans expression rationnelle se comporte de + la même manière lorsqu'elle est utilisée pour des requêtes + mandatées. Par contre, lorsque la directive <Location> sans expression rationnelle + est utilisée pour des requêtes non mandatées, elle fera + correspondre implicitement les slashes multiples à des slashes + uniques. Par exemple, si vous spécifiez <Location + "/abc/def">, une requête de la forme + /abc//def correspondra.

+
+ +

Voir aussi

+ +
+
top
+

Directive <LocationMatch>

+ + + + + + +
Description:N'applique les directives contenues qu'aux URLs +correspondant à une expression rationnelle
Syntaxe:<LocationMatch + regex> ... </LocationMatch>
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
+

La directive <LocationMatch> + limite la portée des directives contenues à l'URL spécifiée, de + manière identique à la directive <Location>. Mais son argument permettant de + spécifier les URLs concernées est une expression rationnelle au lieu d'une simple + chaîne de caractères. Par exemple :

+ +
<LocationMatch "/(extra|special)/data">
+    # ...
+</LocationMatch>
+ + +

correspondrait à toute URL contenant les sous-chaînes + /extra/data ou /special/data.

+ +

Si vous recherchez une URL commençant par + plutôt que seulement contenant /extra/data, préfixez + l'expression rationnelle avec un ^.

+ +
<LocationMatch "^/(extra|special)/data">
+ +
+ +

A partir de la version 2.4.8, les groupes nommés et les + références arrières sont extraits et enregistrés dans + l'environnement avec leur nom en majuscules et préfixé + par "MATCH_". Ceci permet + de référencer des URLs dans des expressions + ou au sein de modules comme mod_rewrite. Pour + éviter toute confusion, les références arrières numérotées (non + nommées) sont ignorées. Vous devez utiliser à la place des groupes + nommés.

+ +
<LocationMatch "^/combined/(?<sitename>[^/]+)">
+    Require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
+</LocationMatch>
+ + +

Note à propos du slash '/'

La signification du + caractère slash '/' dépend de l'endroit où il apparaît dans une URL. Les + utilisateurs sont habitués à voir de multiples slashes adjacents réduits à + un seul au sein du système de fichiers (par exemple, + /home///foo est équivalent à /home/foo). Ce n'est + n'est cependant pas toujours vrai au sein des URLs si la directive + MergeSlashes a été définie à "OFF". En + effet, si vous souhaitez spécifier plusieurs slashes, vous devez le faire + explicitement au sein de la directive <LocationMatch> et de la version regex de la + directive <Location>, si les slashes ne + sont pas fusionnés.

+ +

Par exemple, <LocationMatch "^/abc"> correspondra à + l'URL /abc, mais pas à l'URL //abc. La directive + (non-regex) <Location> se comporte de + la même manière lorsqu'elle est utilisée dans les requêtes de mandataire. + Par contre, pour les autres types de requêtes, la directive <Location> considérera plusieurs slashes + adjacents comme équivalents à un seul slash. Par exemple, si vous + spécifiez <Location "/abc/def">, une requête pour + /abc//def correspondra.

+
+ +

Voir aussi

+ +
+
top
+

Directive LogLevel

+ + + + + + + + +
Description:Contrôle la verbosité du journal des erreurs
Syntaxe:LogLevel [module:]niveau + [module:niveau] ... +
Défaut:LogLevel warn
Contexte:configuration globale, serveur virtuel, répertoire
Statut:Noyau httpd
Module:core
Compatibilité:La configuration du niveau de journalisation par module +et par répertoire est disponible depuis la version 2.3.6 du serveur HTTP +Apache
+

La directive LogLevel permet d'ajuster la + verbosité des messages enregistrés dans les journaux d'erreur (voir + la directive ErrorLog + directive). Les niveaux disponibles sont présentés + ci-après, par ordre de criticité décroissante :

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Niveau Description Exemple
emerg Urgences - le système est inutilisable."Child cannot open lock file. Exiting"
alert Des mesures doivent être prises immédiatement."getpwuid: couldn't determine user name from uid"
crit Conditions critiques."socket: Failed to get a socket, exiting child"
error Erreurs."Premature end of script headers"
warn Avertissements."child process 1234 did not exit, sending another + SIGHUP"
notice Evènement important mais normal."httpd: caught SIGBUS, attempting to dump core in + ..."
info Informations."Server seems busy, (you may need to increase + StartServers, or Min/MaxSpareServers)..."
debug Messages de débogage."Opening config file ..."
trace1 Messages de traces"proxy: FTP: control connection complete"
trace2 Messages de traces"proxy: CONNECT: sending the CONNECT request to the remote proxy"
trace3 Messages de traces"openssl: Handshake: start"
trace4 Messages de traces"read from buffered SSL brigade, mode 0, 17 bytes"
trace5 Messages de traces"map lookup FAILED: map=rewritemap key=keyname"
trace6 Messages de traces"cache lookup FAILED, forcing new map lookup"
trace7 Messages de traces, enregistrement d'une grande quantité de + données"| 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"
trace8 Messages de traces, enregistrement d'une grande quantité de + données"| 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"
+ +

Lorsqu'un niveau particulier est spécifié, les messages de tous + les autres niveaux de criticité supérieure seront aussi enregistrés. + Par exemple, si LogLevel info est spécifié, + les messages de niveaux notice et warn + seront aussi émis.

+ +

Il est recommandé d'utiliser un niveau crit ou + inférieur.

+ +

Par exemple :

+ +
LogLevel notice
+ + +

Note

+

Si la journalisation s'effectue directement dans un fichier, + les messages de niveau notice ne peuvent pas être + supprimés et sont donc toujours journalisés. Cependant, ceci ne + s'applique pas lorsque la journalisation s'effectue vers + syslog.

+
+ +

Spécifier un niveau sans nom de module va attribuer ce niveau à + tous les modules. Spécifier un niveau avec nom de module va + attribuer ce niveau à ce module seulement. Il est possible de + spécifier un module par le nom de son fichier source ou par son + identificateur, avec ou sans le suffixe _module. Les + trois spécifications suivantes sont donc équivalentes :

+ +
LogLevel info ssl:warn
+LogLevel info mod_ssl.c:warn
+LogLevel info ssl_module:warn
+ + +

Il est aussi possible d'attribuer un niveau de journalisation par + répertoire :

+ +
LogLevel info
+<Directory "/usr/local/apache/htdocs/app">
+  LogLevel debug
+</Directory>
+ + +
+ La configuration du niveau de journalisation par répertoire + n'affecte que les messages journalisés après l'interprétation de + la requête et qui sont associés à cette dernière. Les messages + de journalisation associés à la connexion ou au serveur ne sont + pas affectés. +
+ +

Voir aussi

+ +
+
top
+

Directive MaxKeepAliveRequests

+ + + + + + + +
Description:Nombre de requêtes permises pour une connexion +persistante
Syntaxe:MaxKeepAliveRequests nombre
Défaut:MaxKeepAliveRequests 100
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
+

La directive MaxKeepAliveRequests permet + de limiter le nombre de requêtes autorisées par connexion lorsque + KeepAlive est à "on". Si sa + valeur est 0, le nombre de requêtes autorisées est + illimité. Il est recommandé de définir une valeur assez haute pour + des performances du serveur maximales.

+ +

Par exemple :

+ +
MaxKeepAliveRequests 500
+ + +
+
top
+

Directive MaxRangeOverlaps

+ + + + + + + + +
Description:Nombre de chevauchements de segments de données autorisé + (par exemple 100-200,150-300) avant le renvoi de la + ressource complète
Syntaxe:MaxRangeOverlaps default | unlimited | none | nombre de + chevauchements
Défaut:MaxRangeOverlaps 20
Contexte:configuration globale, serveur virtuel, répertoire
Statut:Noyau httpd
Module:core
Compatibilité:Disponible depuis la version 2.3.15 du serveur HTTP + Apache
+

La directive MaxRangeOverlaps permet + de limiter le nombre de chevauchements de segments de données HTTP + autorisé par le serveur. Si le nombre de + chevauchements de segments demandé est supérieur au nombre maximal + autorisé, la ressource sera renvoyée dans son intégralité.

+ +
+
default
+
Limite le nombre de chevauchements de segments à la valeur + par défaut 20 définie à la compilation.
+ +
none
+
Aucun chevauchement de segment n'est autorisé.
+ +
unlimited
+
Le nombre de chevauchements de segments est illimité.
+ +
number-of-ranges
+
Un nombre positif représente le nombre maximal de + chevauchements de segments autorisé par le serveur.
+
+ +
+
top
+

Directive MaxRangeReversals

+ + + + + + + + +
Description:Nombre d'inversions d'ordre autorisé dans la spécification des + segments de données (par exemple 100-200,50-70) avant le renvoi de la + ressource complète
Syntaxe:MaxRangeReversals default | unlimited | none | nombre + d'inversions
Défaut:MaxRangeReversals 20
Contexte:configuration globale, serveur virtuel, répertoire
Statut:Noyau httpd
Module:core
Compatibilité:Disponible depuis la version 2.3.15 du serveur HTTP + Apache
+

La directive MaxRangeReversals permet + de limiter le nombre d'inversions d'ordre dans la spécification + des segments de données HTTP + autorisé par le serveur. Si le nombre + d'inversions demandé est supérieur au nombre maximal + autorisé, la ressource sera renvoyée dans son intégralité.

+ +
+
default
+
Limite le nombre d'inversions à la valeur + par défaut 20 définie à la compilation.
+ +
none
+
Aucune inversion n'est autorisée.
+ +
unlimited
+
Le nombre d'inversions est illimité.
+ +
number-of-ranges
+
Un nombre positif représente le nombre maximal + d'inversions autorisé par le serveur.
+
+ +
+
top
+

Directive MaxRanges

+ + + + + + + + +
Description:Nombre de segments de données autorisé avant le renvoi de +l'intégralité de la ressource
Syntaxe:MaxRanges default | unlimited | none | nombre de segments
Défaut:MaxRanges 200
Contexte:configuration globale, serveur virtuel, répertoire
Statut:Noyau httpd
Module:core
Compatibilité:Disponible depuis la version 2.3.15 du serveur HTTP +Apache
+

La directive MaxRanges permet de limiter + le nombre de segments de données que le serveur va renvoyer au + client. Si un nombre de segments plus important est demandé, la + ressource sera renvoyée dans son intégralité.

+ +
+
default
+
Limite le nombre de segments de données à 200 (valeur par + défaut définie à la compilation).
+ +
none
+
Les en-têtes Range sont ignorés.
+ +
unlimited
+
Le nombre de segments de données est illimité.
+ +
nombre de segments
+
Un nombre positif représentera la nombre de segments de + données maximal que le serveur renverra au client.
+
+ +
+
top
+

Directive MergeSlashes

+ + + + + + + + +
Description:Fusion des slashes consécutifs dans les URLs par le serveur. +
Syntaxe:MergeSlashes ON|OFF
Défaut:MergeSlashes ON
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
Compatibilité:Disponible à partir de la version 2.4.39 du serveur HTTP Apache
+

Par défaut, le serveur fusionne les caractères slash ('/') multiples et + consécutifs dans la partie chemin de l'URL d'une requête.

+ +

Lorsque cette partie chemin de l'URL est appliquée au système de + fichiers, ces slashes multiples sont inutiles. Il peut être cependant + préférable de conserver ces slashes multiples et consécutifs car ils peuvent + avoir une signification dans le cas des URLs gérées différemment, par + exemple par CGI ou par un serveur mandataire. Il convient alors de définir + MergeSlashes à OFF pour conserver les + slashes multiples consécutifs, ce qui correspond au comportement + traditionnel.

+

+ Lorsque cette directive est définie à "OFF", les expressions rationnelles utilisées dans le + fichier de configuration pour effectuer une comparaison de la partie chemin + de l'URL ((LocationMatch, + RewriteRule, ...) doivent en effet tenir compte de la + présence éventuelle de slashes multiples et consécutifs. Les sections + Location à base d'expressions non rationnelles + correspondent toujours à des URLs avec slashes fusionnés et ne peuvent pas + tenir compte des slashes multiples.

+ +
+
top
+

Directive MergeTrailers

+ + + + + + + + +
Description:Détermine si les données supplémentaires (trailers) sont +fusionnées avec les en-têtes
Syntaxe:MergeTrailers [on|off]
Défaut:MergeTrailers off
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
Compatibilité:Disponible à partir de la version 2.4.11 du serveur HTTP +Apache
+

Cette directive permet de contrôler la fusion des données HTTP + supplémentaires (trailers) avec la représentation interne des + en-têtes. Cette fusion intervient lorsque le corps de la requête a + été entièrement reçu, bien longtemps après que la majeure partie du + traitement des en-têtes ait une chance de pouvoir examiner ou + modifier les en-têtes de la requête.

+

Cette option a été introduite dans un souci de compatibilité avec + les versions antérieures à 2.4.11, où les données supplémentaires + étaient systématiquement fusionnées avec les en-têtes de la requête.

+ +
+
top
+

Directive Mutex

+ + + + + + + + +
Description:Définit les mécanismes de mutex et le repertoire du fichier +verrou pour tous les mutex ou seulement les mutex spécifiés
Syntaxe:Mutex mécanisme [default|nom-mutex] ... [OmitPID]
Défaut:Mutex default
Contexte:configuration globale
Statut:Noyau httpd
Module:core
Compatibilité:Disponible depuis la version 2.3.4 du serveur HTTP Apache
+

La directive Mutex permet de définir le + mécanisme de mutex, et éventuellement le répertoire du fichier + verrou que les modules et httpd utilisent pour sérialiser l'accès aux + ressources. Spécifiez default comme second argument + pour modifier la configuration de tous les mutex ; spécifiez un nom + de mutex (voir la table ci-dessous) comme second argument pour + ne modifier que la configuration de ce mutex.

+ +

La directive Mutex est typiquement + utilisée dans les situations exceptionnelles suivantes :

+ +
    +
  • choix d'un autre mécanisme de mutex lorsque le mécanisme par + défaut sélectionné par APR présente un + problème de fonctionnement ou de performances.
  • + +
  • choix d'un autre répertoire utilisé par les mutex à base de + fichier lorsque le répertoire par défaut ne supporte pas le + verrouillage
  • +
+ +

Modules supportés

+

Cette directive ne configure que les mutex qui ont été + enregistrés avec le serveur de base via l'API + ap_mutex_register(). Tous les modules fournis avec + httpd supportent la directive Mutex, mais il + n'en sera pas forcément de même pour les modules tiers. + Reportez-vous à la documentation du module tiers considéré afin de + déterminer le(s) nom(s) de mutex qui pourront être définis si la + directive est supportée.

+
+ + + +

Les mécanismes de mutex disponibles sont les suivants :

+
    +
  • default | yes +

    C'est l'implémentation du verrouillage par défaut, telle + qu'elle est définie par APR. On peut + afficher l'implémentation du verrouillage par défaut via la + commande httpd avec l'option -V.

  • + +
  • none | no +

    Le mutex est désactivé, et cette valeur n'est permise pour un + mutex que si le module indique qu'il s'agit d'un choix valide. + Consultez la documentation du module pour plus d'informations.

  • + +
  • posixsem +

    Une variante de mutex basée sur un sémaphore Posix.

    + +

    Avertissement

    +

    La propriété du sémaphore n'est pas restituée si un thread du + processus gérant le mutex provoque une erreur de segmentation, + ce qui provoquera un blocage du serveur web.

    +
    +
  • + +
  • sysvsem +

    Une variante de mutex basée sur un sémaphore IPC SystemV.

    + +

    Avertissement

    +

    Il peut arriver que les sémaphores SysV soient conservés si le + processus se crashe avant que le sémaphore ne soit supprimé.

    +
    + +

    Sécurité

    +

    L'API des sémaphores permet les attaques par déni de service + par tout programme CGI s'exécutant sous le même uid que le + serveur web (autrement dit tous les programmes CGI, à moins que + vous n'utilisiez un programme du style suexec + ou cgiwrapper).

    +
    +
  • + +
  • sem +

    Sélection de la "meilleure" implémentation des sémaphores + disponible ; le choix s'effectue entre les sémaphores posix et + IPC SystemV, dans cet ordre.

  • + +
  • pthread +

    Une variante de mutex à base de mutex de thread Posix + inter-processus.

    + +

    Avertissement

    +

    Sur la plupart des systèmes, si un processus enfant se + termine anormalement alors qu'il détenait un mutex qui utilise + cette implémentation, le serveur va se bloquer et cesser de + répondre aux requêtes. Dans ce cas, un redémarrage manuel est + nécessaire pour récupérer le mutex.

    +

    Solaris et Linux constituent des exceptions notables, en ceci qu'ils fournissent + un mécanisme qui permet en général de récupérer le mutex après + l'arrêt anormal d'un processus enfant qui détenait le mutex.

    +

    Si votre système est compatible POSIX ou implémente la fonction + pthread_mutexattr_setrobust_np(), vous devriez + pouvoir utiliser l'option pthread sans problème.

    +
    +
  • + +
  • fcntl:/chemin/vers/mutex +

    Une variante de mutex utilisant un fichier verrou physique et + la fonction fcntl().

    + +

    Avertissement

    +

    Lorsqu'on utilise plusieurs mutex basés sur ce mécanisme dans + un environnement multi-processus, multi-thread, des erreurs de + blocage (EDEADLK) peuvent être rapportées pour des opérations de + mutex valides si la fonction fcntl() ne gère pas + les threads, comme sous Solaris.

    +
    +
  • + +
  • flock:/chemin/vers/mutex +

    Méthode similaire à fcntl:/chemin/vers/mutex, + mais c'est la fonction flock() qui est utilisée + pour gérer le verrouillage par fichier.

  • + +
  • file:/chemin/vers/mutex +

    Sélection de la "meilleure" implémentation de verrouillage + par fichier disponible ; le choix s'effectue entre + fcntl et flock, dans cet ordre.

  • +
+ +

La plupart des mécanismes ne sont disponibles que sur les + plate-formes où ces dernières et APR les + supportent. Les mécanismes qui ne sont pas disponibles sur toutes + les plate-formes sont posixsem, + sysvsem, sem, pthread, fcntl, + flock, et file.

+ +

Avec les mécanismes à base de fichier fcntl et + flock, le chemin, s'il est fourni, est un répertoire dans + lequel le fichier verrou sera créé. Le répertoire par + défaut est le répertoire d'exécution de httpd relatif à la + directive ServerRoot. + Utilisez toujours un système + de fichiers local sur disque pour /chemin/vers/mutex et + jamais un répertoire se trouvant dans un système de fichiers NFS ou + AFS. Le nom de base du fichier se composera du type de mutex, d'une + chaîne optionnelle correspondant à l'instance et fournie par le + module ; et, sauf si le mot-clé OmitPID a été spécifié, + l'identificateur du processus parent httpd sera ajouté afin de + rendre le nom du fichier unique, évitant ainsi tout conflit lorsque + plusieurs instances d'httpd partagent le même répertoire de + verrouillage. Par exemple, si le nom de mutex est + mpm-accept, et si le répertoire de verrouillage est + /var/httpd/locks, le nom du fichier verrou pour + l'instance httpd dont le processus parent a pour identifiant 12345 + sera /var/httpd/locks/mpm-accept.12345.

+ +

Sécurité

+

Il est conseillé d'éviter de placer les fichiers mutex + dans un répertoire où tout le monde peut écrire comme + /var/tmp, car quelqu'un pourrait initier une attaque + par déni de service et empêcher le serveur de démarrer en créant un + fichier verrou possédant un nom identique à celui que le serveur va + tenter de créer.

+
+ +

La table suivante décrit les noms de mutex utilisés par httpd et + ses modules associés.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nom mutexModule(s)Ressource protégée
mpm-acceptmodules MPM prefork et workerconnexions entrantes, afin d'éviter le problème de + l'afflux de requêtes ; pour plus d'informations, voir la + documentation Amélioration des + performances
authdigest-clientmod_auth_digestliste de clients en mémoire partagée
authdigest-opaquemod_auth_digestcompteur en mémoire partagée
ldap-cachemod_ldapcache de résultat de recherche LDAP
rewrite-mapmod_rewritecommunication avec des programmes externes + d'associations de valeurs, afin d'éviter les interférences + d'entrées/sorties entre plusieurs requêtes
ssl-cachemod_sslcache de session SSL
ssl-staplingmod_sslcache de l'étiquetage OCSP ("OCSP stapling")
watchdog-callbackmod_watchdogfonction de rappel d'un module client particulier
+ +

Le mot-clé OmitPID permet d'empêcher l'addition de + l'identifiant du processus httpd parent au nom du fichier verrou.

+ + +

Dans l'exemple suivant, le mécanisme de mutex pour le mutex + mpm-accept est modifié pour passer du mécanisme par défaut au + mécanisme fcntl, avec le fichier verrou associé créé + dans le répertoire /var/httpd/locks. Le mécanisme de + mutex par défaut pour tous les autres mutex deviendra + sysvsem.

+ +
Mutex sysvsem default
+Mutex fcntl:/var/httpd/locks mpm-accept
+ + +
+
top
+

Directive NameVirtualHost

+ + + + + + +
Description:OBSOLETE : Définit une adresse IP pour les serveurs virtuels à base de +nom
Syntaxe:NameVirtualHost adresse[:port]
Contexte:configuration globale
Statut:Noyau httpd
Module:core
+ +

Avant la version 2.3.11, il était nécessaire de définir une + directive NameVirtualHost pour indiquer au + serveur qu'une paire adresse IP/port particulière pouvait être + utilisée comme serveur virtuel à base de nom. Depuis la version + 2.3.11, chaque fois qu'une paire adresse IP/port est utilisée dans + plusieurs serveurs virtuels, l'hébergement virtuel à base de nom est + automatiquement activé pour cette adresse.

+ +

Cette directive n'a actuellement plus aucun effet.

+ +

Voir aussi

+ +
+
top
+

Directive Options

+ + + + + + + + + +
Description:Définit les fonctionnalités disponibles pour un répertoire +particulier
Syntaxe:Options + [+|-]option [[+|-]option] ...
Défaut:Options FollowSymlinks
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:Options
Statut:Noyau httpd
Module:core
Compatibilité:Avec la version 2.3.11, la valeur par défaut passe de All +à FollowSymlinks
+

La directive Options permet de définir + les fonctionnalités de serveur disponibles pour un répertoire + particulier.

+ +

option peut être défini à None, auquel + cas aucune fonctionnalité spécifique n'est activée, ou comprendre + une ou plusieurs des options suivantes :

+ +
+
All
+ +
Toutes les options excepté MultiViews.
+ +
ExecCGI
+ +
L'exécution de scripts CGI à l'aide du module + mod_cgi est permise.
+ +
FollowSymLinks
+ +
+ + 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 + pas le nom de chemin concerné défini par la section + <Directory>.

+ +

Les options FollowSymLinks et + SymLinksIfOwnerMatch ne fonctionnent que dans les + sections <Directory> ou les fichiers + .htaccess.

+ +

Le fait d'omettre cette option ne doit pas être considéré comme + une mesure de sécurité efficace, car il existe toujours une + situation de compétition (race condition) entre l'instant où l'on + vérifie qu'un chemin n'est pas un lien symbolique, et l'instant où + l'on utilise effectivement ce chemin.

+
+ +
Includes
+ +
+ Les inclusions côté serveur (SSI) à l'aide du module + mod_include sont autorisées.
+ +
IncludesNOEXEC
+ +
+ + Les inclusions côté serveur (SSI) sont permises, mais #exec + cmd et #exec cgi sont désactivés. + L'utilisation de #include virtual pour les scripts + CGI est cependant toujours possible depuis des répertoires + définis par ScriptAlias.
+ +
Indexes
+ +
+ Si une URL requise correspond au répertoire concerné, et si aucun + DirectoryIndex (par + exemple index.html) n'est défini pour ce + répertoire, le module mod_autoindex va renvoyer + un listing formaté du répertoire.
+ +
MultiViews
+ +
+ Les vues multiples ("multiviews") à contenu négocié à l'aide du + module mod_negotiation sont autorisées. +

Note

Cette option est ignorée si elle est + définie en tout autre endroit qu'une section <Directory>, car + mod_negotiation a besoin de ressources réelles + pour effectuer ses comparaisons et ses évaluations.

+ +
+ +
SymLinksIfOwnerMatch
+ +
Le serveur ne suivra que les liens symboliques qui renvoient + vers un fichier ou un répertoire dont le propriétaire est le même + que celui du lien. + +

Note

+

Les options FollowSymLinks et + SymLinksIfOwnerMatch ne fonctionnent que dans les + sections <Directory> ou les fichiers + .htaccess.

+ +

Le fait d'omettre cette option ne doit pas être considéré comme + une mesure de sécurité efficace, car il existe toujours une + situation de compétition (race condition) entre l'instant où l'on + vérifie qu'un chemin n'est pas un lien symbolique, et l'instant où + l'on utilise effectivement ce chemin.

+
+
+ +

Normalement, si plusieurs directives + Options 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 comment les sections sont + fusionnées). Elles le sont cependant si toutes les + options de la directive Options sont + précédées d'un symbole + ou -. Toute + option précédée d'un + est ajoutée à la liste des + options courantes de manière forcée et toute option précédée d'un + - est supprimée de la liste des options courantes de la + même manière.

+ +

Note

+

Mélanger des Options avec + + ou - avec des Options sans + + ou - constitue une erreur de syntaxe, et + la vérification de la syntaxe au cours du démarrage du serveur fera + échouer ce dernier.

+
+ +

Par exemple, sans aucun symbole + et - + :

+ +
<Directory "/web/docs">
+  Options Indexes FollowSymLinks
+</Directory>
+
+<Directory "/web/docs/spec">
+  Options Includes
+</Directory>
+ + +

ici, seule l'option Includes sera prise en compte + pour le répertoire /web/docs/spec. Par contre, si la + seconde directive Options utilise les + symboles + et - :

+ +
<Directory "/web/docs">
+  Options Indexes FollowSymLinks
+</Directory>
+
+<Directory "/web/docs/spec">
+  Options +Includes -Indexes
+</Directory>
+ + +

alors, les options FollowSymLinks et + Includes seront prises en compte pour le répertoire + /web/docs/spec.

+ +

Note

+

L'utilisation de -IncludesNOEXEC ou + -Includes désactive complètement les inclusions côté + serveur sans tenir compte des définitions précédentes.

+
+ +

En l'absence de toute définition d'options, la valeur par défaut + est FollowSymlinks.

+ +
+
top
+

Directive Protocol

+ + + + + + + +
Description:Protocole pour une socket d'écoute
Syntaxe:Protocol protocole
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
Compatibilité:Disponible depuis la version 2.1.5 d'Apache, mais +seulement depuis la version 2.3.3 sous Windows.
+

Cette directive permet de spécifier le protocole utilisé pour une + socket d'écoute particulière. Le protocole sert à déterminer quel + module doit traiter une requête, et d'appliquer les optimisations + spécifiques au protocole via la directive + AcceptFilter.

+ +

Dans la plupart des configurations, cette directive n'est pas nécessaire. + Si elle n'est pas définie, le protocole par défaut pour le port 443 est + https et http pour tous les autres ports. La + connaissance du protocole permet de déterminer quel module doit traiter la + requête, et d'appliquer les optimisations spécifiques au protocole via la + directive AcceptFilter.

+ +

Par exemple, si vous travaillez avec le protocole + https sur un port non standard, spécifiez le protocole + de manière explicite :

+ +
Protocol https
+ + +

Vous pouvez aussi spécifier le protocole via la directive + Listen.

+ +

Voir aussi

+ +
+
top
+

Directive Protocols

+ + + + + + + + +
Description:Protocoles disponibles pour un serveur virtuel ou non
Syntaxe:Protocols protocole ...
Défaut:Protocols http/1.1
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
Compatibilité:Disponible à partir de la version 2.4.17 du serveur + HTTP Apache.
+

Cette directive permet de spécifier la liste des protocoles + supportés par un serveur virtuel ou non. Cette liste énumère les + protocoles qu'un client sera autorisé à négocier avec ce + serveur.

+ +

Par défaut, + seul le protocole http/1.1 est disponible (compatible avec les + clients http/1.0 et http/0.9). Par conséquent, vous devez + fournir cette liste si vous voulez étendre les protocoles + disponibles pour le serveur.

+ +

Par exemple, si vous voulez autoriser le protocole + HTTP/2 pour un serveur avec TLS, utilisez + cette directive comme suit :

+ +
Protocols h2 http/1.1
+ + +

Les protocoles valides sont http/1.1 pour les + connexions http et https, h2 pour les connections + https et h2c pour les connexions http. D'autres + modules peuvent fournir d'autres protocoles.

+ +

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

+ +

Si un serveur virtuel ne possède pas de directive Protocols + propre, il hérite des protocoles spécifiés pour le serveur + principal. Autrement dit, les directives Protocols définies au + niveau d'un serveur virtuel remplacent celles définies au niveau + du serveur principal. +

+ + +

Voir aussi

+ +
+
top
+

Directive ProtocolsHonorOrder

+ + + + + + + + +
Description:Détermine qui du client ou du serveur détermine l'ordre + des protocoles au cours de la négociation de la connexion
Syntaxe:ProtocolsHonorOrder On|Off
Défaut:ProtocolsHonorOrder On
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
Compatibilité:Disponible à partir de la version 2.4.17 du serveur + HTTP Apache.
+

Cette directive permet de définir si le serveur doit tenir + compte de l'ordre des protocoles définis par la directive + Protocols.

+ +

Si cette directive est définie à Off, l'ordre de la liste des + protocoles fournie par le client l'emporte sur l'ordre défini + dans la configuration du serveur.

+ +

Si la directive ProtocolsHonorOrder + est définie à on (valeur par défaut), + il n'est pas tenu compte de l'ordre de la liste des protocoles + fournie par le client, et seul l'ordre de la liste des protocles + définie au niveau du serveur influera la + négociation du protocole.

+ + +

Voir aussi

+ +
+
top
+

Directive QualifyRedirectURL

+ + + + + + + + + +
Description:Vérifie si la variable d'environnement REDIRECT_URL est +pleinement qualifiée
Syntaxe:QualifyRedirectURL On|Off
Défaut:QualifyRedirectURL Off
Contexte:configuration globale, serveur virtuel, répertoire
Surcharges autorisées:FileInfo
Statut:Noyau httpd
Module:core
Compatibilité:Directive supportée à partir de la version 2.4.18 du +serveur HTTP Apache. Jusqu'à la version 2.4.17, le serveur se comportait +comme si la directive QualifyRedirectURL était définie à On.
+

Cette directive permet de s'assurer que le serveur vérifiera que + la variable d'environnement REDIRECT_URL est bien pleinement + qualifiée. Par défaut, cette variable contient l'URL textuellement + demandée par le client, par exemple "/index.html". Avec + QualifyRedirectURL ON, la même requête + affectera à la variable REDIRECT_URL une valeur du style + "http://www.example.com/index.html".

+

Même si cette directive n'est pas définie, lorsqu'une requête est + soumise avec une URL pleinement qualifiée, la variable REDIRECT_URL + contiendra quand-même une URL pleinement qualifiée. +

+ +
+
top
+

Directive ReadBufferSize

+ + + + + + + + +
Description:Taille des tampons utilisés pour lire les données
Syntaxe:ReadBufferSize bytes
Défaut:ReadBufferSize 8192
Contexte:configuration globale, serveur virtuel, répertoire
Statut:Noyau httpd
Module:core
Compatibilité:Disponible à partir de la version 2.5 du serveur HTTP +Apache.
+

Cette directive permet de définir la taille (en octets) du tampon mémoire + utilisé pour lire des données depuis le réseau ou un fichier.

+ +

Un tampon de grande taille peut améliorer les performances pour les + grandes quantités de données, mais consomme d'avantage de mémoire par + connexion. La taille minimale du tampon est de 1024 octets.

+ +
+
top
+

Directive RegexDefaultOptions

+ + + + + + + + +
Description:Configuration des options globales par défaut pour les + expressions rationnelles
Syntaxe:RegexDefaultOptions [none] [+|-]option [[+|-]option] ...
Défaut:RegexDefaultOptions DOTALL DOLLAR_ENDONLY
Contexte:configuration globale
Statut:Noyau httpd
Module:core
Compatibilité:Disponible à partir de la version 2.4.30 du serveur HTTP + Apache.
+

Cette directive permet d'ajouter certains comportements par défaut à + TOUTES les expressions rationnelles utilisées ultérieurement.

+ +

Toute option précédée d'un '+' est ajoutée aux options déjà définies.
+ Toute option précédée d'un '-' est enlevée des options déjà définies.
+ Toute option non suffixée par '+' ou '-' sera définie et remplacera + l'option correspondante éventuellement déjà définie.
+ Le mot-clé none annule toutes les options déjà définies.

+ +

option peut être :

+
+
ICASE
+
Utilise une recherche de correspondance insensible à la casse.
+ +
EXTENDED
+
Le drapeau Perl /x ; ignore les espaces non échappés et les + commentaires dans le modèle.
+ +
DOTALL
+
Le drapeau Perl /s ; '.' correspond aux caractères nouvelle + ligne.
+ +
DOLLAR_ENDONLY
+
'$' n'est actif qu'à la fin de la chaîne de référence.
+ +
+
# Ajoute l'option ICASE par défaut pour toutes les expressions rationnelles
+RegexDefaultOptions +ICASE
+...
+# Supprime l'option DOLLAR_ENDONLY par défaut et conserve toutes les autres
+# options
+RegexDefaultOptions -DOLLAR_ENDONLY
+...
+# Définit l'option DOTALL seule et annule toutes les autres options
+RegexDefaultOptions DOTALL
+...
+# Annule toutes les options définies
+RegexDefaultOptions none
+...
+ + +
+
top
+

Directive RegisterHttpMethod

+ + + + + + + +
Description:Enregistrement de méthodes HTTP non standards
Syntaxe:RegisterHttpMethod méthode [méthode [...]]
Contexte:configuration globale
Statut:Noyau httpd
Module:core
Compatibilité:Disponible à partir de la version 2.4.24 du serveur HTTP Apache
+

Cette directive permet d'enregistrer des méthodes HTTP supplémentaires. Ceci +s'avérera nécessaire si l'on doit utiliser des méthodes non standards avec des +directives qui acceptent des noms de méthodes en paramètres, ou pour permettre +l'utilisation de méthodes particulières non standards en passant par un serveur +mandataire ou au sein de scripts CGI, et ceci alors que le serveur a été +configuré pour ne transmettre que des méthodes reconnues aux modules.

+ +

Voir aussi

+ +
+
top
+

Directive RLimitCPU

+ + + + + + + + +
Description:Limite le temps CPU alloué aux processus initiés par les +processus enfants d'Apache httpd
Syntaxe:RLimitCPU secondes|max [secondes|max]
Défaut:Non défini ; utilise les valeurs par défaut du système +d'exploitation
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:All
Statut:Noyau httpd
Module:core
+

Prend 1 ou 2 paramètres. Le premier definit la limite de + consommation de ressources pour tous les processus, et le second la + consommation de ressources maximale. Les deux paramètres peuvent + contenir soit un nombre, soit max pour indiquer au + serveur que la limite de consommation correspond à la valeur + maximale autorisée par la configuration du système d'exploitation. + Pour augmenter la consommation maximale de ressources, le serveur + doit s'exécuter en tant que root, ou se trouver dans sa + phase de démarrage.

+ +

Cette directive s'applique aux processus initiés par les + processus enfants d'Apache httpd qui traitent les requêtes, et non aux + processus enfants eux-mêmes. Sont concernés les scripts CGI et les + commandes exec des SSI, mais en aucun cas les processus initiés par + le processus parent d'Apache httpd comme les journalisations redirigées + vers un programme.

+ +

Les limites de ressources CPU sont exprimées en secondes par + processus.

+ +

Voir aussi

+ +
+
top
+

Directive RLimitMEM

+ + + + + + + + +
Description:Limite la mémoire allouée aux processus initiés par les +processus enfants d'Apache httpd
Syntaxe:RLimitMEM octets|max [octets|max]
Défaut:Non défini ; utilise les valeurs par défaut du système +d'exploitation
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:All
Statut:Noyau httpd
Module:core
+

Prend 1 ou 2 paramètres. Le premier definit la limite de + consommation de ressources pour tous les processus, et le second la + consommation de ressources maximale. Les deux paramètres peuvent + contenir soit un nombre, soit max pour indiquer au + serveur que la limite de consommation correspond à la valeur + maximale autorisée par la configuration du système d'exploitation. + Pour augmenter la consommation maximale de ressources, le serveur + doit s'exécuter en tant que root, ou se trouver dans sa + phase de démarrage.

+ +

Cette directive s'applique aux processus initiés par les + processus enfants d'Apache httpd qui traitent les requêtes, et non aux + processus enfants eux-mêmes. Sont concernés les scripts CGI et les + commandes exec des SSI, mais en aucun cas les processus initiés par + le processus parent d'Apache httpd comme les journalisations redirigées + vers un programme.

+ +

Les limites de ressources mémoire sont exprimées en octets par + processus.

+ +

Voir aussi

+ +
+
top
+

Directive RLimitNPROC

+ + + + + + + + +
Description:Limite le nombre de processus qui peuvent être initiés par +les processus initiés par les processus enfants d'Apache httpd
Syntaxe:RLimitNPROC nombre|max [nombre|max]
Défaut:Unset; uses operating system defaults
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:All
Statut:Noyau httpd
Module:core
+

Prend 1 ou 2 paramètres. Le premier definit la limite de + consommation de ressources pour tous les processus, et le second la + consommation de ressources maximale. Les deux paramètres peuvent + contenir soit un nombre, soit max pour indiquer au + serveur que la limite de consommation correspond à la valeur + maximale autorisée par la configuration du système d'exploitation. + Pour augmenter la consommation maximale de ressources, le serveur + doit s'exécuter en tant que root, ou se trouver dans sa + phase de démarrage.

+ +

Cette directive s'applique aux processus initiés par les + processus enfants d'Apache httpd qui traitent les requêtes, et non aux + processus enfants eux-mêmes. Sont concernés les scripts CGI et les + commandes exec des SSI, mais en aucun cas les processus initiés par + le processus parent d'Apache httpd comme les journalisations redirigées + vers un programme.

+ +

Les limites des processus contrôlent le nombre de processus par + utilisateur.

+ +

Note

+

Si les processus CGI s'exécutent sous le même + utilisateur que celui du serveur web, cette + directive va limiter le nombre de processus que le serveur + pourra lui-même créer. La présence de messages + cannot fork dans le journal des + erreurs indiquera que la limite est atteinte.

+
+ +

Voir aussi

+ +
+
top
+

Directive ScriptInterpreterSource

+ + + + + + + + + +
Description:Permet de localiser l'interpréteur des scripts +CGI
Syntaxe:ScriptInterpreterSource Registry|Registry-Strict|Script
Défaut:ScriptInterpreterSource Script
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:FileInfo
Statut:Noyau httpd
Module:core
Compatibilité:Win32 seulement.
+

Cette directive permet de contrôler la méthode qu'utilise Apache + httpd pour trouver l'interpréteur destiné à exécuter les scripts CGI. La + définition par défaut est Script : ceci indique à + Apache httpd qu'il doit utiliser l'interpréteur précisé dans la ligne + shebang du script (la première ligne, commençant par + #!). Sur les systèmes Win32, cette ligne ressemble + souvent à ceci :

+ +
#!C:/Perl/bin/perl.exe
+ + +

ou simplement, dans le cas où perl est dans le + PATH :

+ +
#!perl
+ + +

Avec ScriptInterpreterSource Registry, Windows va + effectuer une recherche dans l'arborescence + HKEY_CLASSES_ROOT de la base de registre avec comme + mot-clé l'extension du fichier contenant le script (par exemple + .pl). C'est la commande définie par la sous-clé de + registre Shell\ExecCGI\Command ou, si elle n'existe + pas, la sous-clé Shell\Open\Command qui est utilisée + pour ouvrir le fichier du script. Si ces clés de registre ne sont + pas trouvées, Apache httpd utilise la méthode de l'option + Script.

+ +

Sécurité

+

Soyez prudent si vous utilisez ScriptInterpreterSource + Registry avec des répertoires faisant l'objet d'un ScriptAlias, car Apache httpd va essayer + d'exécuter tous les fichiers contenus dans + celui-ci. L'option Registry peut causer des appels de + programmes non voulus sur des fichiers non destinés à être exécutés. + Par exemple, la commande par défaut open sur les fichiers + .htm sur la plupart des systèmes Windows va lancer + Microsoft Internet Explorer ; ainsi, toute requête HTTP pour un + fichier .htm situé dans le répertoire des scripts + va lancer le navigateur en arrière-plan sur le serveur, ce qui a + toutes les chances de crasher votre système dans les minutes qui + suivent.

+
+ +

L'option Registry-Strict + agit de manière identique à Registry, mais n'utilise + que la sous-clé Shell\ExecCGI\Command. La présence de + la clé ExecCGI n'étant pas systématique, Elle doit être + définie manuellement dans le registre Windows et évite ainsi tout + appel de programme accidentel sur votre système.

+ +
+
top
+

Directive SeeRequestTail

+ + + + + + + + +
Description:Détermine si mod_status affiche les 63 premiers caractères +d'une requête ou les 63 derniers, en supposant que la requête +elle-même possède plus de 63 caractères.
Syntaxe:SeeRequestTail On|Off
Défaut:SeeRequestTail Off
Contexte:configuration globale
Statut:Noyau httpd
Module:core
Compatibilité:Disponible depuis la version 2.2.7 +d'Apache httpd.
+

Avec ExtendedStatus On, mod_status affiche la + véritable requête en cours de traitement. Pour des raisons + historiques, seuls 63 caractères de la requête sont réellement + stockés à des fins d'affichage. Cette directive permet de déterminer + si ce sont les 63 premiers caractères qui seront stockés (c'est le + comportement par défaut), + ou si ce sont les 63 derniers. Ceci ne s'applique bien entendu que + si la taille de la requête est de 64 caractères ou plus.

+ +

Si Apache httpd traite la requête GET /disque1/stockage/apache/htdocs/images/rep-images1/nourriture/pommes.jpg HTTP/1.1 + , l'affichage de la requête par mod_status se présentera comme suit : +

+ + + + + + + + + + +
Off (défaut)GET /disque1/stockage/apache/htdocs/images/rep-images1/nourritu
Onapache/htdocs/images/rep-images1/nourriture/pommes.jpg HTTP/1.1
+ + +
+
top
+

Directive ServerAdmin

+ + + + + + +
Description:L'adresse électronique que le serveur inclut dans les +messages d'erreur envoyés au client
Syntaxe:ServerAdmin adresse électronique|URL
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
+

La directive ServerAdmin permet de définir + l'adresse de contact que le serveur va inclure dans tout message + d'erreur qu'il envoie au client. Si le programme httpd + ne reconnait pas l'argument fourni comme une URL, il suppose que + c'est une adresse électronique, et lui ajoute le préfixe + mailto: dans les cibles des hyperliens. Il est + cependant recommandé d'utiliser exclusivement une adresse + électronique, car de nombreux scripts CGI considèrent ceci comme + implicite. Si vous utilisez une URL, elle doit pointer vers un autre + serveur que vous contrôlez. Dans le cas contraire, les utilisateurs + seraient dans l'impossibilité de vous contacter en cas de problème.

+ +

Il peut s'avérer utile de définir une adresse dédiée à + l'administration du serveur, par exemple :

+ +
ServerAdmin www-admin@foo.example.com
+ +

car les utilisateurs ne mentionnent pas systématiquement le + serveur dont ils parlent !

+ +
+
top
+

Directive ServerAlias

+ + + + + + +
Description:Autres noms d'un serveur utilisables pour atteindre des +serveurs virtuels à base de nom
Syntaxe:ServerAlias nom serveur [nom serveur] +...
Contexte:serveur virtuel
Statut:Noyau httpd
Module:core
+

La directive ServerAlias permet de définir + les noms alternatifs d'un serveur utilisables pour atteindre des serveurs virtuels à base de + nom. La directive ServerAlias peut + contenir des caractères génériques, si nécessaire.

+ +
<VirtualHost *:80>
+  ServerName server.example.com
+  ServerAlias server server2.example.com server2
+  ServerAlias *.example.com
+  UseCanonicalName Off
+  # ...
+</VirtualHost>
+ +

La recherche du serveur virtuel à base de nom correspondant au + plus près à la requête s'effectue selon l'ordre d'apparition des + directives <virtualhost> dans le fichier de + configuration. Le premier serveur virtuel dont le ServerName ou le ServerAlias correspond est choisi, sans + priorité particulière si le nom contient des caractères génériques + (que ce soit pour ServerName ou ServerAlias).

+ +

Tous les noms spécifiés au sein d'une section <VirtualHost> sont traités comme un + ServerAlias (sans caractères génériques).

+ + +

Voir aussi

+ +
+
top
+

Directive ServerName

+ + + + + + +
Description:Nom d'hôte et port que le serveur utilise pour +s'authentifier lui-même
Syntaxe:ServerName +[protocole://]nom-de-domaine|adresse-ip[:port]
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
+

La directive ServerName permet de définir + les protocole, nom d'hôte et port d'une requête que le serveur + utilise pour s'authentifier lui-même.

+ +

La directive ServerName permet (éventuellement en + conjonction avec la directive ServerAlias) d'identifier de manière unique un + serveur virtuel, lorsqu'elle est utilisée dans un contexte de 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.

+ +

Par exemple, si le nom de la + machine hébergeant le serveur web est + simple.example.com, la machine possède l'alias + DNS www.example.com, et si vous voulez que le serveur + web s'identifie avec cet alias, vous devez utilisez la définition + suivante :

+ +
ServerName www.example.com
+ + +

La directive ServerName peut apparaître à + toutes les étapes de la définition du serveur. Toute occurrence + annule cependant la précédente (pour ce serveur).

+ +

Si la directive ServerName n'est pas + définie, le serveur tente de déterminer le nom + d'hôte visible du point de vue du client en demandant tout d'abord au + système d'exploitation le nom d'hôte système, et en cas d'échec, en effectuant + une recherche DNS inverse sur une adresse IP présente sur le système.

+ +

Si la directive + ServerName ne précise pas de port, le serveur + utilisera celui de la requête entrante. Il est recommandé de + spécifier un nom d'hôte et un port spécifiques à l'aide de la + directive ServerName pour une fiabilité + optimale et à titre préventif.

+ +

Si vous définissez des serveurs virtuels à base de + nom, une directive ServerName située à + l'intérieur d'une section <VirtualHost> spécifiera quel nom d'hôte + 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 + https:// et le port auquel les clients se connectent + dans la directive ServerName, afin de + s'assurer que le serveur génère correctement ses URLs + d'auto-identification. +

+ +

Voir la description des directives UseCanonicalName et UseCanonicalPhysicalPort pour les + définitions qui permettent de déterminer si les URLs + auto-identifiantes (par exemple via le module + mod_dir) vont faire référence au port spécifié, ou + au port indiqué dans la requête du client. +

+ +
+

Si la valeur de la directive ServerName ne + peut pas être résolue en adresse IP, le démarrage du serveur + provoquera un avertissement. httpd va alors utiliser le + résultat de la commande système hostname pour + déterminer le nom du serveur, ce qui ne correspondra pratiquement + jamais au nom de serveur que vous souhaitez réellement.

+

+ httpd: Could not reliably determine the server's fully qualified domain name, using rocinante.local for ServerName +

+
+ + +

Voir aussi

+ +
+
top
+

Directive ServerPath

+ + + + + + +
Description:Nom de chemin d'URL hérité pour un serveur virtuel à base +de nom accédé par un navigateur incompatible
Syntaxe:ServerPath chemin d'URL
Contexte:serveur virtuel
Statut:Noyau httpd
Module:core
+

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.

+ +

Voir aussi

+ +
+
top
+

Directive ServerRoot

+ + + + + + + +
Description:Racine du répertoire d'installation du +serveur
Syntaxe:ServerRoot chemin de répertoire
Défaut:ServerRoot /usr/local/apache
Contexte:configuration globale
Statut:Noyau httpd
Module:core
+

La directive ServerRoot permet de définir + le répertoire dans lequel le serveur est installé. En particulier, + il contiendra les sous-répertoires conf/ et + logs/. Les chemins relatifs indiqués dans les autres + directives (comme Include ou LoadModule) seront définis par + rapport à ce répertoire.

+ +
ServerRoot "/home/httpd"
+ + +

La valeur par défaut de ServerRoot peut + être modifiée via l'argument --prefix de la commande configure, et de + nombreuses distributions tierces du serveur proposent une valeur + différente de celles listées ci-dessus.

+ + +

Voir aussi

+ +
+
top
+

Directive ServerSignature

+ + + + + + + + +
Description:Définit un pied de page pour les documents générés par le +serveur
Syntaxe:ServerSignature On|Off|EMail
Défaut:ServerSignature Off
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:All
Statut:Noyau httpd
Module:core
+

La directive ServerSignature permet de + définir une ligne de pied de page fixe pour les documents générés + par le serveur (messages d'erreur, listings de répertoires ftp de + mod_proxy, sorties de mod_info, + etc...). Dans le cas d'une chaîne de mandataires, l'utilisateur n'a + souvent aucun moyen de déterminer lequel des mandataires chaînés a + généré un message d'erreur, et c'est une des raisons pour lesquelles + on peut être amené à ajouter un tel pied de page.

+ +

La valeur par défaut Off supprime la ligne de pied + de page. la valeur On + ajoute simplement une ligne contenant le numéro de version du + serveur ainsi que le nom du serveur virtuel issu de la directive + ServerName, alors que la valeur + EMail ajoute en plus une référence "mailto:" à + l'administrateur du document référencé issu la directive + ServerAdmin.

+ +

Les détails à propos du numéro de + version du serveur sont contrôlés à l'aide de la directive + ServerTokens.

+ +

Voir aussi

+ +
+
top
+

Directive ServerTokens

+ + + + + + + +
Description:Configure l'en-tête Server de la réponse +HTTP
Syntaxe:ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Full
Défaut:ServerTokens Full
Contexte:configuration globale
Statut:Noyau httpd
Module:core
+

Cette directive permet de contrôler le contenu de l'en-tête + Server inclus dans la réponse envoyée au client : cet + en-tête peut contenir le type de système d'exploitation du serveur, + ainsi que des informations à propos des modules compilés avec le + serveur.

+ +
+
ServerTokens Full (ou non spécifié)
+ +
Le serveur envoie par exemple : Server: Apache/2.4.2 + (Unix) PHP/4.2.2 MyMod/1.2
+ +
ServerTokens Prod[uctOnly]
+ +
Le serveur renvoie (par exemple): Server: + Apache
+ +
ServerTokens Major
+ +
Le serveur renvoie (par exemple): Server: + Apache/2
+ +
ServerTokens Minor
+ +
Le serveur renvoie (par exemple): Server: + Apache/2.4
+ +
ServerTokens Min[imal]
+ +
Le serveur renvoie (par exemple): Server: + Apache/2.4.2
+ +
ServerTokens OS
+ +
Le serveur renvoie (par exemple): Server: + Apache/2.4.2 (Unix)
+ + + +
+ +

Cette définition s'applique à l'ensemble du serveur et ne peut + être activée ou désactivée pour tel ou tel serveur virtuel.

+ +

Cette directive contrôle + aussi les informations fournies par la directive ServerSignature.

+ +
Définir ServerTokens à une + valeur inférieure à minimal n'est pas + recommandé car le débogage des problèmes + interopérationnels n'en sera alors que plus difficile. Notez + aussi que la désactivation de l'en-tête Server: + n'améliore en rien la sécurité de votre + serveur ; le concept de "sécurité par + l'obscurité" est un mythe et conduit à + une mauvaise perception de ce qu'est la sécurité.
+ + + +

Voir aussi

+ +
+
top
+

Directive SetHandler

+ + + + + + + + +
Description:Force le traitement des fichiers spécifiés par un +gestionnaire particulier
Syntaxe:SetHandler handler-name|none|expression
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:FileInfo
Statut:Noyau httpd
Module:core
Compatibilité:L'argument expression est disponible à partir de la version +2.4.19 su serveur HTTP Apache
+

Lorsqu'elle se situe à l'intérieur d'un fichier + .htaccess, ou d'une section <Directory> ou <Location>, cette directive force le + traitement de tous les fichiers spécifiés par le gestionnaire défini par l'argument + nom gestionnaire. Par exemple, dans le cas d'un + répertoire dont vous voulez interpréter le contenu comme des + fichiers de règles d'images cliquables, sans tenir compte des + extensions, vous pouvez ajouter la ligne suivante dans un fichier + .htaccess de ce répertoire :

+ +
SetHandler imap-file
+ + +

Autre exemple : si vous voulez que le serveur affiche un + compte-rendu d'état chaque fois qu'une URL du type http://nom + serveur/status est appelée, vous pouvez ajouter ceci dans + httpd.conf :

+ +
<Location "/status">
+  SetHandler server-status
+</Location>
+ + +

Vous pouvez aussi utiliser cette directive pour associer un + gestionnaire à des fichiers possèdant une extension de nom de + fichier particulière. Par exemple :

+ +
<FilesMatch "\.php$">
+    SetHandler application/x-httpd-php
+</FilesMatch>
+ + +

Pour référencer des variables spécifiques à une requête, y compris les + références arrières vers des expressions rationnelles nommées, vous pouvez + utiliser des expressions ayant pour valeur une chaîne :

+ +
<LocationMatch ^/app/(?<sub>[^/]+)/>
+     SetHandler "proxy:unix:/var/run/app_%{env:MATCH_sub}.sock|fcgi://localhost:8080"
+</LocationMatch>
+ + +

Vous pouvez écraser la définition antérieure d'une directive + SetHandler en utilisant la valeur + 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é.

+ +

Voir aussi

+ +
+
top
+

Directive SetInputFilter

+ + + + + + + +
Description:Définit les filtres par lesquels vont passer les requêtes +client et les données POST
Syntaxe:SetInputFilter filtre[;filtre...]
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:FileInfo
Statut:Noyau httpd
Module:core
+

La directive SetInputFilter permet de + définir le ou les filtres par lesquels vont passer les requêtes + client et les données POST au moment où le serveur les reçoit. Cette + définition vient en ajout à tout autre filtre défini en + quelqu'endroit que ce soit, y compris via la directive AddInputFilter.

+ +

Si la directive comporte plusieurs filtres, ils doivent être + séparés par des points-virgules, et spécifiés selon l'ordre dans + lequel vous souhaitez les voir agir sur les contenus.

+ +

Voir aussi

+ +
+
top
+

Directive SetOutputFilter

+ + + + + + + +
Description:Définit les filtres par lesquels vont passer les réponses +du serveur
Syntaxe:SetOutputFilter filtre[;filtre...]
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:FileInfo
Statut:Noyau httpd
Module:core
+

La directive SetOutputFilter permet de + définir les filtres par lesquels vont passer les réponses du serveur + avant d'être envoyées au client. Cette définition vient en ajout à + tout autre filtre défini en quelqu'endroit que ce soit, y compris + via la directive AddOutputFilter.

+ +

Par exemple, la configuration suivante va traiter tous les + fichiers du répertoire /www/data/ comme des inclusions + côté serveur (SSI) :

+ +
<Directory "/www/data/">
+  SetOutputFilter INCLUDES
+</Directory>
+ + +

Si la directive comporte plusieurs filtres, ils doivent être + séparés par des points-virgules, et spécifiés selon l'ordre dans + lequel vous souhaitez les voir agir sur les contenus.

+ +

Voir aussi

+ +
+
top
+

Directive StrictHostCheck

+ + + + + + + + +
Description:Détermine si le nom d'hôte contenu dans une requête doit être +explicitement spécifié au niveau du serveur virtuel qui a pris en compte cette +dernière. +
Syntaxe:StrictHostCheck ON|OFF
Défaut:StrictHostCheck OFF
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
Compatibilité:Disponible à partir de la version 2.4.49 du serveur HTTP Apache.
+

Par défaut, le serveur répond aux requêtes quel que soit le nom d'hôte + qu'elles contiennent, y compris un nom d'hôte non prévu dans la + configuration. Bien que cela soit pratique, il peut s'avérer souhaitable de + restreindre les noms d'hôte qu'une application sous-jacente devra prendre en + compte car elle va souvent générer des réponses en se référençant elle-même.

+ +

Si la directive StrictHostCheck est définie à + ON, le serveur générera une erreur HTTP 400 si le nom d'hôte que + contient la requête n'a pas été explicitement spécifié par une directive + ServerName ou ServerAlias au niveau du serveur virtuel qui + correspond le mieux aux caractéristiques de la connexion entrante.

+ +

Cette directive permet aussi de rechercher une correspondance entre le nom + d'hôte de la requête et les noms d'hôte spécifiés au sein de la balise + ouvrante VirtualHost. Il s'agit + cependant d'un mécanisme de configuration relativement obscur qui agit comme + une directive ServerAlias + supplémentaire.

+ +

Cette directive n'a aucun effet dans les serveurs virtuels qui ne sont pas + des serveurs par défaut. La valeur héritée de la configuration globale du + serveur ou le serveur virtuel par défaut pour l'adresse IP/port de la + connexion sous-jacente déterminent la valeur effective.

+ +
+
top
+

Directive TimeOut

+ + + + + + + +
Description:Temps pendant lequel le serveur va attendre certains +évènements avant de considérer qu'une requête a échoué
Syntaxe:TimeOut secondes
Défaut:TimeOut 60
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
+

La directive TimeOut permet de définir le + temps maximum pendant lequel Apache httpd va attendre des entrées/sorties + selon les circonstances :

+ +
    +
  • Lors de la lecture de données en provenance du client, le + temps maximum jusqu'à l'arrivée d'un paquet TCP si le tampon est + vide.

    +

    Pour les données initiales d'une nouvelle connexion, et tant qu'une + directive AcceptFilter n'aura pas + transmis cette nouvelle connexion au serveur, cette directive n'aura aucun + effet.

    +
  • + +
  • Lors de l'écriture de données destinées au client, le temps + maximum jusqu'à l'arrivée de l'accusé-réception d'un paquet si le + tampon d'envoi est plein.
  • + +
  • Avec mod_cgi et mod_cgid, le temps + d'attente maximum pour un bloc individuel en sortie d'un script CGI.
  • + +
  • Avec mod_ext_filter, le temps d'attente + maximum des sorties d'un processus de filtrage.
  • + +
  • Avec mod_proxy, la valeur du délai par défaut + si ProxyTimeout n'est + pas défini.
  • +
+ + +
+
top
+

Directive TraceEnable

+ + + + + + + +
Description:Détermine le comportement des requêtes +TRACE
Syntaxe:TraceEnable [on|off|extended]
Défaut:TraceEnable on
Contexte:configuration globale, serveur virtuel
Statut:Noyau httpd
Module:core
+

Cette directive l'emporte sur le comportement de + TRACE pour le noyau du serveur et + mod_proxy. La définition par défaut + TraceEnable on permet des requêtes TRACE + selon la RFC 2616, qui interdit d'ajouter tout corps à la requête. + La définition TraceEnable off indique au noyau du + serveur et à mod_proxy de retourner un code + d'erreur 405 (Méthode non autorisée) au client.

+ +

En fait, et à des fins de test et de diagnostic seulement, on + peut autoriser l'ajout d'un corps de requête à l'aide de la + définition non standard TraceEnable extended. Le noyau + du serveur (dans le cas d'un serveur d'origine) va limiter la taille + du corps de requête à 64Kb (plus 8Kb pour les en-têtes de + fractionnement si Transfer-Encoding: chunked 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 à 64Kb.

+ +

Note

+

Bien que certains prétendent le contraire, activer la méthode + TRACE ne constitue pas un problème de sécurité dans Apache + httpd. La méthode TRACE est définie par la spécification + HTTP/1.1 et les différentes implémentations sont censées la supporter.

+
+ +
+
top
+

Directive UnDefine

+ + + + + + +
Description:Invalide la définition d'une variable
Syntaxe:UnDefine nom-variable
Contexte:configuration globale
Statut:Noyau httpd
Module:core
+

Annule l'effet d'une directive Define ou d'un argument -D de + httpd en invalidant l'existence de la variable + correspondante.

+

On peut utiliser cette directive pour inverser l'effet d'une + section <IfDefine> + sans avoir à modifier les arguments -D dans les scripts + de démarrage.

+ +

Afin d'éviter tout risque de collision avec la syntaxe de la directive + RewriteMap, les noms de + variables ne doivent pas contenir de caractère ":".

+ +

Piège de la portée de cette directive

+

Si cette directive est définie au sein d'un bloc VirtualHost, les + changements qu'elle induit sont visibles de toute directive + ultérieure, au delà de tout bloc VirtualHost.

+
+ +

Voir aussi

+ +
+
top
+

Directive UseCanonicalName

+ + + + + + + +
Description:Définit la manière dont le serveur détermine son propre nom +et son port
Syntaxe:UseCanonicalName On|Off|DNS
Défaut:UseCanonicalName Off
Contexte:configuration globale, serveur virtuel, répertoire
Statut:Noyau httpd
Module:core
+

Dans de nombreuses situations, Apache httpd doit construire une URL + auto-identifiante -- c'est à dire une URL qui fait + référence au serveur lui-même. Avec UseCanonicalName + On, Apache httpd va utiliser le nom d'hôte et le port spécifiés par + la directive ServerName pour + construire le nom canonique du serveur. Ce nom est utilisé dans + toutes les URLs auto-identifiantes, et affecté aux variables + SERVER_NAME et SERVER_PORT dans les + programmes CGI.

+ +

Avec UseCanonicalName Off, Apache httpd va construire ses + URLs auto-identifiantes à l'aide du nom d'hôte et du port fournis + par le client, si ce dernier en a fourni un (dans la négative, + Apache utilisera le nom canonique, de la même manière que + ci-dessus). Ces valeurs sont les mêmes que celles qui sont utilisées + pour implémenter les serveurs virtuels à base de + nom, et sont disponibles avec les mêmes clients. De même, les + variables CGI SERVER_NAME et SERVER_PORT + seront affectées des valeurs fournies par le client.

+ +

Cette directive peut s'avérer utile, par exemple, sur un serveur + intranet auquel les utilisateurs se connectent en utilisant des noms + courts tels que www. Si les utilisateurs tapent un nom + court suivi d'une URL qui fait référence à un répertoire, comme + http://www/splat, sans le slash terminal, vous + remarquerez qu'Apache httpd va les rediriger vers + http://www.example.com/splat/. Si vous avez activé + l'authentification, ceci va obliger l'utilisateur à s'authentifier + deux fois (une première fois pour www et une seconde + fois pour www.example.com -- voir la + foire aux questions sur ce sujet pour plus d'informations). + Par contre, si UseCanonicalName est définie à + Off, Apache httpd redirigera l'utilisateur vers + http://www/splat/.

+ +

Pour l'hébergement virtuel en masse à base d'adresse IP, on + utilise une troisième option, UseCanonicalName + DNS, pour supporter les clients anciens qui ne + fournissent pas d'en-tête Host:. Apache httpd effectue alors + une recherche DNS inverse sur l'adresse IP du serveur auquel le + client s'est connecté afin de construire ses URLs + auto-identifiantes.

+ +

Avertissement

+

Les programmes CGI risquent d'être perturbés par cette option + s'ils tiennent compte de la variable SERVER_NAME. Le + client est pratiquement libre de fournir la valeur qu'il veut comme + nom d'hôte. Mais si le programme CGI n'utilise + SERVER_NAME que pour construire des URLs + auto-identifiantes, il ne devrait pas y avoir de problème.

+
+ +

Voir aussi

+ +
+
top
+

Directive UseCanonicalPhysicalPort

+ + + + + + + +
Description:Définit la manière dont le serveur +détermine son propre port
Syntaxe:UseCanonicalPhysicalPort On|Off
Défaut:UseCanonicalPhysicalPort Off
Contexte:configuration globale, serveur virtuel, répertoire
Statut:Noyau httpd
Module:core
+

Dans de nombreuses situations, Apache httpd doit construire une URL + auto-identifiante -- c'est à dire une URL qui fait + référence au serveur lui-même. Avec UseCanonicalPhysicalPort + On, Apache httpd va fournir le numéro de port physique réel utilisé + par la requête en tant que port potentiel, pour construire le port + canonique afin que le serveur puisse alimenter la directive + UseCanonicalName. Avec + UseCanonicalPhysicalPort Off, Apache httpd n'utilisera pas le + numéro de port physique réel, mais au contraire se référera aux + informations de configuration pour construire un numéro de port + valide.

+ +

Note

+

L'ordre dans lequel s'effectue la recherche quand on utilise le + port physique est le suivant :

+
+
UseCanonicalName On
+
+
    +
  1. Port indiqué dans Servername
  2. +
  3. Port physique
  4. +
  5. Port par défaut
  6. +
+
+
UseCanonicalName Off | DNS
+
+
    +
  1. Port spécifié dans l'en-tête Host:
  2. +
  3. Port physique
  4. +
  5. Port spécifié par Servername
  6. +
  7. Port par défaut
  8. +
+
+
+ +

Avec UseCanonicalPhysicalPort Off, on reprend + l'ordre ci-dessus en supprimant "Port physique".

+
+ + +

Voir aussi

+ +
+
top
+

Directive <VirtualHost>

+ + + + + + +
Description:Contient des directives qui ne s'appliquent qu'à un nom +d'hôte spécifique ou à une adresse IP
Syntaxe:<VirtualHost + adresse IP[:port] [adresse + IP[:port]] ...> ... + </VirtualHost>
Contexte:configuration globale
Statut:Noyau httpd
Module:core
+

Les balises <VirtualHost> et + </VirtualHost> permettent de rassembler un groupe + de directives qui ne s'appliquent qu'à un serveur virtuel + particulier. Toute directive autorisée dans un contexte de serveur + virtuel peut être utilisée. Lorsque le serveur reçoit un requête + pour un document hébergé par un serveur virtuel particulier, il + applique les directives de configuration rassemblées dans la section + <VirtualHost>. adresse + IP peut être une des entités suivantes, éventuellement suivies + d'un caractère ':' et d'un numéro de port (ou *) :

+ +
    +
  • L'adresse IP du serveur virtuel ;
  • + +
  • Un nom de domaine entièrement qualifié correspondant à + l'adresse IP du serveur virtuel (non recommandé) ;
  • + +
  • Le caractère *, qui agit comme un + caractère générique, et correspond à toute adresse IP.
  • + +
  • La chaîne _default_, dont la signification est + identique à celle du caractère *
  • + +
+ +
<VirtualHost 10.1.2.3:80>
+  ServerAdmin webmaster@host.example.com
+  DocumentRoot "/www/docs/host.example.com"
+  ServerName host.example.com
+  ErrorLog "logs/host.example.com-error_log"
+  TransferLog "logs/host.example.com-access_log"
+</VirtualHost>
+ + + +

Les adresses IPv6 doivent être entourées de crochets car dans le + cas contraire, un éventuel port optionnel ne pourrait pas être + déterminé. Voici un exemple de serveur virtuel avec adresse IPv6 + :

+ +
<VirtualHost [2001:db8::a00:20ff:fea7:ccea]:80>
+  ServerAdmin webmaster@host.example.com
+  DocumentRoot "/www/docs/host.example.com"
+  ServerName host.example.com
+  ErrorLog "logs/host.example.com-error_log"
+  TransferLog "logs/host.example.com-access_log"
+</VirtualHost>
+ + +

Chaque serveur virtuel doit correspondre à une adresse IP, un + port ou un nom d'hôte spécifique ; dans le premier cas, le serveur + doit être configuré pour recevoir les paquets IP de plusieurs + adresses (si le serveur n'a qu'une interface réseau, on peut + utiliser à cet effet la commande ifconfig alias -- si + votre système d'exploitation le permet).

+ +

Note

+

L'utilisation de la directive <VirtualHost> n'affecte en rien les + adresses IP sur lesquelles Apache httpd est en écoute. Vous devez vous + assurer que les adresses des serveurs virtuels sont bien incluses + dans la liste des adresses précisées par la directive Listen.

+
+ +

Tout bloc <VirtualHost> doit comporter une directive + ServerName. Dans le cas + contraire, le serveur virtuel héritera de la valeur de la directive + ServerName issue de la + configuration du serveur principal.

+ +

A l'arrivée d'une requête, le serveur tente de la + faire prendre en compte par la section <VirtualHost> qui correspond le mieux en ne + se basant que sur la paire adresse IP/port. Les chaînes sans + caractères génériques l'emportent sur celles qui en contiennent. Si + aucune correspondance du point de vue de l'adresse IP/port n'est + trouvée, c'est la configuration du serveur "principal" qui sera + utilisée.

+ +

Si plusieurs serveurs virtuels correspondent du point de vue de + l'adresse IP/port, le serveur sélectionne celui qui correspond le + mieux du point de vue du nom d'hôte de la requête. Si aucune + correspondance du point de vue du nom d'hôte n'est trouvée, c'est le + premier serveur virtuel dont l'adresse IP/port correspond qui sera + utilisé. Par voie de conséquence, le premier serveur virtuel + comportant une certaine paire adresse IP/port est le serveur virtuel + par défaut pour cette paire adresse IP/port.

+ +

Sécurité

+

Voir le document sur les conseils à propos de sécurité + pour une description détaillée des raisons pour lesquelles la + sécurité de votre serveur pourrait être compromise, si le répertoire + contenant les fichiers journaux est inscriptible par tout autre + utilisateur que celui qui démarre le serveur.

+
+ +

Voir aussi

+ +
+
+
+

Langues Disponibles:  de  | + en  | + es  | + fr  | + ja  | + tr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file -- cgit v1.2.3