Fonctionalit�s de Base Apache

AcceptFilter Directive

Cette directive permet d'effectuer une optimisation du 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 et le filtre plus primitif TCP_DEFER_ACCEPT sous Linux sont actuellement support�s.

Sous FreeBSD, les valeurs par d�faut sont :

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 :

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

L'utilisation de la valeur none comme argument d�sactive tout filtre d'acceptation pour ce protocole. Elle peut �tre utile dans le cas d'un protocole pour lequel un serveur doit d'abord envoyer des donn�es, comme nntp :

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, comme cgi-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 :

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 :

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

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 MIME. Par exemple :

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

AddOutputFilterByType Directive

Cette directive active un filtre en sortie particulier pour une requ�te en fonction du type MIME de la r�ponse. Suite � certains probl�mes �voqu�s plus loin, cette directive a �t� abandonn�e. Le m�me r�sultat peut �tre obtenu � l'aide du module mod_filter.

L'exemple suivant active le filtre DEFLATE qui est fourni par le module mod_deflate. Il va compresser toute sortie dont le type MIME est text/html ou text/plain avant de l'envoyer au client.

Si vous voulez assigner plusieurs filtres au contenu, leurs noms doivent �tre s�par�s par des points-virgules. On peut aussi utiliser une directive AddOutputFilterByType pour chacun des filtres � assigner.

La configuration ci-dessous impose le traitement de toute sortie de script dont le type MIME est text/html en premier lieu par le filtre INCLUDES, puis par le filtre DEFLATE.

Voir aussi

• AddOutputFilter
• SetOutputFilter
• Les filtres

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 est d�finie � 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 DefaultType, ErrorDocument, ForceType, LanguagePriority, SetHandler, SetInputFilter, SetOutputFilter, et directives du module mod_mime Add* et Remove*, etc...), des metadonn�es des documents (Header, RequestHeader, SetEnvIf, SetEnvIfNoCase, BrowserMatch, CookieExpires, CookieDomain, CookieStyle, CookieTracking, CookieName), des directives du module mod_rewrite (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).

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.

Exemple :

Dans l'exemple ci-dessus, toutes les directives qui ne font partie ni du groupe AuthConfig, ni du groupe Indexes, provoquent une "internal server error".

Voir aussi

• AccessFileName
• Fichiers de Configuration
• Fichiers .htaccess

AuthName Directive

Cette directive permet de d�finir l'identificateur d'autorisation pour un r�pertoire. Cet identificateur est fourni au client afin que ce dernier sache quels nom d'utilisateur et mot de passe envoyer. AuthName n'accepte qu'un seul argument ; si l'identificateur contient des espaces, il doit �tre entour� d'apostrophes. Il doit �tre associ� � des directives AuthType et Require, ainsi qu'� des directives telles que AuthUserFile et AuthGroupFile pour pouvoir fonctionner.

Par exemple :

La cha�ne de caract�res d�finie par la directive AuthName correspond � celle que la plupart des navigateurs vont fournir dans la bo�te de dialogue de saisie du mot de passe.

Voir aussi

• Authentification, Autorisation, et contr�le d'acc�s

AuthType Directive

Cette directive permet de d�finir le type d'authentification de l'utilisateur pour un r�pertoire. Les types d'authentification disponibles sont Basic (impl�ment� par mod_auth_basic), et Digest (impl�ment� par mod_auth_digest).

Pour que l'authentification fonctionne, vous devez aussi d�finir les directives AuthName et Require. En outre, le serveur doit avoir � sa disposition un module fournisseur d'authentification tel que mod_authn_file et un module d'autorisation tel que mod_authz_user.

Voir aussi

• Authentification et autorisation
• Tutoriel du contr�le d'acc�s

CGIMapExtension Directive

Cette directive permet de contr�ler la mani�re dont Apache 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.

DefaultType Directive

Il peut arriver que le serveur doive servir un document dont il ne peut pas d�terminer le type � partir de sa table de types MIME.

Le serveur DEVRAIT fournir au client le type de contenu du document. Si le serveur n'est pas capable de le d�terminer par la voie normale, il fournira le type d�fini par la directive DefaultType. Par exemple :

conviendra pour un r�pertoire contenant de nombreuses images GIF dont le fichier ne comporte pas l'extension .gif.

Dans les cas o� ni le serveur, ni l'administrateur (ou un serveur mandataire) ne sont en mesure de d�terminer le type du document, il est pr�f�rable de ne pas le mentionner, plut�t que de fournir de fausses informations. � cet effet, on utilise

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

Notez qu'� la diff�rence de la directive ForceType, cette directive ne d�finit que le type MIME par d�faut. Toute autre d�finition de type MIME, y compris l'extension des noms de fichiers, susceptible de permettre d'identifier le type de m�dia l'emportera sur la valeur par d�faut.

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

Les Expressions rationnelles peuvent aussi �tre utilis�es en ajoutant le caract�re ~. Par exemple :

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

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

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

Notez que pour Apache, la politique d'acc�s par d�faut dans les sections <Directory /> est Allow from All. Ceci signifie qu'Apache va servir tout fichier correspondant � une URL. Il est recommand� de modifier cette situation � l'aide d'un bloc du style

puis d'affiner la configuration pour les r�pertoires que vous voulez rendre accessibles. Voir la page Conseils � propos de la s�curit� pour plus de d�tails.

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

Voir aussi

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

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

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 :

un acc�s � http://www.my.host.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 terminal.

Voir aussi

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

EnableMMAP Directive

Cette directive d�finit si httpd peut utiliser la projection en m�moire (Memory-Mapping) s'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 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. Cependant, sur certains syst�mes, 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.
• La suppression ou la troncature d'un fichier faisant l'objet d'une image en m�moire 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 :

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

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 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 plateforme Itanium, sendfile peut s'av�rer r.{1,2}pertoireincapable de traiter les fichiers de plus de 2 Go.
• Avec un montage r�seau de DocumentRoot (par exemple NFS ou SMB), 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 sujettes � ce genre de probl�me, il est recommand� de d�sactiver cette fonctionnalit� en sp�cifiant :

Pour les montages NFS ou SMB, cette fonctionnalit� peut �tre explicitement d�sactiv�e pour les fichiers concern�s en sp�cifiant :

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_disk_cache. Le module ne prend en compte la d�finition de EnableSendfile que dans un contexte global.

ErrorDocument Directive

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

De plus, on peut sp�cifier la valeur sp�ciale default pour indiquer l'utilisation d'un simple message d'Apache 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 cod� en dur pour les configurations qui sans cela, h�riteraient d'une directive ErrorDocument existante.

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), 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 ces 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 ne g�n�rera pas de messages d'erreur personnalis�s pour le contenu mandat�.

Avant la version 2.0, les messages �taient indiqu�s en les pr�fixant par un seul caract�re guillemet isol�.

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�re comme relatif au chemin d�fini par la directive ServerRoot.

Si le chemin fichier commence par une barre verticale "|", il est consid�r� comme une commande � lancer pour traiter la journalisation de l'erreur.

Voir les notes � propos des journaux redirig�s pour plus de d�tails.

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

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 d'Apache

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). Dans les versions 1.3.22 et ant�rieures d'Apache, la valeur de l'en-t�te ETag se composait toujours de l'inode du fichier, de sa taille et de sa date de derni�re modification (mtime). La directive FileETag vous permet d�sormais de choisir quelles caract�ristiques du fichier vont �tre �ventuellement utilis�es. 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 les directives s'appliquant 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 :

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 :

correspondrait � la plupart des formats graphiques de l'Internet.

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

Notez qu'� la diff�rence de DefaultType, cette directive l'emporte sur toute m�thode d'attribution du type MIME, y compris les extensions de nom de fichier, qui parviendrait � identifier le type de m�dium.

Vous pouvez annuler toute autre d�finition ForceType en affectant la valeur None � l'argument type MIME :

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

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

La d�finition de l'argument nom param�tre s'effectue au niveau de la ligne de commande httpd via le param�tre -Dparam�tre au d�marrage du serveur.

Les sections <IfDefine> peuvent �tre imbriqu�es, ce qui permet de mettre en oeuvre un test multi-param�tres simple. Exemple :

<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 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()) dans le nom du fichier ou la partie r�pertoire 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 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. Nous vous recommandons plut�t d'utiliser la syntaxe avec caract�res g�n�riques vue ci-dessous pour inclure des fichiers dont le nom correspond � un mod�le particulier, comme *.conf par exemple.

Lorsqu'on utilise un caract�re g�n�rique dans le nom de fichier ou la partie r�pertoire du chemin, et si aucun fichier ou r�pertoire ne correspond au mod�le, la directive Include sera silencieusement ignor�e. Si un nom de fichier ou un r�pertoire du chemin est sp�cifi� sans caract�re g�n�rique, et si ce r�pertoire ou fichier n'existe pas, la directive Include �chouera et renverra un message d'erreur indiquant que le r�pertoire ou fichier n'a pas pu �tre trouv�. Il devient ainsi inutile de cr�er des fichiers fictifs destin�s � correspondre par d�faut � un chemin contenant des caract�res g�n�riques.

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 :

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

Voir aussi

• apachectl

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 MaxRequestsPerChild, quel que soit le nombre de requ�tes transmises via cette connexion.

Voir aussi

• MaxKeepAliveRequests

KeepAliveTimeout Directive

Le nombre de secondes pendant lesquelles Apache va attendre une requ�te avant de fermer la connexion. 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 le d�lai du premier serveur virtuel d�fini (le serveur par d�faut) parmi un ensemble de directives NameVirtualHost qui sera utilis�. Les autres valeurs seront ignor�es.

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

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.

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

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

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

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'un chemin d'url). 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 :

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

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

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 :

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 :

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

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.

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 �galement utiliser les Expressions rationnelles, moyennant l'addition d'un caract�re ~. Par exemple :

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

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 :

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 :

correspondrait � toute URL contenant les sous-cha�nes /extra/data ou /special/data.

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 :

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 :

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

La documentation de cette directive n'a pas encore t traduite. Veuillez vous reporter la version en langue anglaise.

NameVirtualHost Directive

La directive NameVirtualHost est obligatoire si vous envisagez de configurer des serveurs virtuels par nom.

Bien que adresse puisse �tre un nom d'h�te, il est recommand� d'utiliser plut�t une adresse IP et un port, dans le style

La directive NameVirtualHost vous permet de sp�cifier l'adresse IP sur laquelle le serveur recevra des requ�tes pour des serveurs virtuels bas�s sur le nom. Il s'agit en g�n�ral de l'adresse � laquelle correspondent vos noms de serveurs virtuels bas�s sur le nom. Dans le cas o� un par-feu ou autre mandataire re�oit les requ�tes et les fait suivre au serveur avec une adresse IP diff�rente, vous devez sp�cifier l'adresse IP de l'interface physique du serveur qui traite les requ�tes. Si vous avez plusieurs serveurs virtuels bas�s sur le nom avec plusieurs adresses, utilisez une directive pour chaque adresse.

Vous pouvez �galement ajouter un num�ro de port sur lequel les serveurs virtuels bas�s sur le nom r�pondront, comme

Les adresses IPv6 doivent �tre entour�es de crochets, comme dans l'exemple suivant :

Pour recevoir les requ�tes sur toutes les interfaces, vous pouvez utiliser comme argument *:80, ou * dans le cas o� vous �coutez sur plusieurs ports et souhaitez vraiment que le serveur r�ponde sur chacun d'entre eux avec un jeu de serveurs virtuels particulier.

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�e MultiViews. il s'agit de la configuration par d�faut.

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

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

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

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

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

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 :

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

Voir aussi

• AcceptFilter
• Listen

Require Directive

Cette directive permet de d�terminer les utilisateurs authentifi�s autoris�s � acc�der � une ressource. De multiples instances de cette directive se combinent entre elles avec un "OU" logique, si bien qu'un utilisateur qui convient � une ligne Require re�oit l'autorisation d'acc�s. Les restrictions sont trait�es par les modules d'autorisation. Voici quelques exemples de syntaxes autoris�es par mod_authz_user et mod_authz_groupfile :

Require user identifiant_utilisateur [identifiant_utilisateur] ...

Seuls les utilisateurs sp�cifi�s peuvent acc�der � la ressource.

Require group nom_groupe [nom_groupe] ...

Seuls les utilisateurs appartenant aux groupes sp�cifi�s peuvent acc�der � la ressource.

Require valid-user

Tout utilisateur valide peut acc�der � la ressource.

D'autres modules d'autorisation comme mod_authnz_ldap, mod_authz_dbm, et mod_authz_owner impl�mentent les options de la directive Require.

La directive Require doit �tre associ�e aux directives AuthName et AuthType, ainsi qu'� des directives telles que AuthUserFile et AuthGroupFile (pour la d�finition des utilisateurs et des groupes) afin de pouvoir fonctionner correctement. Exemple :

Les contr�les d'acc�s appliqu�s de cette mani�re sont effectifs pour toutes les m�thodes HTTP. C'est en g�n�ral ce que l'on souhaite. Si vous d�sirez n'appliquer les contr�les d'acc�s que pour certaines m�thodes, tout en laissant les autres m�thodes sans protection, vous devez placer la directive Require � l'int�rieur d'une section <Limit>.

Si la directive Require est utilis�e conjointement avec les directives Allow ou Deny, l'interaction entre les diff�rentes restrictions impos�es est contr�l�e par la directive Satisfy.

Voir aussi

• Authentification et autorisation
• Tutoriel du contr�le d'acc�s
• Satisfy
• mod_authz_host

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 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 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 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 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 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 comme les journalisations redirig�es vers un programme.

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

Voir aussi

• RLimitMEM
• RLimitCPU

Satisfy Directive

Cette directive permet de d�finir la politique d'acc�s lorsque les directives Allow et Require sont utilis�es conjointement. L'argument prend pour valeur All ou Any. Cette directive ne s'av�re utile que dans le cas o� l'acc�s � une zone particuli�re est contr�l� � la fois par une authentification utilisateur/mot de passe et par l'adresse IP du client. Avec la valeur par d�faut de l'argument (All), le client doit d'abord satisfaire � la condition d'acc�s en fonction de son adresse IP, puis fournir un couple utilisateur/mot de passe valide. Si l'argument est Any, le client se verra accorder l'acc�s s'il satisfait � au moins une des conditions d'acc�s : adresse IP et/ou un couple utilisateur/mot de passe valides. On peut utiliser cette valeur pour restreindre l'acc�s � une zone � l'aide d'un mot de passe, mais laisser cette zone en acc�s libre pour les clients poss�dant certaines adresses IP.

Par exemple, si vous souhaitez accorder un acc�s sans restriction � une portion de votre site web aux clients de votre r�seau, mais n'accorder cet acc�s aux clients � l'ext�rieur de votre r�seau qu'en �change d'un mot de passe, vous pouvez utiliser une configuration de ce style :

Depuis la version 2.0.51, les directives Satisfy peuvent �tre limit�es � certaines m�thodes particuli�res � l'aide des sections <Limit> et <LimitExcept>.

Voir aussi

• Allow
• Require

ScriptInterpreterSource Directive

Cette directive permet de contr�ler la m�thode qu'utilise Apache pour trouver l'interpr�teur destin� � ex�cuter les scripts CGI. La d�finition par d�faut est Script : ceci indique � Apache 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 :

ou simplement, dans le cas o� perl est dans le PATH :

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 utilise la m�thode de l'option Script.

Par exemple, pour que les scripts poss�dant l'extension .pl soient trait�s par perl, la ligne du registre doit �tre :

L'option Registry-Strict, apparue avec Apache 2.0, 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.

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 :

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.

La recherche du serveur virtuel � base de nom qui correspond le mieux s'effectue selon l'ordre d'apparition des sections <virtualhost> dans le fichier de configuration. Le premier serveur virtuel dont le ServerName ou le ServerAlias correspond est choisi, sans pr�f�rence si le nom contient des caract�res g�n�riques ou pas.

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 d'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 par 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 :

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 Apache
• Documentation sur les serveurs virtuels d'Apache
• UseCanonicalName
• UseCanonicalPhysicalPort
• NameVirtualHost
• 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 d'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.

Voir aussi

• the -d options de httpd
• les conseils � propos de la 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.

Depuis 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 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.0

ServerTokens Min[imal]

Le serveur renvoie (par exemple): Server: Apache/2.0.41

ServerTokens OS

Le serveur renvoie (par exemple): Server: Apache/2.0.41 (Unix)

ServerTokens Full (valeur par d�faut)

Le serveur renvoie (par exemple): Server: Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2

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 �galement 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 :

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

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

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

Suexec Directive

Lorsque cette directive est d�finie � On, le d�marrage du serveur �chouera si le binaire suexec n'existe pas, ou poss�de un mode de fichier ou un propri�taire invalides.

Lorsque cette directive est d�finie � Off, la fonctionnalit� suEXEC est d�sactiv�e, m�me si le binaire suexec existe et poss�de un mode de fichier et un propri�taire valides.

TimeOut Directive

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

1. Lors de la lecture de donn�es en provenance du client, le temps maximum d'attente avant l'arriv�e d'un paquet TCP si le tampon de lecture est vide.
2. Lors de l'envoi de donn�es vers le client, le temps maximum d'attente avant l'arriv�e de l'accus�-r�ception d'un paquet si le tampon d'envoi est plein.
3. Avec mod_cgi, le temps maximum d'attente avant la sortie des donn�es d'un script CGI.
4. Avec mod_ext_filter, le temps maximum d'attente avant la sortie des donn�es d'un processus de filtrage.
5. Avec mod_proxy, la valeur du d�lai par d�faut si la directive ProxyTimeout n'a pas �t� d�finie.

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.

UseCanonicalName Directive

Dans de nombreuses situations, Apache 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 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 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 par 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 va les rediriger vers http://www.domain.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.domain.com -- voir la foire aux questions sur ce sujet pour plus d'informations). Par contre, si UseCanonicalName est d�finie � Off, Apache redirigera l'utilisateur vers http://www/splat/.

Pour l'h�bergement virtuel en masse par 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 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 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 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 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 :

• 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 n'est utilis� qu'en combinaison avec NameVirtualHost * pour intercepter toutes les adresses IP ; ou
• La cha�ne de caract�res _default_, qui n'est utilis�e qu'avec l'h�bergement virtuel � base d'adresse IP pour intercepter les adresses IP qui ne correspondent � aucun serveur virtuel.

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 :

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

Avec l'h�bergement virtuel � base d'adresse IP, on peut utiliser le nom sp�cial _default_, auquel cas le serveur virtuel consid�r� interceptera toute adresse IP qui n'est pas explicitement associ�e � un autre serveur virtuel. En l'absence de serveur virtuel associ� � _default_, et si l'adresse IP demand�e ne correspond � aucun serveur virtuel, c'est la configuration du serveur "principal" qui sera utilis�e, c'est � dire l'ensemble des d�finitions situ�es en dehors de toute section VirtualHost (Notez cependant que toute adresse IP correspondant � une directive NameVirtualHost n'utilisera ni la configuration du serveur "principal", ni le serveur virtuel _default_. Voir la documentation de l'h�bergement virtuel par nom pour plus de d�tails).

Vous pouvez sp�cifier :port pour modifier le port du serveur virtuel. S'il n'est pas sp�cifi�, sa valeur par d�faut correspond � celle qui est d�finie par la derni�re directive Listen du serveur principal. Vous pouvez aussi sp�cifier :* pour accepter tous les ports associ�s � l'adresse du serveur virtuel (c'est une configuration recommand�e lorsqu'on utilise _default_).

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.

Voir aussi

• Documentation des serveurs virtuels d'Apache
• Probl�mes concernant DNS et Apache
• D�finition des adresses et ports qu'utilise 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