[APACHE DOCUMENTATION]

Apache HTTP Server Version 1.3

Noyau central d'Apache

Ces paramètres de configuration contrôlent les fonctionnalités premières d'Apache, et sont toujours disponibles.

Directives


Directive : AccessConfig

Syntaxe : AccessConfig nomfichier
Défaut : AccessConfig conf/access.conf
Contexte : configuration serveur, hôtes virtuels
Statut : core

Le serveur lit dans ce fichier des directives supplémentaires après avoir ouvert le fichier ResourceConfig. nomfichier est exprimé relativement à ServerRoot. Cette fonctionnalité peut être désactivée en écrivant :

AccessConfig /dev/null

Historiquement, ce fichier ne contient que des sections <Directory>; en fait, il pourra maintenant contenir toute directive "serveur" autorisée dans le contexte de la configuration serveur.


Directive : AccessFileName

Syntaxe : AccessFileName nomfichier nomfichier ...
Défaut : AccessFileName .htaccess
Contexte : configuration serveur, hôte virtuel
Statut : core
Compatibilité : AccessFileName ne peut accepter plusieurs noms de fichiers qu'à partir de la version 1.3 d'Apache

Lorsqu'il retourne un document au client, le server cherche le premier fichier de contrôle d'accès existant dans cette liste dans chacun des répertoires inscrit dans le chemin d'accès menant au document, pour déterminer si l'accès est autorisé dan chacun de ces répertoires. Par exemple:

AccessFileName .acl

Avant de servir le document /usr/local/web/index.html, le serveur lira les fichiers /.acl, /usr/.acl, /usr/local/.acl et /usr/local/web/.acl à la recherche de directives, sauf si celles-ci ont été désactivées par l'écriture

<Directory />
AllowOverride None
</Directory>


Directive : AddModule

Syntaxe : AddModule module module ...
Contexte : configuration serveur
Statut : core
Compatibilité : AddModule n'est disponible qu'à partir de la version 1.2 d'Apache

Le serveur peut intégrer des modules compilés qui ne sont pas mis en service. Cette directive peut être utilisée pour activer ou désactiver ces modules. Le serveur est installé avec une liste pré-configurée de modules à activer; cette liste peut être effacée par la directive ClearModuleList.


Directive : AllowOverride

Syntaxe : AllowOverride surcharge surcharge ...
Défaut : AllowOverride All
Contexte : répertoire
Statut : core

Lorsque le serveur trouve un fichier .htaccess (comme spécifié par AccessFileName) il doit savoir lesquelles des directives declarées dans ce fichier peuvent outrepasser les droits fixés par des directives précédentes.

Surcharge peut être pris comme None, auquel cas le serveur ne lit pas le fichier, All auquel cas le serveur prendra en compte toutes les directives dans ce fichier, ou encore une ou plusieurs instances de ce qui suit :

AuthConfig
Autorise l'usage de la directive Authorization (AuthDBMGroupFile, AuthDBMUserFile, AuthGroupFile, AuthName, AuthType, AuthUserFile, require, etc.).
FileInfo
Autorise l'usage de directives controllant l'accès aux types de documents (AddEncoding, AddLanguage, AddType, DefaultType, ErrorDocument, LanguagePriority, etc.).
Indexes
Autorise l'usage de directives controllant l'indexation des répertoires (AddDescription, AddIcon, AddIconByEncoding, AddIconByType, DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, ReadmeName, etc.).
Limit
Autorise l'usage de directives controllant les accès de certains hôtes (allow, deny et order).
Options
Autorise l'usage de directives controllant certaines fonctionnalités spécifiques des répertoires (Options and XBitHack).


Directive : AuthName

Syntaxe : AuthName domaine-autorisé
Contexte : répertoire, .htaccess
Surcharge : AuthConfig
Status : core

Cette directive indique le nom du schéma d'autorisation pour un répertoire. Ce schéma sera donné au client de sorte que l'utilisateur sache quel nom et quel mot de passe envoyer. Pour fonctionner correctement, elle devra être accompagnée des directives AuthType et require, et de directives telles que AuthUserFile et AuthGroupFile.


Directive : AuthType

Syntaxe : AuthType type
Contexte : répertoire, .htaccess
Surcharge : AuthConfig
Statut : core

Cette directive selectionne le type d'authentification pour un répertoire. Seul le type Basic est actuellement implémenté. Pour fonctionner correctement, elle devra être accompagnée des directives AuthName et require, et de directives telles que AuthUserFile et AuthGroupFile.


Directive : BindAddress

Syntaxe : BindAddress saddr
Défaut : BindAddress *
Contexte : configuration serveur
Statut : core

Un serveur http sous Unix® peut soit "écouter" toutes les adresses IP de la machine sur lequel il est implanté, ou uniquement une ou quelques unes de ces adresses. Saddr peut être

  • *
  • Une adresse IP qualifiée
  • Un nom de domaine Internet entièrement qualifié
  • Si la valeur est *, alors le serveur écoutera toutes les adresses IP ; dans le cas contraire, il n'écoutera que les adresses IP spécifiées.

    Une et une seule directive BindAddress peut être utilisée. Pour contrôler plus finement quels ports et adresses Apache écoute, utilisez la directive Listen au lieu de BindAddress.

    BindAddress peut être utilisée comme alternative à l'implantation d'hôtes virtuels utilisant des serveurs multiples indépendants, soit au lieu d'utiliser les sections <VirtualHost>.

    Voir aussi: Apache et DNS
    Voir aussi: Configurer les ports et adresses utilisés par Apache


    Directive : ClearModuleList

    Syntaxe : ClearModuleList
    Contexte : configuration serveur
    Statut : core
    Compatibilité : ClearModuleList n'est disponible qu'à partir de la version 1.2 d'Apache

    Le serveur dispose à l'installation d'une liste pré-configurée de modules activés. Cette directive efface cette liste. Il est supposé que cette liste sera reconstruite à partir de directives AddModule.


    Directive : ContentDigest

    Syntaxe : ContentDigest on|off
    Défaut : ContentDigest off
    Contexte : configuration serveur, hôtes virtuels, répertoire, .htaccess
    Surcharge : AuthConfig
    Statut : expérimental

    Compatibilité : ContentDigest n'est disponible qu'à partir de la version 1.1 d'Apache

    Cette directive active la génération d'en-têtes Content-MD5 conformes aux RFC1864 et RFC2068.

    MD5 est un algorithme permettant d'extraire un "résumé" à partir d'un bloc de données de longueur arbitraire, avec un degré de confiance suffisant dans la mesure ou une moindre altération dans les données sera reflétée par un changement dans le "résumé".

    L'en-tête Content-MD5 procure un test de l'intégrité de message de bout en bout (MIC) sur le corps d'entité. Un proxy ou client pourra tester cet en-tête pour détecter des modifications accidentelles du corp d'entité en cours de transfert. Exemple d'en-tête:

    Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==

    Notez que ceci peut réduire les performances de votre serveur dans la mesure où le "résumé" est calculé à chaque requête (il ne peut être "caché").

    Content-MD5 n'est émis que pour des documents servis par le noyau, et à l'exception de tout module. Par exemple, les documents SSI, la sortie de scripts CGI, et des réponses en flux d'octet binaire ne pourront utiliser cet en-tête.


    Directive : CoreDumpDirectory

    Syntaxe : CoreDumpDirectory nomrépertoire
    Défaut : même répertoire que ServerRoot
    Contexte : configuration serveur
    Statut : core

    Elle définit le répertoire auquel Apache tente d'accéder avant d'enregistrer un "core dump". Par défaut, il s'agit du répertoire ServerRoot, cependant, si ce répertoire n'est pas accessible en écriture par l'utilisateur sous lequel tourne le serveur, le "core dump" ne pourra être généré. Si vous souhaîtez dans ce cas obtenir un "core dump" pour des nécessités de débogage, vous pouvez utiliser cette directive pour spécifier un autre répertoire dans lequel vous avez toute autorisation pour écrire.


    Directive : DefaultType

    Syntaxe : DefaultType mime-type
    Défaut : DefaultType text/html
    Contexte : configuration serveur, hôtes virtuels, répertoire, .htaccess
    Surcharge : FileInfo
    Statut : core

    Il peut arriver qu'une requête demande au serveur un document dont le type ne peut être déterminé par les tables de MIME.

    Le serveur doit informer le client du type de contenu (Content-type) du document. Dans le cas d'un type inconnu, il utilisera le DefaultType. Par exemple :

    DefaultType image/gif

    sera approprié dans un répertoire contenant une majorité d'images gif dont certaines ne présentent pas explicitement l'extension .gif.


    Directive : <Directory>

    Syntaxe : <Directory nomrépertoire> ... </Directory>
    Contexte : configuration serveur, hôtes virtuels
    Statut : core

    <Directory> et </Directory> sont utilisés pour "encapsuler" un groupe de directives applicables uniquement au réprtoire indiqué ainsi qu'à ses sous-répertoires. Toute directive autorisée dans un contexte de répertoire peut apparaître entre ces deux balises. nomrépertoire est soit le chemin entièrement qualifié du répertoire, ou un motif. Dans un motif, '?' remplace un caractère unique quelconque, et '*' remplace toute séquence de zéro ou plus caractères quelconques. Sur Apache 1.3, vous pouvez aussi utiliser les plages de caractères '[]' comme dans un shell UNIX. De plus aucun des métacaractères ne peut remplacer un '/', ce qui correspond plus intimement à la réaction des shells UNIX. Exemple:

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

    A partir d'Apache 1.2 : Peuvent être utilisées les "expressions régulières", lesquelles devront être précédées du caractère ~. Par exemple : <Directory ~ "^/www/.*/[0-9]{3}">

    correspondrait à des répertoires dans /www/ dont le nom serait constitué de trois digits.

    Si plusieurs sections de répertoires pointent sur le répertoire d'un document (ou l'un de ses pères) sans qu'il s'agisse d'une expression régulière, alors les directives sont appliquées selon la loi de "la plus courte qualification d'abord", combinées aux directives des fichiers .htaccess. Par exemple, avec l'écriture

    <Directory />
    AllowOverride None
    </Directory>
    
    <Directory /home/*>
    AllowOverride FileInfo
    </Directory>
    

    pour le contrôle d'accès au document /home/web/dir/doc.html les étapes d'évaluation sont les suivantes :

  • Applique la directive AllowOverride None (désactivant les fichiers .htaccess).
  • Appliquela directive AllowOverride FileInfo (pour le répertoire /home/web).
  • Applique toutes les directives FileInfo de /home/web/.htaccess
  • Les sections exprimant des répertoires sous forme d'expressions régulières sont gérés légèrement différemment par Apache 1.2 et 1.3. Sous Apache 1.2, elles sont combinées aux sections "normales" et s'appliquent dans l'ordre où elles apparaissent dans le fichier de configuration. Elles ne s'appliquent qu'une fois, seulement pour celles qui font partie de la section "à plus courte correspondance". Sous Apache 1.3 les sections basées sur des expressions régulières ne sont pas évaluées tant que toutes les sections "normales" n'ont pas été considérées. A ce moment, les sections "régulières" sont traitées dans l'ordre où elles apparaissent dans le fichier de configuration. Par exemple, avec l'écriture

    <Directory ~ abc$>
    ... directives ici ...
    </Directory>
    

    Supposez que le nom de fichier demandé soit /home/abc/public_html/abc/index.html. Le serveur considère chacune des sections /, /home, /home/abc, /home/abc/public_html, et /home/abc/public_html/abc dans cet ordre. Sous Apache 1.2, lorsque /home/abc est pris en compte, l'expression régulière correspondra et ses termes seront appliqués. Sous Apache 1.3 l'expression régulière n'est pas considérée du tout à ce point de l'arbre. Elle ne le sera pas tant que toutes les sections "normales" <Directory>s et celles des fichiers .htaccess n'ont pas été appliquées. A ce moment seulement l'expression régulière reconnaîtra /home/abc/public_html/abc et les directives seront appliquées.

    Notez que l'accès par défaut d'Apache pour les sections <Directory> est Allow from All. Ceci veut dire que par défaut, Apache desservira tout fichier indiqué par une URL. Nous recommandons de modifier ceci à l'aide d'un bloc tel que

    <Directory />
         Order Deny,Allow
         Deny from All
    </Directory>
    

    puis désactiver sélectivement la protection pour les répertoires devant rester accessibles. Voir la page Security Tips pour plus de détails.

    Les sections de répertoires apparaissent habituellement dans le fichier access.conf, mais peuvent être présentes dans n'importe quel fichier de configuration. Les directives <Directory> ne peuvent être imbriquées, et ne peuvent petre incluses dans des sections <Limit>.

    Voir aussi : Comment fonctionnent les sections concernant les répertoires, chemins et fichiers pour une explication plus précise concernant la manière dont ces sections sont combinées lorsqu'une requête est traitée.


    Directive : <DirectoryMatch>

    Syntaxe : <DirectoryMatch regex> ... </DirectoryMatch>
    Contexte : configuration serveur, hôtes virtuels
    Statut : Core
    Compatibilité : Disponible à partir de la version 1.3 d'Apache

    <DirectoryMatch> et </DirectoryMatch> sont utilisés pour "encapsuler" un groupe de directives s'appliquant uniquement aux répertoires nommés et ses sous-répertoires, de manière identique à la directive <Directory>. Cependant, elle n'accepte comme argument qu'une expression régulière. Par exemple :

    <DirectoryMatch "^/www/.*/[0-9]{3}">

    correspondrait aux répertoires de /www/ dont le nom consiste en trois digits.

    Voir aussi : <Directory> pour une description de la manière dont les définitions par expression régulière sont combinées aux sections <Directory> "normales".
    Voir aussi : Comment fonctionnent les sections concernant les répertoires, chemins et fichiers pour une explication plus précise concernant la manière dont ces sections sont combinées lorsqu'une requête est traitée


    Directive : DocumentRoot

    Syntaxe : DocumentRoot directory-filename
    Défaut : DocumentRoot /usr/local/apache/htdocs
    Contexte : configuration serveur, hôtes virtuels
    Statut : core

    Cette directive définit le répertoire racine à partir duquel httpd va distribuer les fichiers. Sauf si le répertoire est pointé par une directive telle que Alias, le serveur ajoute le chemin relatif mentionnée dans l'URL présentée à cette racine pour établir le chemin complet jusqu'au document. Exemple :

    DocumentRoot /usr/web

    Un accès à http://www.my.host.com/index.html se réferre au document /usr/web/index.html.

    Un bogue existe pour cette directive mod_dir, laquelle fonctionne mal lorsque DocumentRoot est donnée avec un '/' final (c-à-d. "DocumentRoot /usr/web/"). Il vaut mieux éviter cette écriture.


    Directive : ErrorDocument

    Syntaxe : ErrorDocument error-code document
    Contexte : configuration serveur, hôtes virtuels, répertoire, .htaccess
    Statut : core
    Surcharge : FileInfo
    Compatibilité : Les contextes répertoire et .htaccess ne sont utilisables qu'à partir de la version 1.1 d'Apache.

    Dans l'éventualité d'un problème ou d'une erreur, Apache peut exécuter l'une des quatre actions suivantes :

    1. sortie d'un message d'erreur simple standard
    2. sortie d'un message personnalisé
    3. redirection vers une URL locale pour traiter le problème (ou l'erreur)
    4. redirection vers une URL externe pour traiter le problème (ou l'erreur)

    La première option est celle par défaut, les options 2 à 4 seront choisies par mention de la directive ErrorDocument, suivi du code HTTP d'erreur et du message textuel d'erreur, ou une URL.

    Messages dans ce contexte, commence par un guillemet simple ("), qui ne fait pas partie du message lui-même. Apache ajoutera souvent des informations complémentaires explicitant le problème (ou l'erreur).

    L'URL peut débuter par un slash (/) pour des URL locales, ou être complètement qualifiées. 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

    Notez que lorsque vous spécifiez un ErrorDocument qui pointe vers une URL externe (c-à-d. toute adresse commençant par quelque chose du style "http:") Apache émettra une requête de redirection au client pour lui indiquer où trouver le document, même si ce document est sur le serveur local et donc en théorie directement accessible... Ceci a plusieurs implications, dont la plus importante est que si vous utilisez l'écriture "ErrorDocument 401" alors il est impératif d'utiliser une URL locale. Ceci est induit par la nature des schémas d'authentification de base d'HTTP.

    Voir aussi: documentation sur les réponses personnalisées.


    Directive : ErrorLog

    Syntaxe : ErrorLog nomfichier
    Défaut : ErrorLog logs/error_log
    Contexte : configuration serveur, hôtes virtuels
    Statut : core

    Cette directive définit le nom du fichier dans lequel le serveur marque la trace des erreurs rencontrées. Si le nom de fichier ne commence pas par un slash (/), alors la partie "chemin d'accès" est considérée relativement à ServerRoot. Exemple:

    ErrorLog /dev/null

    Cette expression a pour effet de désactiver la trace d'erreurs.

    Sécurité : Voir la page note sur la securité pour plus d'information concernant une possibilité de brêche de sécurité si le répertoire d'accueil des fichiers de trace peut être écrit par tout autre utilisateur que le propriétaire du processus serveur.


    Directive : <Files>

    Syntaxe : <Files nomfichier> ... </Files>
    Contexte : configuration serveur, hôtes virtuels, .htaccess
    Statut : core
    Compatibilité : Disponible à partir de la version 1.2 d'Apache.

    La directive <Files> permet une gestion de contrôle d'accès fichier par fichier. Elle est comparable aux directives <Directory> et <Location>. Elle doit s'apparier à une directive </Files>. Les directives applicables au fichier indiqué sont encapsulées entre ces deux balises. Les sections <Files> sont traitées dans l'ordre où elles apparaissent dans le fichier de configuration, une fois traitées les sections <Directory> et les fichiers .htaccess, mais avant les sections <Location>.

    L'argument filename peut inclure un nom de fichier, où un motif, dans lequel '?' correspond à tout caractère unique quelconque, et '*' correspond à une séquence de zéro à un nombre quelconque de caractères. Les "expressions régulières" peuvent aussi être utilisées, pourvu qu'elles soient précédées du caractère ~. Par exemple :

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

    correspondrait à la majorité des fichiers graphiques utilisés sur Internet. A partir de la version 1.3 d'Apache, l'usage de la directive <FilesMatch> est cependant préférable.

    Notez que, contrairement aux sections <Directory> et <Location>, les sections <Files> peuvent apparaître dans des fichiers .htaccess. Ceci permet aux utilisateurs de contrôler l'accès à leurs propres fichiers, sur un mode individuel. Lorsqu'elles sont utilisées dans un fichier .htaccess, si nomfichier ne commence pas par un slash (/), le répertoire courant contenant ledit fichier .htaccess y sera préfixé automatiquement.

    Voir aussi : Comment fonctionnent les sections concernant les répertoires, chemins et fichiers pour une explication plus précise concernant la manière dont ces sections sont combinées lorsqu'une requête est traitée


    Directive : <FilesMatch>

    Syntaxe : <FilesMatch regex> ... </Files>
    Contexte : configuration serveur, hôtes virtuels, .htaccess
    Statut : core
    Compatibilité : Disponible à partir de la version 1.3 d'Apache.

    La directive <FilesMatch> permet un contrôle d'accès fichier par fichier, tout comme la directive <Files>. Cependant, elle n'accepte qu'un argument sous forme d'expression régulière. Par exemple :

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

    qui correspondrait à la plupart des fichiers graphiques utilisés sur Internet.

    Voir aussi : Comment fonctionnent les sections concernant les répertoires, chemins et fichiers pour une explication plus précise concernant la manière dont ces sections sont combinées lorsqu'une requête est traitée


    Directive : Group

    Syntaxe : Group groupeUnix
    Défaut : Group #-1
    Contexte : configuration serveur, hôte virtuel
    Statut : core

    La directive Group définit le groupe dont les requêtes seront traitées par le serveur. Pour utiliser cette directive, le serveur stand-alone doit tout d'abord être exécuté par l'utilisateur "root". groupeUnix est à choisir parmi :

    un nom de groupe
    se réfère à un groupe unix par son nom.
    # suivi d'unnuméro de groupe.
    se réfère à un groupe par son indice.

    Il est recommendé de créer un nouveau groupe d'utilisateurs pour les utilisateurs exécutant le serveur. Certains administrateurs assignent le serveur à l'utilisateur nobody, mais ceci n'est pas toujours possible ou souhaîtable.

    Note : si vous démarrez le serveur sous un compte utilisateur autre que "root", la commutation sur un autre groupe échouera, et le groupe utilisé restera le groupe initial de l'utilisateur.

    Note spéciale : L'utilisation de cette directive dans un contexte <VirtualHost> nécessite un suEXEC wrapper correctement configuré. De cette manière et dans ce contexte, seul le groupe dans lequel sont exécutés les CGI sont affectés. Toute requête autre que CGI sont toujours lancées dans le groupe défini par la directive Group principale.

    Sécurité : Voir Utilisateur pour une discussion plus détaillée sur les aspects utilisateurs.


    Directive : HostNameLookups

    Syntaxe : HostNameLookups on | off | double
    Défaut : HostNameLookups off
    Contexte : configuration serveur, hôte virtuel, répertoire, .htaccess
    Statut : core
    Compatibilité : double n'est disponible qu'à partir de la version 1.3 d'Apache.
    Compatibilité : La valeur par défaut était on pour toute version antérieure à la version 1.3 d'Apache.

    Cette directive autorise la résolution DNS pour la trace d'accès (et pour les passer aux CGI/SSI en REMOTE_HOST). La valeur double signifie une résolution DNS inverse double. C'est-à-dire, après qu'une résolution inverse soit effectuée, une résolution est ensuite effectuée à partir du résultat obtenu. Au moins une des adresses IP obtenues par la deuxième résolution doit correspondre à l'adresse originale. (Dans le langage des "fous de tcp" ceci s'appelle PARANOID.)

    Indépendamment du mode choisi, lorsque mod_access est utilisé pour faire du contrôle d'accès par nom d'hôte, une résolution inverse double sera effectuée. Ceci est indispensable pour des raisons de sécurité. Notez que le résultat de cette résolution inverse double n'est en général pas accessible sauf si l'option HostnameLookups double est activée. Par exemple, si l'option est simplement HostnameLookups on et une requête est reçue vers un objet soumis à des restrictions quant aux noms d'hôtes, et quelque soit le résultat de la réslution inverse double, les CGI recevront le résultat de la résolution inverse dans la variable d'environnement REMOTE_HOST.

    Par défaut, l'état choisi était on dans les versions d'apache antérieures à la version 1.3. Elle est aujourd'hui à off afin de diminuer le trafic pour les sites qui n'ont pas un besoin absolu de la résolution inverse. C'est aussi un avantage pour les utilisateurs finaux qui n'auront pas à attendre la fin du processus de résolution avant d'être servis. Des sites chargés devraient plutôt laisser cette opyion à off, dans la mesure où une recherche DNS peut consommer un temps non négligeable. L'utilitaire logresolve, fourni dans le répertoire /support, peut être utilisé pour résoudre des noms d'hôtes à partir des adresses IP tracées en mode "offline".


    Directive : IdentityCheck

    Syntaxe : IdentityCheck booléen
    Défaut : IdentityCheck off
    Contexte : configuration serveur, hôte virtuel, répertoire, .htaccess
    Statut : core

    Cette directive autorise une trace conforme à la RFC1413 du nom d'utilisateur pour chaque connexion, lorsque la machine cliente exécute identd ou un procesus similaire. Cette information est tracée dans le fichier access log. booléen vaut soit on ou off.

    Cette information n'est absolument pas certifiée et ne peut être considérée que pour une analyse sommaire.

    Notez que ce fontionnement peut rallonger notablement les délais d'accès à votre serveur dans la mesure où chaque requête nécessite l'exécution d'une résolution. Lorsque des "firewalls" sont présents chaque résolution peut éventuellement échouer et ajouter ainsi 30 secondes d'attente pour chaque accès. En conclusion, cette option n'est en général pas opportune pour des serveurs Internet ouverts au public.


    Directive : <IfModule>

    Syntaxe : <IfModule [!]nomModule> ... </IfModule>
    Défaut : None
    Contexte : all
    Statut : Core
    Compatibilité : IfModule n'est disponible qu'à partir de la version 1.2 d'Apache.

    La section <IfModule test>...</IfModule> permet de rendre conditionnelles un groupe de directives. Les directives à l'intérieur d'une section IfModule ne sont considérées que si le test est vérifié. Si test vaut faux, toute directive inclue entre la balise de début et celle de fin sont ignorées.

    Le test d'une section <IfModule> peut prendre l'une des formes suivantes :

    Dans le premier cas, les directives entre les deux balises de début et de fin ne sont traitées que si le module indiqué par nomModule est compilé dans votre version d'Apache. La seconde forme inverse le sens du test, et ne traite les directives que si le module nomModule n'est pas compilé.

    L'argument nomModule spécifie un nom de module par son nom de fichier source, tel qu'appelé par la compilation. Par exemple, mod_rewrite.c.

    Les sections <IfModule> peuvent être imbriquées, ce qui peut être utile pour implémenter simplement des tests multi-modules.


    Directive : Include

    Syntaxe : (Apache 1.2) Include nomfichier
    Contexte : configuration server
    Statut : Core
    Compatibilité : Include n'est disponible qu'à partir de la version 1.3 d'Apache.

    Cette directive permet l'inclusion d'autres fichiers de configuration à partir d'autres fichiers de configuration serveur.


    Directive : KeepAlive

    Syntaxe : (Apache 1.1) KeepAlive requêtesMax
    Défaut : (Apache 1.1) KeepAlive 5
    Syntaxe : (Apache 1.2) KeepAlive on/off
    Défaut : (Apache 1.2) KeepAlive On
    Contexte : configuration serveur
    Statut : Core
    Compatibilité : KeepAlive est disponible à partir de la version 1.1 d'Apache.

    Cette directive apporte le support Keep-Alive.

    Sous Apache 1.1: Mettre requêtesMax au nombre maximum de requêtes qu'Apache peut traiter par connexion rémanente. Une limitation est imposée pour éviter qu'un client ne vienne asphixier votre serveur de ressources. Mettre un 0 pour désactiver ce support.

    Apache 1.2 et postérieur: Mettre à On pour autoriser des connexions rémanentes, Off pour les interdire. Voir aussi la directive MaxKeepAliveRequests.


    Directive : KeepAliveTimeout

    Syntaxe : KeepAliveTimeout secondes
    Défaut : KeepAliveTimeout 15
    Contexte : configuration serveur
    Statut : Core
    Compatibilité : KeepAliveTimeout est disponible à partir de la version 1.1 d'Apache.

    Le nombre de secondes pendant lesquelles Apache attendra une requête postérieure avant de rompre une connexion. Dès qu'une requête est reçue, la valeur de la temporisation spécifiée par la directive Timeout s'applique.


    Directive : <Limit>

    Syntaxe : <Limit méthode méthode ... > ... </Limit>
    Contexte : any
    Statut : core

    <Limit> et </Limit> sont utilisées pour "encapsuler" un groupe de directives de contrôle d'accès ne s'appliquant uniquement qu'aux méthodes d'accès HTTP spécifiées par méthode. Toute directive autre qu'une autre directive <Limit> ou une directive <Directory> peut être utilisée; la majorité de ces directives ne seront pas affectées par <Limit>. Exemple:

    <Limit GET POST>
    require valid-user
    </Limit>
    

    Si une directive de contrôle d'accès apparaît en dehors d'une section <Limit>, alors elle s'applique à toutes les méthodes d'accès. Les méthodes possibles peuvent être l'une des suivantes : GET, POST, PUT, DELETE, CONNECT ou OPTIONS. Si la méthode GET est mentionnée, la restriction s'appliquera aussi aux requêtes HEAD. Si vous souhaitez implémenter une restriction pour toutes les méthodes, n'incluez aucune section <Limit>.


    Directive : Listen

    Syntaxe : Listen [adresseIp:]numéroPort
    Contexte : configuration serveur
    Statut : core
    Compatibilité : Listen est disponible à partir de la version 1.1 d'Apache.

    La directive Listen enjoint Apache à écouter plus d'une adresse IP ou port; par défaut Apache répond aux requêtes reçues sur toutes les interfaces IP, mais seulement celles arrivant sur le port donné par la directive Port. Listen peut être utilisée à la place de BindAddress et Port. Elle indique au serveur d'accepter des requêtes entrantes sur le port spécifié ou sur une combinaison adresse-port. Si le premier format est utilisé (avec seule mention d'un numéro de port), le serveur "écoutera" tous les ports spécifiés sur chacune des interfaces IP qu'il connaît, plutôt que sur le port donné par la directive Port. Si une adresse IP adresse IP est précisée en complément, le serveur restreindra son écoute à la combinaison adresse-port précisée.

    Notez que vous avez toujours besoin de la directive Port qui permettent à Apache de générer les URL de retour vers votre serveur.

    Plusieurs directives Listen peuvent être utilisées pour spécifier un ensemble d'adresses et de ports à écouter. Le serveur répondra aux requêtes reçues sur n'importe laquelle des combinaisons adresse-port ainsi spécifiée.

    Par exemple, pour autoriser le serveur à accepter des connexions sur les ports 80 et 8000, écrire :

    Listen 80
    Listen 8000
    

    Pour autoriser un serveur à accepter des connexions sur deux "sockets" qualifiés, écrire :

    Listen 192.170.2.1:80
    Listen 192.170.2.5:8000
    

    Voir aussi: Apache et DNS
    Voir aussi: Configurer les ports et adresses utilisée par Apache
    Voir aussi : Bogues connus


    Directive : ListenBacklog

    Syntaxe : ListenBacklog backlog
    Défaut : ListenBacklog 511
    Contexte : configuration serveur
    Statut : Core
    Compatibilité : ListenBacklog n'est disponible qu'à partir de la version 1.2.0 d'Apache.

    La longueur maximale de la file d'attente des connexions en attente. En général, aucun ajustement n'est nécessaire, cependant, il est souhaitable sur certains systèmes d'augmenter cette longueur de file pour répondre à des attaques TCP SYN. Voir les paramètres backlog dans l'appel système listen(2).


    Directive : <Location>

    Syntaxe : <Location URL> ... </Location>
    Contexte : configuration serveur, hôtes virtuels
    Statut : core
    Compatibilité : Location est disponible à partir des versions 1.1 d'Apache.

    La directive <Location> permet d'instaurer un contrôle d'accès sur une base URL. Elle est comparable à la directive <Directory>, et doit s'apparier à une directive </Location>. Les directives s'appliquant à l'URL précisée seront à inclure entre ces deux balises. Les sections <Location> sont traitées dans l'ordre où elles apparaissent dans le fichier de configuration, une fois les sections <Directory> et les fichiers .htaccess traités.

    Notez que, du fait du fontionnement d'HTTP, le préfixe d'URL devra, sauf pour des requêtes à un proxy, être de la forme /chemin/, et ne devra pas inclure de mention http://nomserveur. Elle ne protège pas nécessairement un répertoire (cela peut être un fichier individuel, ou un ensemble de fichiers), et peut inclure des métacaractères. Dans un motif (avec des métacaractères), '?' remplace un caractère quelconque, et '*' remplace toute chaîne quelconque de 0 ou plus caractères.

    Apache 1.2 et plus : Des expression régulières peuvent être utilisées, à condition de les faire précéder du caractère ~. Par exemple :

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

    correspondrait à des URL contenant la sous-chaîne "/extra/data" ou "/special/data". Cependant, sous Apache 1.3, l'utilisation de la directive <LocationMatch> est conseillée.

    La fonctionnalité Location est particulièrement pratique lorsque combinée à la directive SetHandler. Par exemple, pour permettre des requêtes sur les rapports d'état, mais ne les autoriser que pour des agents requérant à partir du domaine foo.com, vous pourriez écrire :

    <Location /status>
    SetHandler server-status
    order deny,allow
    deny from all
    allow from .foo.com
    </Location>
    

    Voir aussi: Comment fonctionnent les sections concernant les répertoires, chemins et fichiers pour une explication plus précise concernant la manière dont ces sections sont combinées lorsqu'une requête est traitée.


    Directive : <LocationMatch>

    Syntaxe : <LocationMatch regex> ... </LocationMatch>
    Contexte : configuration serveur, hôte virtuel
    Statut : core
    Compatibilité : Location est disponible à partir de la version 1.3 d'Apache.

    La directive <LocationMatch> permet l'établissement d'un contrôle d'accès sur une base URL, d'une façon identique à la directive <Location>. Cependant, elle n'accepte qu'une expression régulière comme argument. Par exemple : <LocationMatch "/(extra|special)/data"> représente des URL contenant l'une des sous-chaînes "/extra/data" ou "/special/data". Voir aussi : Comment fonctionnent les sections concernant les répertoires, chemins et fichiers pour une explication plus précise concernant la manière dont ces sections sont combinées lorsqu'une requête est traitée.


    Directive : LockFile

    Syntaxe : LockFile nomfichier
    Défaut : LockFile logs/accept.lock
    Contexte : configuration serveur
    Statut : core

    La directive LockFile indique le chemin d'accès du fichier de verrouillage utilisé lorsqu'Apache est compilé en mode USE_FCNTL_SERIALIZED_ACCEPT ou USE_FLOCK_SERIALIZED_ACCEPT. Ce paramètre sera laissé généralement dans son état par défaut. La raison principale qui conduirait à modifier ce paramètre serait le fait que le répertoire des traces (logs) soit monté sous NFS, le fichier de verrouillage devant de préférence être situé sur un disque local à la machine serveur pour autant que possible. Le PID du processus serveur principal est automatiquement rajouté au nom de fichier.


    Directive : MaxClients

    Syntaxe : MaxClients nombre
    Défaut : MaxClients 256
    Contexte : configuration serveur
    Statut : core

    La directive MaxClients indique le nombre limite de requêtes simultanées pouvant être acceptées par le serveur ; il représente le nombre maximum de processus serveur fils qui peuvent tourner à un instant donné.


    Directive : MaxKeepAliveRequests

    Syntaxe : MaxKeepAliveRequests nombre
    Défaut : MaxKeepAliveRequests 100
    Contexte : configuration serveur
    Statut : core
    Compatibilité : Uniquement à partir de la version 1.2 d'Apache.

    La directive MaxKeepAliveRequests limite le nombre de requêtes permises pour une connexion unique lorsque la directive KeepAlive est activée. Si nombre vaut "0", chaque connexion peut admettre un nombre illimité de requêtes. Nous recommendons que ce paramètre soit réglé sur une valeur relativement haute pour obtenir des performances optimales du serveur.


    Directive : MaxRequestsPerChild

    Syntaxe : MaxRequestsPerChild nombre
    Défaut : MaxRequestsPerChild 0
    Contexte : configuration serveur
    Statut : core

    La directive MaxRequestsPerChild indique le nombre limite de requêtes qu'un processus serveur fils peut traîter. Après MaxRequestsPerChild requêtes, ce processus fils meurt. Si ce paramètre est fixé à 0, alors les processus fils ne meurent jamais.

    Le fait de mettre MaxRequestsPerChild à une valeur non nulle a deux conséquences bénéfiques :


    Directive : MaxSpareServers

    Syntaxe : MaxSpareServers nombre
    Défaut : MaxSpareServers 10
    Contexte : configuration serveur
    Statut : core

    La directive MaxSpareServers indique le nombre maximal de processus fils en attente. Un processus en attente est un processus qui existe, mais qui ne traite pas de requête. S'il existe plus de MaxSpareServers de ces processus, alors le père viendra tuer les processus en supplémentaires.

    L'activation de cette fonctionnalité ne devrait être nécessaire que sur les site vraiment très chargés. Régler ce paramètre sur une grande valeur est de toutes façon toujours une mauvaise idée.

    Voir aussi MinSpareServers et StartServers.


    Directive : MinSpareServers

    Syntaxe : MinSpareServers nombre
    Défaut : MinSpareServers 5
    Contexte : configuration serveur
    Statut : core

    La directive MinSpareServers indique le nombre minimum de processus fils en attente qu'un serveur pourra conserver. S'il existe moins de MinSpareServers processus serveurs fils en attente, le processus père recréera des processus fils au rythme de 1 par seconde.

    L'activation de cette fonctionnalité ne devrait être nécessaire que sur des sites très chargés. Régler ce paramètre sur une grande valeur est de toutes façons toujours une mauvaise idée.

    Voir aussi MaxSpareServers et StartServers.


    Directive : NameVirtualHost

    Syntaxe : NameVirtualHost addr[:port]
    Contexte : configuration serveur
    Statut : core
    Compatibilité : NameVirtualHost n'est disponible qu'à partir de la version 1.3 d'Apache.

    La directive NameVirtualHost est nécessaire si vous souhaitez configurer des hôtes virtuels nommés.

    Bien que addr puisse être exprimée comme un nom d'hôte, il est recommandé d'utiliser une adresse IP, exemple :

    NameVirtualHost 111.22.33.44

    Avec cette directive NameVirtualHost, l'adresse nommée par le nom de votre hôte virtuel se résout. Si vous exploitez plusieurs hôtes nommés sur des adresses multiples, répétez cette directive autant de fois que nécessaire (pour chaque adresse).

    En option, vous pouvez préciser un numéro de port sur lequel l'hôte virtuel nommé sera atteint, par exemple :

    NameVirtualHost 111.22.33.44:8080
    Voir aussi : Hôtes virtuels sur Apache


    Directive : Options

    Syntaxe : Options [+|-]option [+|-]option ...
    Contexte : configuration serveur, hôte virtuel, répertoire, .htaccess
    Surcharge: Options
    Statut : core

    La directive Options contrôle quelles fonctions du serveur sont disponibles dans un répertoire particulier.

    option peut valoir None, auquel cas aucune fonction supplémentaire n'est disponible, ou une ou plus des possibilités suivantes :

    All
    toutes options sauf MultiViews.
    ExecCGI
    L'exécution des scripts CGI est autorisée.
    FollowSymLinks
    Le serveur est autorisé à suivre les liens symboliques dans ce répertoire.

    Note: même si le serveur suit le lien symbolique, il ne doit pas changer le chemin d'accès afin de ne pas entrer en contradiction avec les sections <Directory>.

    Includes
    Les inclusions par Server-Side-Include sont permises.
    IncludesNOEXEC
    Les SSI sont autorisés, mais pas la commande #exec ni #include des scripts CGI.
    Indexes
    Si une URL requise pointe sur un répertoire, et aucun fichier défini par DirectoryIndex (ex. index.html) n'existe dans ce répertoire, alors le serveur retourne une liste formatée du contenu du répertoire.
    MultiViews
    Un contenu négocié en MultiViews est permis.
    SymLinksIfOwnerMatch
    Le serveur ne suivra les liens symboliques uniquement si le fichier visé ou le répertoire visé appartiennent au même utilisateur que le lien lui-même.

    Normalement, si plusieurs options Options peuvent être appliquées à un répertoire, alors la plus restrictive est appliquée ; les options ne sont pas combinées. Cependant, si all les options dans la directive Options sontprécédées d'un symbole + ou -, alors les options sont alors combinées entre elles. Toute option précédée d'un + est ajoutée aux options en cours, toute option précédée d'un - est désactivée.

    Par exemple, sans symboles + ni - :

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

    seul Includes sera activé pour le répertoire /web/docs/spec. Cependant, si la seconde directive d'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 sont validées pour le répertoire /web/docs/spec.


    Directive : PidFile

    Syntaxe : PidFile filename
    Défaut : PidFile logs/httpd.pid
    Contexte : configuration serveur
    Statut : core

    La directive PidFile définit le fichier dans lequel le serveur enregistre l'identificateur de processus du démon. Si le nom de fichier ne commence pas par un slash (/) alors le fichier est défini relativement au ServerRoot. Le fichier PidFile n'est utilisé que dans le mode standalone.

    Il est souvent utile de pouvoir envoyer un signal au serveur, pour qu'il referme et réouvre ses fichiers ErrorLog et TransferLog, et relise ses fichiers de configuration. Ceci peut être fait en envoyant un signal SIGHUP (kill -1) au processus identifié par l'identificateur de processus marqué dans PidFile.

    Le fichier PidFile est concerné par les mêmes problèmes d'emplacement et de securité que les fichiers de trace.


    Directive : Port

    Syntaxe : Port numéro
    Défaut : Port 80
    Contexte : configuration serveur
    Statut : core

    numéro est un nombre compris entre 0 et 65535; certains numéros de ports (surtout en dessous de 1024) sont réservés pour des protocoles spécifiques. Une liste des ports prédéfinis est consultable dans la RFC 1340 "Assigned Numbers" /etc/services; le port standard assigné au protocole http est le port 80.

    La directive Port a deux comportements, le premier est nécessaire pour assurer la compatibilité NCSA (et qui peut préter à confusion dans le contexte d'Apache).

    Dans aucun cas une définition du Port ne définit à quel port un VirtualHost répond, la directive VirtualHost elle-même se chargeant de cette définition.

    Le comportement premier de la directive Port doit être considéré comme similaire à celui de la directive ServerName. ServerName et Port spécifient conjointement ce que vous considérez être l'adresse canonique du serveur.

    Le Port 80 est l'un des ports prédéfinis d'Unix. Tous les ports numérotés en dessous de 1024 sont réservés à un usage système, c-à-d. que des utilisateurs non privilégiés (non-root) ne peuvent les utiliser ; ces derniers peuvent par contre utiliser des ports de plus haut rang. Pour utiliser le port 80, le serveur doit être exécuté sous root. Après avoir lié le port (bind) et avant d'accepter des requêtes, Apache changera son utilisateur associé tel que défini par la directive User.

    Si vous ne pouvez utiliser le port 80, choisissez tout autre port libre. Les utilisateurs non-root devront choisir un numéro de port supérieur à 1023, 8000 par exemple.

    Sécurité : si vous démarrez le serveur sous root, assurez vous que la directive User ne mentionne pas root. Si vous traitez des requêtes en disposant toujours de super privilèges, vous ouvrez votre système à des attaques majeures.


    Directive : require

    Syntaxe : require nomEntite Entite Entite...
    Contexte : répertoire, .htaccess
    Surcharge: AuthConfig
    Statut : core

    Cette directive choisi quels utilisateurs autorisés peuvent accéder à un répertoire. Les syntaxes valides sont :

    Si require apparaît dans une section <Limit>, alors les restrictions ne sont appliquées qu'aux méthodes http mentionnées. Autrement, toutes les méthodes http sont restreintes. Exemple :

    AuthType Basic
    AuthName unDomaine
    AuthUserFile /web/users
    AuthGroupFile /web/groups
    <Limit GET POST>
    require group admin
    </Limit>
    

    Pour fonctionner correctement, la directive Require doit être accompagné de directives AuthName et AuthType, et de directives de type AuthUserFile et AuthGroupFile (servant à définir les utilisateurs et les groupes).


    Directive : ResourceConfig

    Syntaxe : ResourceConfig nomfichier
    Défaut : ResourceConfig conf/srm.conf
    Contexte : configuration serveur, hôte virtuel
    Statut : core

    Le serveur lit dans ce fichier des directives supplémentaires, après avoir lu le fichier httpd.conf. nomfichier est considéré relativement à ServerRoot. Cette fonctionnalité peut être désactivée par l'écriture :

    ResourceConfig /dev/null

    Historiquement, ce fichier contenait essentiellement les directives autres que celles servant à la configuration du serveur ou les sections <Directory> ; en fait, il peut contenir maintenant toute directive admise dans le contexte configuration serveur.

    Voir aussi AccessConfig.


    Directive : RLimitCPU

    Syntaxe : RLimitCPU # ou 'max' [# ou 'max']
    Défaut : Non précisé; utilise le défaut du système d'exploitation
    Contexte : configuration serveur, hôte virtuel
    Statut : core
    Compatibilité : RLimitCPU n'est disponible qu'à partir de la version 1.2 d'Apache

    Accepte 1 ou 2 parametères. Le premier paramètre indique la limite logicielle pour tous les processus et le second paramètre la limite supérieure en termes de ressources. Chacun des paramètres peut être exprimé par un nombre, ou max pour indiquer au serveur que la limite est celle imposée par le système d'exploitation. La limite supérieure en ressource ne peut être atteinte que si le serveur tourne sous root, ou éventuellement pendant la phase de démarrage.

    La limite de ressources CPU est exprimée en secondes par processus.

    Voir aussi RLimitMEM ou RLimitNPROC.


    Directive : RLimitMEM

    Syntaxe : RLimitMEM # ou 'max' [# ou 'max']
    Défaut : Non précisé ; utilise le défaut du système d'exploitation
    Contexte : configuration serveur, hôte virtuel
    Statut : core
    Compatibilité : RLimitMEM is only available in Apache 1.2 and later

    Accepte 1 ou 2 paramètres. Le premier paramètre fixe la limite logicielle en ressources mémoire pour tous les processus tandis que le second paramètre fixe la limite absolue de ressources mémoire. Chaque paramètre peut être un nombre, ou max pour indiquer au serveur que la limite est fixée par le système d'exploitation. La limite supérieure en ressource ne peut être atteinte que si le serveur tourne sous root, ou éventuellement pendant la phase de démarrage.

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

    Voir aussi RLimitCPU ou RLimitNPROC.


    Directive : RLimitNPROC

    Syntaxe : RLimitNPROC # ou 'max' [# ou 'max']
    Défaut : Unset; uses operating system defaults
    Contexte : configuration serveur, hôte virtuel
    Statut : core
    Compatibilité : RLimitNPROC n'est disponible qu'à partir de la version 1.2 d'Apache

    Accepte 1 ou 2 paramètres. Le premier paramètre fixe la limite logicielle en ressources pour tous les processus tandis que le second paramètre fixe la limite absolue de ressources mémoire. Chaque paramètre peut être un nombre, ou max pour indiquer au serveur que la limite est fixée par le système d'exploitation. La limite supérieure en ressource ne peut être atteinte que si le serveur tourne sous root, ou éventuellement pendant la phase de démarrage.

    Cette limite contrôle le nombre de processus maximum par utilisateur.

    Note : Si les processus CGI ne tournent pas sous un autre utilisateur que l'utilisateur du serveur, cette directive limitera aussi le nombre de processus que le serveur lui-même peut créer. Cette situation sera indiquée de façon évidente par des messages d'erreur cannot fork dans le fichier error_log.

    Voir aussi RLimitMEM ou RLimitCPU.


    Directive : Satisfy

    Syntaxe : Satisfy 'any' ou 'all'
    Défaut : Satisfy all
    Contexte : répertoire, .htaccess
    Statut : core
    Compatibilité : Satisfy n'est disponible qu'à partir de la version 1.2 d'Apache

    Politique d'accès si à la fois 'allow' et 'require' sont utilisés. Le paramètre peut valoir soit 'all' soit 'any'. Cette directive n'est utile que si l'accès à une zone particulière est à la fois restreinte par un username/password et et par l'adresse d'hôte client. Dans ce cas le comportement par défaut ("all") impose au client de passer la restriction d'adresse et d'entrer un identificateur d'utilisateur et un mot de passe valides. Avec l'option "any", le client sera servi si son adresse d'hôte est conforme ou s'il rentre des paramètres d'identification corrects. Ceci peut être utilisé pour restreindre un zone par un mot de passe, tout en laissant quelques client bien identifiés entrer dans le domaine sans avoir à se soumettre à la procédure d'identification.


    Directive : ScoreBoardFile

    Syntaxe : ScoreBoardFile nomfichier
    Défaut : ScoreBoardFile logs/apache_status
    Contexte : configuration serveur
    Statut : core

    La directive ScoreBoardFile est nécessaire sur certaines architectures pour créer un fichier servant à la communication entre des processus pères et des processus fils. La meilleure façon de savoir si votre système nécessite un tel fichier est d'exécuter Apache et de voir s'il crée le fichier mentionné dans la directive. Si votre système nécessite l'emploi de ce fichier, alors vous devez vous assurer que celui-ci ne peut être utilisé que par une et une seule invocation d'Apache.

    Si vous devez utiliser un ScoreBoardFile, vous pourrez optimiser votre temps d'exécution en le plaçant sur un disque virtuel en RAM. Cependant, rappelez-vous que les mêmes recommandations sont à prendre en compte pour la position de ce fichier que pour la position des fichiers de trace quant à la securité.

    A partir d'Apache 1.2 :

    Les utilisateurs de Linux 1.x doivent pouvoir ajouter -DHAVE_SHMGET aux EXTRA_CFLAGS dans leur fichier de Configuration. Ceci devrait fonctionner sur certaines installations en 1.x, mais pas forcément sur toutes.

    Les utilisateurs de SVR4 devront considérer l'opportunité d'ajouter -DHAVE_SHMGET aux EXTRA_CFLAGS dans leur fichier de Configuration. Il semble que cela fonctionne, mais nous n'avons pu le tester pour la version 1.2.

    Voir aussi : Arrêter et redémarrer Apache


    Directive : SendBufferSize

    Syntaxe : SendBufferSize octets
    Contexte : configuration serveur
    Statut : core

    Le serveur règle la taille du tampon interne de TCP au nombre d'octets spécifié. Très utile pour augmenter les tailles par défaut dans le cas d'utilisation de liaisons haute vitesse (ex. des liaisons transcontinantales rapides).


    Directive : ServerAdmin

    Syntaxe : ServerAdmin adresseEMail
    Contexte : configuration serveur, hôte virtuel
    Statut : core

    La directive ServerAdmin définit l'adresse e-mail que le serveur inclut dans tout message d'erreur retourné au client.

    Il peut être utile de dédier une adresse réservée à cet usage, par exemple :

    ServerAdmin [email protected]

    car les utilisateur ne rappellent pas toujours dans leur message ce à propos de quoi ils interviennent!


    Directive : ServerAlias

    Syntaxe : ServerAlias hôte1 hôte2 ...
    Contexte : hôte virtuel
    Statut : core
    Compatibilité : ServerAlias est disponible à partir de la version 1.1 d'Apache

    La directive ServerAlias défini un nom secondaire pour un hôte, utilisable dans le contexte d'hôte virtuels nommés.

    Voir aussi : Hôtes virtuels sur Apache


    Directive : ServerName

    Syntaxe : ServerName nom de domaine entièrement qualifié
    Contexte : configuration serveur, hôte virtuel
    Statut : core

    La directive ServerName définit le nom d'hôte du serveur ; celui-ci n'est utilisé que pour créer des URL de redirection. S'il n'est pas défini, alors le serveur tentera de le résoudre à partir de sa propre adresse IP ; cependant, cette résolution n'est pas d'une fiabilité absolue, ou peut résulter en un nom autre que le nom "souhaité". Par exemple : ServerName www.wibble.com

    peut être défini lorsque le nom canonique (principal) de la machine actuelle est monster.wibble.com.

    Voir aussi : Apache et DNS


    Directive : ServerPath

    Syntaxe : ServerPath chemin
    Contexte : hôte virtuel
    Statut : core
    Compatibilité : ServerPath est disponible à partir de la version 1.1 d'Apache.

    La directive ServerPath définit le chemin d'accès servant de base pour les URL ciblant un hôte virtuel nommé.

    Voir aussi : Hôtes virtuels sur Apache


    Directive : ServerRoot

    Syntaxe : ServerRoot nomrépertoire
    Défaut : ServerRoot /usr/local/apache
    Contexte : configuration serveur
    Statut : core

    La directive ServerRoot définit le répertoire dans lequel se situe le serveur. Typiquement, ce répertoire contiendra les sous-répertoires conf/ et logs/. Les chemins d'accès relatifs pour d'autres fichiers de configuration seront considérés relativement à ce répertoire.
    Voir aussi les -d options de httpd.


    Directive : ServerType

    Syntaxe : ServerType type
    Défaut : ServerType standalone
    Contexte : configuration serveur
    Statut : core

    La directive ServerType définit comment le serveur est exécuté par le système d'exploitation. Type peut prendre l'une des valeurs suivantes :

    inetd
    Le serveur sera exécuté à partir du processus system inetd ; la commande nécessaire au démarrage du serveur devra être ajoutée au fichier /etc/inetd.conf
    standalone
    Le serveur est lancé en tant que démon ; la commande de démarrage du serveur sera ajoutée aux scripts de démarrage du système d'exploitation. (/etc/rc.local ou /etc/rc3.d/....)

    Inetd est l'option la moins utilisée des deux. Pour chaque connexion http demandée, une nouvelle instance du serveur est créée ; une fois la connexion établie, ce programme tourne. Ceci implique un coût important en ressources pour chaque connexion, mais certains administrateurs préfèrent parfois ce mode pour des raisons de sécurité.

    Standalone est l'option la plus fréquente pour la directive ServerType dans la mesure où ce dernier est de loin plus performant. Le serveur n'est démarré qu'une fois, et dessert toutes les connexions ultérieures. Si vous utilisez Apache sur un site très chargé, le mode standalone sera certainement le seul choix possible.

    Sécurité : si vous êtes quelque peu paranoïaque sur ces questions de sécurité, utilisez le mode inetd. La sécurité absolue ne peut être garantie dans aucun des deux modes, mais du fait que le mode standalone est le plus utilisé, il y a de forte chances que plus de tentatives d'attaques concernent le mode standalone que le mode inetd.


    Directive : StartServers

    Syntaxe : StartServers nombre
    Défaut : StartServers 5
    Contexte : configuration serveur
    Statut : core

    La directive StartServers définit le nombre de processus fils créés dès le démarrage du serveur. Le nombre de ces processus étant contrôlé dynamiquement en fonction de la charge, il y a en général peu d'intérêt à modifier la valeur par défaut de ce paramètre.

    Lorsque le serveur est exécuté sous Microsoft Windows, cette directive définit le nombre total de processus fils actifs. Comme la version Windows d'Apache est écrite en multithread, un seul processus gère l'intégralité des requêtes. Les autres processus sont mises en réserve jusqu'à ce que le processus actif meure.

    Voir aussi MinSpareServers et MaxSpareServers.


    Directive : ThreadsPerChild

    Syntaxe : ThreadsPerChild nombre
    Défaut : ThreadsPerChild 50
    Contexte : configuration serveur
    Statut : core (Windows)
    Compatibilité : Disponible seulement à partir de la version 1.3 pour Windows d'Apache

    Cette directive indique au serveur combien de threads (tâches) il doit lancer. Cela est équivalent au nombre maximum de connexions que le serveur peut traiter simultanément ; soyez sûr de vous et réglez le nombre suffisament haut si votre site est très fréquenté.

    Voir aussi StartServers et MaxRequestsPerChild.


    Directive : TimeOut

    Syntaxe : TimeOut nombre
    Défaut : TimeOut 300
    Contexte : configuration serveur
    Statut : core

    La directive TimeOut définit la temporisation courante pendant laquelle Apache attendra l'une de ces trois choses :

    1. Le temps total de réception d'une requête GET.
    2. Le temps entre la réception de paquets TCP lors d'une requête POST ou PUT.
    3. Le temps entre deux acquittements lors de la transmission de paquets TCP de réponse.

    Nous prévoyons dans le futur de permettre une configuration individuelle de chacune de ces temporisations. La valeur par défaut était de 1200 avant la version 1.2, mais a été abaissée à 300 depuis, ce qui est déjà largement plus que nécessaire dans la plupart des situations. Il n'est cependant pas réglé plsu bas car il peut exister (encore) des portions de code un peu "floues" par lesquelles le temporisateur n'est pas remis à zéro lors de la transmission d'un paquet.


    Directive : User

    Syntaxe : User utilisateurUnix
    Défaut : User #-1
    Contexte : configuration serveur, hôte virtuel
    Statut : core

    La directive User définit l'utilisateur associé au serveur. Pour utiliser cette directive, un serveur standalone devra être lancé sous root. utilisateurUnix est l'un parmi :

    un nom d'utilisateur
    se réfère à un utilisateur déclaré du système.
    # suivi d'un numéro d'utilisateur.
    se réfère à l'utilisateur déclaré du système portant ce numéro.

    L'utilisateur peut n'avoir aucun privilège ce qui lui permet néanmoins de pouvoir avoir accès à des fichiers qui ne sont pas sensés être visibles du "reste du monde", mais pas d'exécuter du code qui ne serait pas explicitement exécutable par l'utilisateur associé à httpd. Il est d'ailleurs recommandé de créer un utilisateur et un groupe specialement pour exécuter le serveur. Certains administrateurs utilisent souvent l'utilisateur nobody, mais ceci n'est pas toujours possible ou souhaitable.

    Note : si vous démarrez le serveur sous un utilisateur non-root, la tentative pour passer sous un utilisateur de moindre privilège échouera, et le serveur continuera à sexécuter sous l'utilisateur d'origine. Si vous démarrez le serveur sous root, alors il sera normal que le processus père continue à s'exécuter sous root.

    Note spécifique : L'utilisation de cette directive dans une section <VirtualHost> nécessite un wrapper suEXEC correctement configuré. Lorsqu'elle est utilisée de cette façon dans une section <VirtualHost>, seul l'utilisateur associé à l'exécution des scripts CGI est affecté. Les requêtes non-CGI seront toujours traitées sous l'utilisateur défini dans la directive User de la section principale.

    Sécurité : Ne définissez pas l'utilisateur (ni le groupe) comme root sauf si vous savez exactement ce que vous faites, et si vous êtes totalement conscients des risques qui sont encourus.


    Directive : <VirtualHost>

    Syntaxe : <VirtualHost adresse[:port] ...> ... </VirtualHost>
    Contexte : configuration serveur
    Statut : Core
    Compatibilité : la "virtualisation" d'hôtes non basés sur l'adressage IP n'est disponible qu'à partir de la version 1.1 d'Apache
    Compatibilité : le support d'adresses multiples n'est disponible qu'à partir de la version 1.2 d'Apache

    Les directives <VirtualHost> et </VirtualHost> sont utilisées pour "encapsuler" un groupe de directives qui s'appliquent à un hôte virtuel particulier. Toute directive autorisée dans un contexte "hôte virtuel" peut être présente. Lorsque le serveur reçoit une requête demandant un document spécifique sur un hôte virtuel spécifique, il utilise les directives de configuration explicitées dans la section <VirtualHost> correspondante. Adresse peut être :

    Exemple :

    <VirtualHost 10.1.2.3> 
    ServerAdmin [email protected]
    DocumentRoot /www/docs/host.foo.com 
    ServerName host.foo.com
    ErrorLog logs/host.foo.com-error_log
    TransferLog logs/host.foo.com-access_log
    </VirtualHost>
    

    Chaque hôte virtuel doit être associé à une adresse IP, à un numéro de port ou à un nom d'hôte différents que celui attribué au server, dans le dernier cas la machine du serveur doit être configurée pour accepter des paquets IP sur plusieurs adresses. (Si la machine ne dispose pas de plusieurs interfaces réseau physiques, ceci peut être obtenu par la commande ifconfig alias (si votre OS l'accepte), ou par des patchs du kernel du type VIF (pour SunOS(TM) 4.1.x)).

    Le nom prédéfini _default_ peut être attribué auquel cas cet hôte virtuel lira toutes les adresses IP qui ne sont pas explicitement listées dans les autres hôtes virtuels définis. En l'absence d'un hôte virtuel _default_, la configuration serveur "principale", à savoir toutes les définitions en dehors des sections VirtualHost, seront utilisées si aucun hôte virtuel ne reconnaît l'adresse.

    Vous pouvez specifier une commande :port pour changer le port reconnu par l'hôte virtuel. Si aucun port n'est mentionné, alors le port reconnu est par défaut celui mentionné dans la dernière directive de Port de la section principale qui précède. Vous pouvez également spécifier :* pour reconnaître tous les ports à cette adresse. (Ceci est conseillé lorsque l'hôte virtuel est le _default_.)

    Sécurité: Voir les conseils de sécurité pour plus de détails sur les risques encourus si le répertoire contenant les fichiers de trace peut être écrit par un autre utilisateur que celui sous lequel est exécuté le serveur.

    Note: L'utilisation de la directive <VirtualHost> n' affecte pas les adresses qu'écoute Apache. Vous devez vous assurer que les adresses définies pour les hôtes virtuels font aussi partie de l'ensemble des adresses écoutées par Apache et définies par des directives BindAddress ou Listen.

    Voir aussi : Hôtes virtuels sur Apache
    Avertissement concernant DNS et Apache
    Configurer les ports et adresses utilisés par Apache

    Voir aussi : Comment fonctionnent les sections concernant les répertoires, chemins et fichiers pour une explication plus précise concernant la manière dont ces sections sont combinées lorsqu'une requête est traitée.


    Apache HTTP Server Version 1.3

    Index Home

    Adaptation française © Valery Fremaux / EISTI 1998