Fonctionalit�s de Base Apache

AcceptFilter Directive

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 data
AcceptFilter https data

Le module MPM pour Windows mpm_winnt utilise la directive AcceptFilter comme commutateur de l'API AcceptEx(), et ne supporte pas la mise en tampon du protocole http. Deux valeurs utilisent l'API Windows AcceptEx() et vont recycler les sockets r�seau entre les connexions. data attend jusqu'� ce que les donn�es aient �t� transmises comme d�crit plus haut, et le tampon de donn�es initiales ainsi que les adresses r�seau finales sont tous extraits gr�ce � une seule invocation d'AcceptEx(). 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.

Voir aussi

• Protocol

AcceptPathInfo Directive

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>

AccessFileName Directive

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

• AllowOverride
• Fichiers de configuration
• Fichiers .htaccess

AddDefaultCharset Directive

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

• AddCharset

AllowEncodedSlashes Directive

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.

Voir aussi

• AcceptPathInfo

AllowOverride Directive

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

Lorsque 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 :

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

Voir aussi

• AccessFileName
• AllowOverrideList
• Fichiers de configuration
• Fichiers .htaccess

AllowOverrideList Directive

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.

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

• AccessFileName
• AllowOverride
• Fichiers de configuration
• Fichiers .htaccess

CGIMapExtension Directive

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.

ContentDigest Directive

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 :

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.

DefaultRuntimeDir Directive

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

• Voir les conseils � propos de s�surit� pour plus d'informations en vue de d�finir correctement les permissions sur la racine du serveur ServerRoot

DefaultType Directive

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.

Define Directive

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.

<Directory> Directive

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 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 apache2.conf. Les directives <Directory> ne peuvent pas �tre imbriqu�es et ne sont pas autoris�es dans les sections <Limit> ou <LimitExcept>.

Voir aussi

• Comment fonctionnent les sections <Directory>, <Location> et <Files> pour des explications � propos de la mani�re dont ces diff�rentes sections se combinent entre elles � la r�ception d'une requ�te

<DirectoryMatch> Directive

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>

conviendrait pour les sous-r�pertoires de /www/ dont le nom se compose de trois chiffres.

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

• <Directory> pour une description de la mani�re dont les expressions rationnelles sont trait�es en pr�sence d'autres sections <Directory> sans expressions rationnelles
• Comment fonctionnent les sections <Directory>, <Location> et <Files> pour une explication � propos de la mani�re dont ces diff�rentes sections se combinent entre elles � la r�ception d'une requ�te

DocumentRoot Directive

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

• Mise en correspondance des URLs avec le syst�me de fichiers

<Else> Directive

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

• <If>
• <ElseIf>
• Fonctionnement des sections <Directory>, <Location>, <Files> pour une explication de la mani�re dont ces diff�rentes section se combinent entre elles lorsqu'une requ�te est re�ue. Les directives <If>, <ElseIf>, et <Else> s'appliquent en dernier.

<ElseIf> Directive

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

• Les expressions dans le serveur HTTP Apache, pour une r�f�rence compl�te et d'autres exemples.
• <If>
• <Else>
• Fonctionnement des sections <Directory>, <Location>, <Files> pour une explication de la mani�re dont ces diff�rentes section se combinent entre elles lorsqu'une requ�te est re�ue. Les directives <If>, <ElseIf>, et <Else> s'appliquent en dernier.

EnableMMAP Directive

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>

EnableSendfile Directive

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.

Error Directive

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>

ErrorDocument Directive

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. afficher un message personnalis�
3. rediriger en interne vers un chemin d'URL local pour traiter le probl�me ou l'erreur
4. rediriger vers une URL externe pour traiter le probl�me ou l'erreur

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.

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. Exemples :

ErrorDocument 500 http://foo.example.com/cgi-bin/tester
ErrorDocument 404 /cgi-bin/bad_urls.pl
ErrorDocument 401 /subscription_info.html
ErrorDocument 403 "Sorry can't allow you access today"
ErrorDocument 403 Forbidden!

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

• documentation sur la personnalisation des r�ponses

ErrorLog Directive

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 chemin fichier 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 chemin fichier 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

ErrorLog syslog:user

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

Voir aussi

• LogLevel
• Fichiers journaux du serveur HTTP Apache

ErrorLogFormat Directive

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.

Certains items de format acceptent des param�tres suppl�mentaires entre accolades.

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 :

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] local\ %a remote\ %A"

Voir aussi

• ErrorLog
• LogLevel
• Fichiers journaux du serveur HTTP Apache

ExtendedStatus Directive

Cette option permet d'extraire des donn�es suppl�mentaires concernant la requ�te en cours de traitement pour un processus donn�, ainsi qu'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.

FileETag Directive

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

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, et Size 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.

<Files> Directive

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

• Comment fonctionnent les sections <Directory>, <Location> et <Files> pour une explication de la mani�re dont ces diff�rentes sections se combinent entre elles � la r�ception d'une requ�te

<FilesMatch> Directive

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.

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

• Comment fonctionnent les sections <Directory>, <Location> et <Files> pour une explication de la mani�re dont ces diff�rentes sections se combinent entre elles � la r�ception d'une requ�te

ForceType Directive

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.

GprofDir Directive

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.

HostnameLookups Directive

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.

<If> Directive

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.

Voir aussi

• Les expressions dans le serveur HTTP Apache, pour une r�f�rence compl�te et d'autres exemples.
• <ElseIf>
• <Else>
• Comment fonctionnent les sections <Directory>, <Location> et <Files> pour une explication de la mani�re dont ces diff�rentes sections se combinent entre elles � la r�ception d'une requ�te. Les directives <If>, <ElseIf>, et <Else> s'appliquent en dernier.

<IfDefine> Directive

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 :

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

<IfModule> Directive

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.

Include Directive

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

• IncludeOptional
• apache2ctl

IncludeOptional Directive

Cette directive permet d'inclure des fichiers dans les fichiers de configuration du serveur. Elle fonctionne de mani�re identique � la directive Include, � l'exception du fait que si l'expression avec caract�res g�n�riques wilcard ne correspond � aucun fichier ou r�pertoire, elle sera ignor�e silencieusement au lieu de causer une erreur.

Voir aussi

• Include
• apache2ctl

KeepAlive Directive

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

• MaxKeepAliveRequests

KeepAliveTimeout Directive

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.

Dans un contexte de 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.

<Limit> Directive

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

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.

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>

<LimitExcept> Directive

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

LimitInternalRecursion Directive

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

LimitRequestBody Directive

Cette directive sp�cifie la taille maximale autoris�e pour le corps d'une requ�te ; la valeur de l'argument octets va de 0 (pour une taille illimit�e), � 2147483647 (2Go). Voir la note ci-dessous pour la limite d'applicabilit� aux requ�tes mandat�es.

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

LimitRequestFields Directive

nombre est un entier de 0 (nombre de champs illimit�) � 32767. 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

LimitRequestFieldSize Directive

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

LimitRequestLine Directive

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

LimitXMLRequestBody Directive

Taille maximale (en octets) du corps d'une requ�te au format XML. Une valeur de 0 signifie qu'aucune limite n'est impos�e.

Exemple :

LimitXMLRequestBody 0

<Location> Directive

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>

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>

Voir aussi

• Comment fonctionnent les sections <Directory>, <Location> et <Files> pour une explication de la mani�re dont ces diff�rentes sections se combinent entre elles � la r�ception d'une requ�te.

<LocationMatch> Directive

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.

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>

Voir aussi

• Comment fonctionnent les sections <Directory>, <Location> et <Files> pour une explication de la mani�re dont ces diff�rentes sections se combinent entre elles � la r�ception d'une requ�te.

LogLevel Directive

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 :

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

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>

Voir aussi

• ErrorLog
• ErrorLogFormat
• Journaux du serveur HTTP Apache

MaxKeepAliveRequests Directive

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

MaxRangeOverlaps Directive

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.

MaxRangeReversals Directive

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.

MaxRanges Directive

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.

MergeTrailers Directive

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.10, o� les donn�es suppl�mentaires �taient syst�matiquement fusionn�es avec les en-t�tes de la requ�te.

Mutex Directive

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 premier argument pour modifier la configuration de tous les mutex ; sp�cifiez un nom de mutex (voir la table ci-dessous) comme premier 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

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 constitue une exception notable, en ceci qu'il fournit 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 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.

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

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

NameVirtualHost Directive

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

• Documentation sur les serveurs virtuels

Options Directive

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.

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.

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

Protocol Directive

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.

Vous ne devez d�finir le protocole que si vous travaillez avec des ports non standards ; dans le cas g�n�ral, le protocole http est associ� au port 80 et le protocole https au port 443.

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

• AcceptFilter
• Listen

RLimitCPU Directive

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

• RLimitMEM
• RLimitNPROC

RLimitMEM Directive

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

• RLimitCPU
• RLimitNPROC

RLimitNPROC Directive

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.

Voir aussi

• RLimitMEM
• RLimitCPU

ScriptInterpreterSource Directive

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.

L'option Registry-Strict, apparue avec la version 2.0 du serveur HTTP Apache, 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.

SeeRequestTail Directive

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 :

ServerAdmin Directive

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 [email protected]

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

ServerAlias Directive

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

• UseCanonicalName
• Documentation sur les serveurs virtuels du serveur HTTP Apache

ServerName Directive

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. Ceci est utile lors de la cr�ation de redirections d'URLs.

La directive ServerName permet aussi (�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.

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 en effectuant une recherche DNS inverse sur son adresse IP. 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.

Voir aussi

• Probl�mes concernant le DNS et le serveur HTTP Apache
• Documentation sur les serveurs virtuels du serveur HTTP Apache
• UseCanonicalName
• UseCanonicalPhysicalPort
• ServerAlias

ServerPath Directive

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

• Documentation sur les serveurs virtuels du serveur HTTP Apache

ServerRoot Directive

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

• the -d options de httpd
• les conseils � propos de s�curit� pour des informations sur la mani�re de d�finir correctement les permissions sur le r�pertoire indiqu� par la directive ServerRoot

ServerSignature Directive

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 (et est ainsi compatible avec le comportement des versions 1.2 et ant�rieures d'Apache). 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.

Apr�s la version 2.0.44, les d�tails � propos du num�ro de version du serveur sont contr�l�s � l'aide de la directive ServerTokens.

Voir aussi

• ServerTokens

ServerTokens Directive

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.

Dans les versions post�rieures � 2.0.44, cette directive contr�le aussi les informations fournies par la directive ServerSignature.

Voir aussi

• ServerSignature

SetHandler Directive

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

Vous pouvez �craser la d�finition ant�rieure d'une directive SetHandler en utilisant la valeur None.

Voir aussi

• AddHandler

SetInputFilter Directive

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

• documentation des Filtres

SetOutputFilter Directive

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

• Filters documentation

TimeOut Directive

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

1. 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.
2. 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.
3. Avec mod_cgi, le temps d'attente maximum des sorties d'un script CGI.
4. Avec mod_ext_filter, le temps d'attente maximum des sorties d'un processus de filtrage.
5. Avec mod_proxy, la valeur du d�lai par d�faut si ProxyTimeout n'est pas d�fini.

TraceEnable Directive

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 � 64k (plus 8k 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 � 64k.

UnDefine Directive

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.

UseCanonicalName Directive

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.

Voir aussi

• UseCanonicalPhysicalPort
• ServerName
• Listen

UseCanonicalPhysicalPort Directive

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.

Voir aussi

• UseCanonicalName
• ServerName
• Listen

<VirtualHost> Directive

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 [email protected]
  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 [email protected]
  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).

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.

Voir aussi

• Documentation des serveurs virtuels du serveur HTTP Apache
• Probl�mes concernant le DNS et le serveur HTTP Apache
• D�finition des adresses et ports qu'utilise le serveur HTTP Apache
• Comment fonctionnent les sections <Directory>, <Location> et <Files> pour une explication de la mani�re dont ces diff�rentes sections se combinent entre elles � la r�ception d'une requ�te