### Apache HTTP Server Version 1.3

Is this the version you want? For more recent versions, check our documentation index.

# Noyau d'Apache

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

## Directives

- AcceptFilter
- AccessConfig
- AccessFileName
- AddDefaultCharset
- AddModule
- AllowOverride
- AuthName
- AuthType
- BindAddress
- BS2000Account
- ClearModuleList
- ContentDigest
- CoreDumpDirectory
- DefaultType
- <Directory>
- <DirectoryMatch>
- DocumentRoot
- EBCDICConvert
- EBCDICConvertByType
- EBCDICKludge
- ErrorDocument
- ErrorLog
- <Files>
- <FilesMatch>
- Group
- HostNameLookups
- IdentityCheck
- <IfDefine>
- <IfModule>
- Include
- KeepAlive
- KeepAliveTimeout
- <Limit>
- <LimitExcept>
- LimitRequestBody
- LimitRequestFields
- LimitRequestFieldsize
- LimitRequestLine
- Listen
- ListenBacklog
- <Location>
- <LocationMatch>
- LockFile
- LogLevel
- MaxClients
- MaxKeepAliveRequests
- MaxRequestsPerChild
- MaxSpareServers
- MinSpareServers
- NameVirtualHost
- Options
- PidFile
- Port
- require
- ResourceConfig
- RLimitCPU
- RLimitMEM
- RLimitNPROC
- Satisfy
- ScoreBoardFile
- ScriptInterpreterSource
- SendBufferSize
- ServerAdmin
- ServerAlias
- ServerName
- ServerPath
- ServerRoot
- ServerSignature
- ServerTokens
- ServerType
- StartServers
- ThreadsPerChild
- ThreadStackSize
- TimeOut
- UseCanonicalName
- User
- <VirtualHost>

## Directive AcceptFilter

Syntaxe : AcceptFilter on|off
Défaut : `AccceptFilter on`
Contexte : server config
Statut : core

`AcceptFilter` contrôle une optimisation spécifique à BSD. Elle est compilée par défaut et activée par défaut si votre système l'implémente (option SO_ACCCEPTFILTER de setsocketopt()). A l'heure actuelle, seul FreeBSD l'implémente.

Se référer à la section concernant les filtres dans la documentation sur la performance pour de plus amples informations.

L'option de compilation `AP_ACCEPTFILTER_OFF` peut être utilisée pour changer le défaut à 'off'. `httpd -V` et `httpd -L` affichent dorénavant les valeurs par défauts au moment de la compilation, et si oui ou non SO_ACCEPTFILTER a été défini pour cette compilation.

## Directive AccessConfig

Syntaxe : AccessConfig nomfichier|nomrépertoire
Défaut : `AccessConfig conf/access.conf`
Context: configuration serveur, hôtes virtuels
Statut : noyau

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`

ou sur les serverus Win32

> `AccessConfig nul`

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

Une nouveauté de la version d'Apache 1.3.13 est la possibilité qu'`AccessConfig` représente un répertoire plutot qu'un fichier. Apache lira tous les fichiers de ce répertoire ainsi que tous les sous-répertoires et analysera tous ces fichiers de configuration.

Voir également ResourceConfig.

## Directive AccessFileName

Syntaxe : AccessFileName nomfichier [nomfichier] ...
Défaut : `AccessFileName .htaccess`
Context: configuration serveur, hôte virtuel
Statut : noyau
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 serveur 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>`

Voir également : AllowOverride

## Directive AddDefaultCharset

Syntaxe : AddDefaultCharset On|Off|charset
Contexte : tous
Statut : noyau
Défaut : `AddDefaultCharset Off`
Compatibilité : AddDefaultCharset n'est disponible qu'à partir de la version 1.3.12

Cette directive spécifie le nom de la table de caractères qui sera ajouté à toutes les réponses qui n'ont aucun paramètre sur le type de contenu dans l'en-tête HTTP. Elle remplace la table de caractère spécifié dans le corps du document par l'utilisation du marqueur `META`. La mise de `AddDefaultCharset Off` désactive cette fonctionnalité. `AddDefaultCharset On` active la table de caractère `iso-8859-1` par défaut d'Apache. Vous pouvez également définir une autre table de caractères à employer. Par exemple `AddDefaultCharset utf-8`.

## Directive AddModule

Syntaxe : AddModule module [module] ...
Contexte : configuration serveur
Statut : noyau
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 actifs cette liste peut être effacée par la directive ClearModuleList.

## Directive AllowOverride

Syntaxe : AllowOverride All|None|type de directive [type de directive] ...
Défaut : `AllowOverride All All`
Contexte : répertoire
Statut : noyau

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

Si la directive est définie à `None`, les fichier .htaccess sont ignorés. Dans ce cas, le serveur n'essaie même pas de lire les fichiers .htaccess.

Si la directive est définie à `All` toutes les directives possibles dans le contexte .htacces sont autorisées dans les fichiers .htaccess.

Les types de directives peuvent être parmi ces groupes de directives :

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

Voir également : AccessFileName

## Directive AuthName

Syntaxe : AuthName domaine-autorisé
Contexte : répertoire, .htaccess
Surcharge : AuthConfig
Statut : noyau

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. `AuthName` prend un seul argument. Si le schéma d'autorisation contient des espaces, il doit être entouré de guillemets. 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 : noyau

Cette directive selectionne le type d'authentification pour un répertoire. Seul les types `Basic` et `Digest` sont actuellement implémentés. 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 *|addresse IP|nom de domaine
Défaut : `BindAddress *`
Contexte : configuration serveur
Statut : noyau

Un serveur http sous Unix® peut soit écouter toutes les adresses IP de la machine sur lequel il est exécuté, ou uniquement une de ces adresses. Si l'argument de cette directive est *, le serveur traitera les connections sur toutes les adresses IP. Sinon, le serveur peut écouter à partir d'une adresse IP spécifique ou d'un nom de domaine Internet.

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

## BS2000Account directive

Syntaxe : BS2000Account account
Défaut : none
Contexte : configuration serveur
Statut : noyau
Compatibilité : BS2000Account n'est valable que pour les machines BS2000, à partir de la version 1.3 d'Apache.

La directive `BS2000Account` n'est disponible que pour les machines BS2000. Elle doit être employée pour définir le numéro de compte pour l'utilisateur non privilégié (qui est défini par la directive User ). Ceci est requis par le sous système POSIX du BS2000 afin de changer l'environnement d'exécution sosu jacent du BS200 en effectuant une sous connexion, et éviter ainsi que des scripts CGI puissent accéder à des ressources accessible à l'utilisateur privilégié utilisé pour lancer le serveur, généralement `SYSROOT`.
Seulement une directive `BS2000Account` peut être utilisée.

Voir également: Portage EBCDIC d'Apache

## Directive ClearModuleList

Syntaxe : ClearModuleList
Contexte : configuration serveur
Statut : noyau
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 actifs. 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 : Options
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 corps 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 mis en cache).

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

Elle définit le répertoire auquel Apache tente d'accéder avant d'enregistrer un "noyau 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 "noyau dump" ne pourra être généré. Si vous souhaitez dans ce cas obtenir un "noyau 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 : noyau

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

`<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 Trucs sur la sécurité 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> ou <LimitExcept>.

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

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

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.

## EBCDICConvert

Syntaxe : EBCDICConvert On|Off[=direction] extension [extension] ...
Contexte : configuration serveur, hôte virtuel, répertoire, .htaccess
Statut : noyau
Surcharge : FileInfo
Compatibilité : la conversion EBCDIC est disponible à partir de la version 1.3.19 d'Apache sur les plate-formes basées sur EBCDIC.

La directive EBCDICConvert associe une extension de fichier à une possible conversion (`On` ou `Off`). Les extensions de fichiers peuvent commencer ou non par un point.

Si le format optionnel `On=direction` (or `Off=direction`) est employé, où direction est choisi parmi `In`, `Out` ou `InOut`, alors la directive ne s'applique seulement que dans une direction de transfert donnée (`In` : contenu reçu par une requête PUT ou POST , `Out` : contenu renvoyé à une requete GET ou POST, et `InOut` : conversion dans les deux directions).
Sinon, `InOut` (conversion dans les deux directions) est défini.

La configuration de conversion basé sur un type de fichier est testé avant la configuration basé sur les types MIME, afin de permettre aux règles génériques MIME d'être surchargées par une extension spécifique (pplusieurs extensions de fichier peuvent exister pour le même type MIME).

Exemple:
Avec la configuration suivante, les fichiers `*.html` contiennent du texte HTML au format EBCDIC, tandis que les fichiers `*.ahtml` contiennent du texte HTML au format ASCII :

        # *.html et *.ahtml contiennet du texte HTML :
        AddType  text/html  .html .ahtml

        # *.ahtml n'est pas converti (il contient déjà du texte ASCII)
        EBCDICConvert       Off .ahtml

        # Les autres fichiers text/html contiennent du texte EBCDIC:
        EBCDICConvertByType On  text/html

Voir également: EBCDICConvertByType et Aperçu des fonctions de conversion EBCDIC

## EBCDICConvertByType

Syntaxe : EBCDICConvertByType On|Off[=direction] mimetype [mimetype] ...
Contexte : configuration serveur, hôte virtuel, répertoire, .htaccess
Statut : noyau
Surcharge : FileInfo
Compatibilité : la conversion EBCDIC est disponible à partir de la version 1.3.19 d'Apache sur les plate-formes basées sur EBCDIC.

La directive EBCDICConvertByType associe un type MIME (pouvant contenir une *) à une éventuelle conversion (`On` ou `Off`).

Si le format optionnel `On=direction` (or `Off=direction`) est employé, où direction est choisi parmi `In`, `Out` ou `InOut`, alors la directive ne s'applique seulement que dans une direction de transfert donnée (`In` : contenu reçu par une requête PUT ou POST , `Out` : contenu renvoyé à une requete GET ou POST, et `InOut` : conversion dans les deux directions).
Sinon, `InOut` (conversion dans les deux directions) est défini.

Par exemple:
Une configuration standard pratique devrait au moins contenir ces directives :

        # All text documents are stored as EBCDIC files:
        # Tous les document textes sont stockés au format EBCDIC
        EBCDICConvertByType On  text/* message/* multipart/*
        EBCDICConvertByType On  application/x-www-form-urlencoded \
              model/vrml application/postscript
        # Les autres fichiers sont traités comme binaires.
        EBCDICConvertByType Off */*

Si vous servez seulement que des documents ASCII, par exemple provenant d'un montage NFS d'un serveur Unix, utilisez :

        # Tous les documents sont déjà en ASCII:
        EBCDICConvertByType Off */*

Voir également: EBCDICConvert et Aperçu des fonctions de conversion EBCDIC

## EBCDICKludge

Syntaxe : EBCDICKludge On|Off
Default: `EBCDICKludge Off`
Contexte : configuration serveur, hôte virtuel, répertoire, .htaccess
Statut : noyau
Surcharge : FileInfo
Compatibilité : EBCDICKludge est disponible à partir de la version 1.3.19 d'Apache sur les plate-formes basées sur EBCDIC. Il est désuet et sera abandonné dans les versions ultérieures.

The EBCDICKludge est proposée par compatibilité avec les versions d'Apache 1.3.0 à 1.3.18. Dans ces versions, tous les fichiers dont le type MIME commence par "text/", "message/" ou "multipart/" ou dont le type est "application/x-www-form-urlencoded" sont convertis par défaut, les autres documents sont retournés sans conversion. Un document est présumé être au format ASCII iuniquement si il est du type "`text/x-ascii-sous-type`", et ne sera donc pas converti. A la place, le préfixe "`x-ascii-`" était supprimé du type, obtenant ainsi le type MIME "`text/sous-type`" comme type du document retourné.

Si la directive EBCDICKludge est mise à `On`, et si aucune des extensions de fichiers ne correspondent aux directives EBCDICConvert définis dans le contexte , alors le serveur teste avec le type MIME de format `type/x-ascii-sous-type`. Si le document a un tel type alors la chaîne "`x-ascii-`" est supprimée et la conversion est mise à `Off`. Cela permet de surcharger l'assertion implicite que tous les fichiers sont stockés au format EBCDIC, par exemple si Apache sert des fichiers provenant d'un montage NFS d'un répertoire contenant des documents ASCII.
En utilisant EBCDICKludge, Il n'y a aucun moyen de forcer un des autres types MIME (par exemple model/vrml) d'être traité au format EBCDIC. L'utilisation de la directive EBCDICConvertByType est préférable pour définir une telle conversion. Avant Apache 1.3.19, il n'y avait aucun moyen de forcer ces document binaires d'être traités comme des fichiers textes EBCDIC

Voir également : EBCDICConvert, EBCDICConvertByType and Aperçu des fonctions de conversion EBCDIC

## Directive ErrorDocument

Syntaxe : ErrorDocument code d'erreur document
Contexte : configuration serveur, hôtes virtuels, répertoire, .htaccess
Statut : noyau
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 obtenues en utilisant 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'est -à-dire 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. Ceci peut perturber les robots et d'autres clients qui essaient de déterminer si une URL est valide en testant le code retour de la requête. De plus, si vous utilisez l'écriture `ErrorDocument 401` le client ne saura pas qu'il doit demander un mot de passe puisqu'il ne recevra pas le code retour 401. Par conséquent, il est impératif d'utiliser une URL locale pour une directive "ErrorDocument 401". 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` (Unix)
Défaut : `ErrorLog logs/error.log` (Windows et OS/2)
Contexte : configuration serveur, hôtes virtuels
Statut : noyau

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.

Si le fichier commence par une barre verticale (|), il est censé être une commande à exécuter pour ttraiter le message d'erreur.

Apache 1.3 et ultérieur: en utilisant `syslog` à la place d'un fichier permet d'employer syslogd(8) si le système l'accepte. Le défau est d'utiliser la fonction syslog `local7`, mais vous pouvez remplacer ceci en utilisant la syntaxe `syslog:`service où service peut être un des noms documenté dans syslog(1).

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 : noyau
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> ... </FilesMatch>
Contexte : configuration serveur, hôtes virtuels, .htaccess
Statut : noyau
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 : noyau

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

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.

## <IfDefine> directive

Syntaxe : <IfDefine [!]nom-paramètre> ... </IfDefine>
Défaut : aucun
Contexte : tous
Statut : noyau
Compatibilité : <IfDefine> est disponible à partir de la version 1.3.1

La section <IfDefine test>...</IfDefine> est employée pour délimiter des directives conditionnelles. Les directives à l'intérieur d'un section IfDefine ne sont prises en compte que si test est vraie. Si test est faux, tout ce qui se trouve entre le marqueur de début et celui de fin est ignoré.

Le test de la section <IfDefine> peut exister sous deux formes :

- nom-paramètre
- `!`nom-paramètre

Dans le premier cas, les directives entre les marqueurs de début et de fin ne sont traité que si le paramètre nommé nom-paramètre est défini. Dans le deuxième cas, les directives entre les marqueurs de début et de fin ne sont traité que si le paramètre nommé nom-paramètre n'est pas défini.

L'argument nom-paramètre est une définition qui peut être donnée en ligne de commande d'httpd en utilisant l'option `-D` nom-paramètre, au lancement du serveur.

Les sections <IfDefine> peuvent s'imbriquer, ce qui permet de réaliser des test sur plusieurs paramètres. Par exemple :

      $ httpd -DReverseProxy ...

      # httpd.conf
      <IfDefine ReverseProxy>
      LoadModule rewrite_module libexec/mod_rewrite.so
      LoadModule proxy_module   libexec/libproxy.so
      </IfDefine>

## Directive <IfModule>

Syntaxe : <IfModule [!]nomModule> ... </IfModule>
Défaut : aucun
Contexte : tous
Statut : noyau
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 :

- nomModule
- !nomModule

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 : Include nomfichier
Contexte : configuration serveur
Statut : noyau
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.

A partir de la version Apache 1.3.13, si `Include` pointe vers un répertoire plutot qu'un fichier, Apche lira tous fichiers de ce répertoire, ou des sous-répertoires, et traitera chacun de ces fichiers de configuration.

## 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 : noyau
Compatibilité : KeepAlive est disponible à partir de la version 1.1 d'Apache.

L'extension Keep-Alive d'HTTP/1.0 et les connexions persistantes d'HTTP/1.1 fournissent des sessions durables HTTP , qui autorisent plusieurs requêtes à être envoyées sur la même connexion. Dans certains cas, il a été constaté une réduction de 50% du temps de latence ppour des documents HTML contenant de nombreuses images. Pour activer les connexions persistantes (keep-alive) à partir d'Apache 1.2 il faut définir la directive `KeepAlive On`.

Pour les clients HTTP/1.1, Les connexions persistantes ne sont employées que si elles sont spécifiquement demandées par un client. De plus, une connexion persistantes ne peut être employées que si la taille du contenu est connu à l'avance. Ceci implique que les contenus dynamiques, tels que les scripts CGI, les pages SSI, et les listes de répertoires générés par le serveur n'utilisent pas de connexions persistentes pour les clients HTTP/1.0. Pour les clients HTTP/1.1, les connexions sont persistantes par défaut à moins d'être spécifiée. Si le client le demande, l'encodage par tranches est utilisé afin d'envoyer des contenus de tailles inconnus au travers de connxions persistantes.

Sous Apache 1.1: Mettre requêtesMax au nombre maximum de requêtes qu'Apache peut traiter par connexion persistante. Une limitation est imposée pour éviter qu'un client ne vienne asphyxier votre serveur en ressources. Mettre un `0` pour désactiver ce support. A partir de la version 1.2, ceci est contrôlé par la directive MaxKeepAliveRequests

Voir aussi la directive MaxKeepAliveRequests.

## Directive KeepAliveTimeout

Syntaxe : KeepAliveTimeout secondes
Défaut : `KeepAliveTimeout 15`
Contexte : configuration serveur
Statut : noyau
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.

Mettre `KeepAliveTimeout` à une grande valeur peut créer des problèmes de performance pour des serveurs chargés. Le plus grand est ce délai, le plus les processus du serveur seront occupés en attente de connexions avec des clients inactifs.

## Directive <Limit>

Syntaxe : <Limit méthode méthode ... > ... </Limit>
Contexte : tous
Statut : noyau

Les contrôles d'accès sont normalement actives pour toutes les méthodes d'accès, et ceci est le comportement normal. En général, les directives de contrôle d'accès ne doivent être placées à l'intérieur d'une section `<limit>`.

Le but de la directive <Limit> est de restreindre la portée des contrôles d'accès à certaines méthodes HTTP. Pour toutes les autres méthodes, les restrictions d'accès qui sont situées à l'intérieur de <Limit> sont sans effets. L'exemple suivant applique le contrôle d'accès uniquement aux méthodes POST, PUT, and DELETE, laissant les autres méthodes non protégées :

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

Les noms de méthodes peuvent être choisis parmi GET, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, et UNLOCK. Le nom de la méthode est sensible à la casse. Si GET est employé, il restreindra également les requêtes HEAD.

## Directive <LimitExcept>

Syntaxe : <LimitExcept méthode [méthode] ... > ... </LimitExcept>
Contexte : tous
Statut : noyau
Compatibilité : disponible à partir de la version 1.3.5 d'Apache.

<LimitExcept> et </LimitExcept> sont employés pour entourer un groupe de directives de contrôle d'accès qui s'appliqueront pour n'importe quelle méthode d'accès ne se trouvant pas en arguments Cette directive est l'oppsée de <Limit> et peut être employée pour contrôler les méthodes non reconnues ou non standard. Voir la documentation de <Limit> pour plus de détails.

## Directive LimitRequestBody

Syntaxe : LimitRequestBody octets
Défaut : `LimitRequestBody 0`
Contexte : configuration serveur, hôte virtuel, répertoire .htaccess
Statut : noyau
Compatibilité : LimitRequestBody est disponible à partir de la version 1.3.2.

Cette directive détermine la taille maximale en octets que peut avoir le corps d'une requête. Elle peut aller de 0 (illimité) à 2147483647 (2GB). La valeur par défaut est déterminée à la compilation par la constante `DEFAULT_LIMIT_REQUEST_BODY` (0 dans les distributions).

La directive LimitRequestBody directive permet à l'utilisateur de fixer une limite à la taille du corps d'une requête à l'intérieur du contexte où cette directive est située (serveur, par répertoire, par fichier). Si le client effezctue une requête excédant cette limite, le serveur retournera un message d'erreur au lieu de traiter la requête. La taille d'une requête normale peut beaucoup varier en fonction de la nature de la ressource demandée et des méthodes d'accès permise sur cette ressource. Typiquement les scripts CGI utilise le corps du message pour passer des informations au serveur. Des implémentation de la méthode PUT nécessite une valeur au moins aussi grande que le serveur souhaite recevoir pour cette ressource.

Cette directive donne à l'administrateur un plus grand contrôle par rapport à des requêtes anormales de clients, et peut être utile pour éviter certaines formes d'attaques par déni de service.

## Directive LimitRequestFields

Syntaxe : LimitRequestFields number
Défaut : `LimitRequestFields 100`
Contexte : configuration serveur
Statut : noyau
Compatibilité : LimitRequestFields est disponible à partir de la version 1.3.2.

Number est un entier allant de 0 (signifiant sans limite) à 32767. La valeur par défaut est définie à la compilation par la constante `DEFAULT_LIMIT_REQUEST_FIELDS` (100 dans la distribution).

La directive LimitRequestFields permet à l'administrateur du serveur de modifier le nombre maximum de champs autorisé à l'intérieur de l'en-tête d'une requête HTTP. Un serveur doit avoir cette valeur supérieure au nombre de champs qu'un client normal peut inclure. Le nombre de champs utilisé par un client excède rarement 20, mais ceci peut varier en fonction de l'implémentation des clients, le plus souvent il dépend du niveau auquel le client a configuré son butineur pour accepter une négociation de contenu très fine. Les extensions HTTP optionnelles sont exprimées en utilisant des champs dans l'en-tête de requête.

Cette directive permet à l'administrateur un meilleur contrôle par rapport à des requêtes anormales, ce qui peut être utile pour éviter certaines attaques par déni de service. Cette valeur doit être augmentée si certains clients obtiennent un message d'erreur à leurs requêtes indiquant que trop de champs sont envoyés dans la requête.

## Directive LimitRequestFieldsize

Syntaxe : LimitRequestFieldsize octets
Défaut : `LimitRequestFieldsize 8190`
Contexte : configuration serveur
Statut : noyau
Compatibilité : LimitRequestFieldsize est disponible à partir de la version 1.3.2.

Cette directive indique la taille maximale de l'en-tête d'une requête HTTP et peut aller de 0 octets à la valeur définit à la compilation par la constante `DEFAULT_LIMIT_REQUEST_FIELDSIZE` (8190 dans la distribution standard).

La directive LimitRequestFieldsize permet à l'administrateur de limiter la taille autorisée pour le champ d'en-tête HTTP d'une requête à une valeur inférieure à celle définie à la compilation. Un serveur doit avoir cette valeur suffisamment grande pour pouvoir traiter les requêtes de clients normaux. La taille d'une requête noramle peut beaucoup varier en fonction de l'implémentation du client, le plus souvent il dépend du niveau auquel le client a configuré son butineur pour accepter une négociation de contenu très fine.

Cette directive permet l'administrateur d'avoir un meilleur contrôle sur des requêtes ayant un comportement anormale, ce qui peut être utile afin d'éviter certaines formes d'attaques par déni de service. Dans des conditions normales, cette valeur doit rester celle par défaut.

## Directive LimitRequestLine

Syntaxe : LimitRequestLine octets
Défaut : `LimitRequestLine 8190`
Contexte : configuration serveur
Statut : noyau
Compatibilité : LimitRequestLine est disponible à partir de la version 1.3.2.

Cette directive indique la taille maximale d'une requête HTTP et peut aller de 0 octets à la valeur définit à la compilation par la constante `DEFAULT_LIMIT_REQUEST_LINE` (8190 dans la distribution standard).

La directive LimitRequestLine permet à l'administrateur de réduire la limite fixée pour une requête HTTP en dessous de la valeur fixée à la compilation. Comme une requête est composée de la méthode HTTP, d'une URI et de la version du protocole utilisé, la directive LimitRequestLine place une restriction sur la taille maximale que peut avoir une URI dansune requête. Un serveur doit avoir cette valeur suffisamment grande pour pouvoir traiter n'importe quelle de ses ressources, en prenant en compte les informations qui pourrait être passées dans une requête GET.

Cette directive permet l'administrateur d'avoir un meilleur contrôle sur des requêtes ayant un comportement anormale, ce qui peut être utile afin d'éviter certaines formes d'attaques par déni de service. Dans des conditions normales, cette valeur doit rester celle par défaut.

## Directive Listen

Syntaxe : Listen [adresseIp:]numéroPort
Contexte : configuration serveur
Statut : noyau
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 : noyau
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)`.

Cette directive est limitée à un petit nombre par le système d'exploitation. Elle peut varier d'un système à un autre. Il faut également noter que pour la plupart des systèmes, la valeur réellement utilisée n'est pas celle spécifiée par la directive, mais un nombre basé sur cette valeur (généralement plus grande).

## Directive <Location>

Syntaxe : <Location URL> ... </Location>
Contexte : configuration serveur, hôtes virtuels
Statut : noyau
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.

Il faut noter que les URL n'ont pas du tout à suivre la même organisation que le système de fichiers, et il faut souligner que la directive <Location> opère de manière totalement indépendante du système de fichiers.

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. POur les requêtes à un proxy, l'URL doitt être de la forme `scheme://nomserveur/serveur`, et vous devez inclure le préfixe.

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>

Note sur / (barre oblique) pour les version supérieures à 1.3: La caractère barre oblique à une signification particulière en fonction de l'endroit où il se situe. Des personnes sont habitués au comportement dans certains systèmes de fichiers où de multiples caractères obliques sont remplacés par un caractère unique (par exemple `/home///foo` est identique à `/home/foo`). Dans le monde des URL ceci n'est pas obligatoirement vrai. La directive `<LocationMatch>` et la version avec expression régulière de `<Location>` demande de spécifier plusieurs caractères obliques si ceci est votre intention. Par exemple, `<LocationMatch ^/abc>` fonctionnera avec l'URL `/abc` mais pas avec l'URL `//abc`. La directive (sans expression régulière) `<Location>` se comporte de manière similaire quand elle est employée pour des requêtes proxy. Mais si la directive (sans expression régulière) `<Location>` est utilisée pour des requêtes sans proxy, il associera implicitement plusieurs obliques à un seul. Par exemple, si vous spécifiez `<Location /abc/def>` et que la requête est `/abc//def` celle ci correspondra.

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

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.

SECURITE : il vaut mieux éviter de metttre ce fichier dans un répertoire inscriptible par tout le monde tel que `/var/tmp` cas quelqu'un pourrait créer une attaque par déni de service et empécher le serveur de redémarrer en créant un fichier de verrouillage de même nom que celui que veut créer le serveur.

## Directive LogLevel

Syntaxe : LogLevel niveau
Défaut : `LogLevel error`
Contexte : configuration serveur, hôtes virtuels
Statut : noyau
Compatibilité : LogLevel est disponible à partir de la version 1.3.

LogLevel ajuste le niveau de verbosité des messages inscrits dans les traces d'erreur (voir la directive ErrorLog). Les niveaux possibles sont par ordre de gravité décroissante :

Niveau | Description
--- | ---
| Exemple
`emerg` | Urgences - le système est inutilisable.
| "Child cannot open lock file. Exiting"
`alert` | Une action doit être prise immédiatement.
| "getpwuid: couldn't determine user name from uid"
`crit` | Conditions critiques.
| "socket: Failed to get a socket, exiting child"
`error` | Cas d'erreur.
| "Premature end of script headers"
`warn` | Avertissements.
| "child process 1234 did not exit, sending another SIGHUP"
`notice` | Normal mais condition significative.
| "httpd: caught SIGBUS, attempting to dump core in ..."
`info` | Pour information.
| "Server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers)..."
`debug` | Messages de déboguage
| "Opening config file ..."

Quand un niveau est spécifié, les messages des niveaux de plus haute gravité seront également rapportés. Par exemple, quand la directive `LogLevel info` est définie, les messages de niveau `notice` et `warn` seront aussi notifiés.

L'utilisation d'un niveau de gravité d'au moins `crit` est recommandé.

## Directive MaxClients

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

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é. Pour configurer plus de 256 clients, vous devez modifier la constante HARD_SERVER_LIMIT du fichier source d'Apache httpd.h et recompiler Apache.

Les tentatives de connexions au delà de MaxClients sont normalement mises en attente, jusqu'à une limite fixée par la directive ListenBacklog. Une fois qu'un processus fils est libre à la fin d'une requête différente, la connexion en attente est traitée.

## Directive MaxKeepAliveRequests

Syntaxe : MaxKeepAliveRequests nombre
Défaut : `MaxKeepAliveRequests 100`
Contexte : configuration serveur
Statut : noyau
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. Dans la version 1.1 d'Apache, ceci est contrôlé par la directive Keepalive

## Directive MaxRequestsPerChild

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

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 :

- cela limite le volume de mémoire qu'un processus peut consommer (accidentellement) et évite une saturation mémoire ;
- en donnant à un processus un temps de vie fini, le nombre total de processus impliqués dans le serveur décroit lorsque la charge du serveur retombe.

Cependant sur les systèmes Win32, il est recommandé de mettre cette valeur à 0. Si celle ci est à une valeur non nulle, quand le nombre de requêtes est atteint, le processus fils quitte, et est relancé en relisant les fichiers de configuration. Ceci peut conduire à un comportement imprévisible si vous avez modifié un fichier de configuration, mais ne souhaitez pas que ces changements soient pris en compte. Voir également ThreadsPerChild.

NOTE: pour les requêtes KeepAlive requests, seule la première requête est comptée. En réalité, il change le comportement afin de limiter le nombre de connexions par fils.

## Directive MaxSpareServers

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

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.

Cette directive n'a aucun effet quand elle est employée sur les plates-formes WIndows.

Voir aussi MinSpareServers et StartServers.

## Directive MinSpareServers

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

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.

Cette directive n'a aucun effet quand elle est employée sur les plates-formes WIndows.

Voir aussi MaxSpareServers et StartServers.

## Directive NameVirtualHost

Syntaxe : NameVirtualHost addr[:port]
Contexte : configuration serveur
Statut : noyau
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).

Note: le "serveur principal" et tous les serveurs "par défaut" ne seront jamais servis pour une requête vers une adresse IP NameVirtualHost (à moins que pour une raison donnée vous définissiez NameVirtualHost mais qu'aucun VirtualHosts ne soit défini pour cette 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`

A partir de la version 1.3.13, vous pouvez donner comme adresse `*` Ceci crée un NameVirtualHost qui correspond à toutes les connexions venant de toutes les adresses IP qui ne sont pas configurés avec une autre directive NameVirtualHost ou un section <VirtualHost>. Cette option est pratique si vous n'utilisez que des hôtes virtuels nommés et que vous ne souhaitez pas coder en dur l'adresse IP de votre machine dans le fichier de configuration.
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 : noyau

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

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

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

- En absence de toute directive Listen ou BindAddress spécifiant un numéro de port, la directive `Port` définit le port réseau que le serveur écoute. S'il existe une directive `Listen` ou `BindAddress` spécifiant un `:numéro` alors la directive Port n'a aucun effet quant au socket que le serveur écoute.
- La directive Port définit la variable d'environnement `SERVER_PORT` (pour les CGI et les SSI), laquelle est utilisée lorsque le serveur génère une URL qui point sur lui-même (par exemple lorsqu'il indique une indirection externe vers lui-même).

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

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

- require user utilisateur utilisateur ...

  Seuls les utilisateurs nommés peuvent accéder au répertoire.

- require group nomGroupe nomGroupe ...

  Seuls les utilisateurs des groupes cités peuvent accéder au répertoire.

- require valid-user

  Tout utilisateur reconnu peut accéder au répertoire (par opposition aux non utilisateurs).

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

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`

ou sur les serveurs Win32

> `ResourceConfig nul`

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.

A partir de la version 1.3.13, si la directive `ResourceConfig` pointe sur un répertoire plutot qu'un fichier, Apache lira tous les fichiers de ce répertoire ou de ses sous-répertoires et les traitera comme fichiers de configuration.

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

Ceci est valide pour les processus lancés par les processus fils d'Apache pour le traitement des requêtes et non pour les processus fils d'Apache eux-mêmes. Cela inclut les scripts CGI, les commandes exec SSI, mais pas les processus lancés par le processu Apache père tels que les traces.

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

Ceci est valide pour les processus lancés par les processus fils d'Apache pour le traitement des requêtes et non pour les processus fils d'Apache eux-mêmes. Cela inclut les scripts CGI, les commandes exec SSI, mais pas les processus lancés par le processu Apache père tels que les traces.

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

Ceci est valide pour les processus lancés par les processus fils d'Apache pour le traitement des requêtes et non pour les processus fils d'Apache eux-mêmes. Cela inclut les scripts CGI, les commandes exec SSI, mais pas les processus lancés par le processu Apache père tels que les traces.

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

Voir aussi Require et Allow.

## Directive ScoreBoardFile

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

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. (avant la version 1.3b4, `HAVE_SHMGET` devait suffire.)

Voir aussi : Arrêter et redémarrer Apache

## ScriptInterpreterSource directive

Syntaxe : ScriptInterpreterSource registry|script
Défaut : `ScriptInterpreterSource script`
Contexte : répertoire, .htaccess
Statut : noyau (seulement sur Windows)

Cette directive sert, à partir de la version 1.3.5 d'Apache, à déterminer où trouver l'interpréteur employé pour exécuter les scripts CGI. La technique par défaut est de prendre l'interpréteur pointé par les caractères #! dans le script. En fixant ScriptInterpreterSource à registry, La table de registration de Windows sera employée pour chercher l'interpréteur, en prenant l'extension du fichier comme clé (par exemple .pl).

## Directive SendBufferSize

Syntaxe : SendBufferSize octets
Contexte : configuration serveur
Statut : noyau

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

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 www-admin@foo.bar.com`

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

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

Si vous utilisez des hôtes virtuels nommés, la directive `ServerName` à l'intérieur d'une section `<VirtualHost>` impose que quel nom d'hôte doit apparaître dans l'en-tête `Host:` d'une requête pour être associé à cet hôte virtuel.

Voir aussi : Apache et DNS documentation sur les hôtes virtuels Apache
UseCanonicalName
NameVirtualHost
ServerAlias

## Directive ServerPath

Syntaxe : ServerPath chemin
Contexte : hôte virtuel
Statut : noyau
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 : noyau

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.

Voir aussi les trucs de sécurité pour plus d'informations sur comment correctment définir les droits d'accès à ServerRoot.

## Directive ServerSignature

Syntaxe : ServerSignature On|Off|EMail
Défaut : `ServerSignature Off`
Contexte : configuration serveur, hôte virtuel, répertoire, .htaccess
Statut : noyau
Compatibilité : ServerSignature est disponible à partir de la version 1.3.

La directive ServerSignature permet la configuration d'une ligne de bas de page pour les documents générés par le serveur (messages d'erreur, liste des répertoire ftp, affichage de mod_info, ...) L'utilité de l'emploi d'une telle ligne apparaît dans la cas d'enchaînement de proxy, où l'utilisateuir souvent n'a aucune possibilité de déterminer quel élément de la chaîne de proxies a produit un message d'erreur.
La valeur par défaut `Off` supprime la ligne d'erreur (et est compatible avec le comportement d'Apache 1.2 et précédents). La valeur `On` ajoute une ligne contenant la version du serveur, la valeur de ServerName de l'hôte virtuel et la valeur `EMail` ajoute une référence "mailto:" vers l'adresse ServerAdmin du document demandé.

## Directive ServerTokens

Syntaxe : ServerTokens Minimal|ProductOnly|OS|Full
Défaut : `ServerTokens Full`
Contexte : configuration serveur
Statut : noyau
Compatibilité : ServerTokens est disponible à partir de la version 1.3 d'Apache. Le mot clé `ProductOnly` est disponible à pertir de la version 1.3.12

Cette directive contrôle si le champ `Server` de l'en-tête de réponse qui est renvoyé aux clients inclut une description du type de système de du serveur ainsi que des informations sur les odules compilés.

`ServerTokens Prod[uctOnly]`
  Le serveur renvoie par exemple : `Server: Apache`
`ServerTokens Min[imal]`
  Le serveur renvoie par exemple : `Server: Apache/1.3.0`
`ServerTokens OS`
  Le serveur renvoie par exemple : `Server: Apache/1.3.0 (Unix)`
`ServerTokens Full` (ou non spécifié)
  Le serveur renvoie par exemple : `Server: Apache/1.3.0 (Unix) PHP/3.0 MyMod/1.2`

Cette directive s'applique à la globalité du serveur et ne paut pas être activé ou désactivé sur la base d'hôtes virtuels.

## Directive ServerType

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

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.

## Directive StartServers

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

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 n'a aucun effet. Comme la version Windows d'Apache est écrite en multithread, un seul processus gère l'intégralité des requêtes. La directive ThreadsPerChild contrôle le nombre maximal de threads traitant les requêtes, ce qui a un effet similaire à la directive Unix `StartServers`

Voir aussi MinSpareServers et MaxSpareServers.

## Directive ThreadsPerChild

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

Cette directive indique au serveur combien de threads 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é.

Cette directive n'a aucun effet sur les systèmes Unix. Les utilisateurs Unix regarderont les directives StartServers et MaxRequestsPerChild.

## Directive ThreadStackSize

Syntaxe : ThreadStackSize nombre
Défaut : `ThreadStackSize 65536`
Contexte : configuration serveur
Statut : noyau (NetWare)
Compatibilité : disponible à partir de la version d'Apache 1.3 sur Netware.

Cette directive indique la taille de la pile à utiliser pour les threads. Si vous rencontrer un problème de débordement de pile, vous devez augmenter cette valeur.

Cette directive n'a aucun effet sur les autres systèmes.

## Directive TimeOut

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

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

## UseCanonicalName directive

Syntaxe : UseCanonicalName on|off|dns
Défaut : `UseCanonicalName on`
Contexte : configuration serveur, hôte virtuel, répertoire
Surcharge : Options
Compatibilité : UseCanonicalName est disponible à partir de la verion 1.3

Dans beaucoup de situations, Apache doit construire des URL s'autoréférençant, autremnet dit, des URL référençant le même serveur. Avec la directive `UseCanonicalName on` (dans les versions d'Apache inférieures à 1.3) Apache utilise les valeurs des directives ServerName et Port pour construire un nom canonique du serveur. Ce nom est utilisé pour toutes les URL autoréférentes et pour les valeurs de `SERVER_NAME` et `SERVER_PORT` pour les scripts CGI.

Avec `UseCanonicalName off`, Apache formera les URLS autoréférentes en utilisant le nom d'hôte le numéro de port fourni par le client si ceux ci sont fournis (sinon il utilisera le nom canonique). Ces valeurs sont les mêmes qui sont employées pour implémenter les hôtes virtuels basés sur des noms, et sont disponibles pour les mêmes clients. Les variable CGI `SERVER_NAME` et `SERVER_PORT` seront aussi construites à partir des valeurs fournies par les clients.

Un exemple où cette directive est utile est le cas d'un serveur intranet où des utilisateurs se connectent à la machine en utilisant des noms courts tels que `www`. Vous noterez que si l'utilisateur tape un nom court et que l'URL est un répertoire tel que `http://www/splat`, sans le caractère oblique / final , Apache redirigera la requête vers `http://www.domain.com/splat/`. Si vous avez une authentification active, lu'tilisateur devra s'authentifier deux fois, (une première fois pour `www` et une deuxième fois pour An example where this may be useful is on an intranet server where you have users connecting to the machine using short names such as . You'll notice that if the users type a `www.domain.com`). Mais si la directive `UseCanonicalName` est à off, Apache redirigera vers `http://www/splat/`.

Il existe une troisième option, `UseCanonicalName DNS`, qui est prévu pour être employé avec de nombreux hôtes virtuels basés sur les adresses IP afin de supporter les clients qui ne fournissent pas d'en-tête `Host:`. Avec cette option Apache effectue une résolution DNS inverse sur l'adresse IP du serveur sur lequel le client se connecte afin de travailler avec pour les URL autoréférentes.

Attention : si les scripts CGI font des suppositions sur les valeurs de `SERVER_NAME` il peuvent ne plus fonctionner avec cette option. Mais le script CGI utilise uniquement `SERVER_NAME` pour construire des URL autoréférentes, il ne evrait y avoir aucun problèmes.

Voir également : ServerName, Port

## Directive User

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

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. Par exemple, le cache de mod_proxy quancd celui est activé , doit être accessible à cette utilisateur (voir la directive `CacheRoot` ).

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 :

- l'adresse IP de l'hôte virtuel
- un nom de domaine entièrement qualifié pour l'adresse IP de cet hôte virtuel.

Exemple :

>     <VirtualHost 10.1.2.3>
>     ServerAdmin webmaster@host.foo.com
>     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 serveur, 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)).

Vous pouvez spécifier plus d'une adresse IP. Ceci peut être utile si une machine répond au même nom venant de deux différentes interfaces. Par exemple, si vous avez un hôte virtuel qui est accessible des hôtes à partir d'un réseau interne (intranet) et externe (internet). Exemple :

> `<VirtualHost 192.168.1.2 204.255.176.199>
> DocumentRoot /www/docs/host.foo.com
> ServerName host.foo.com
> ServerAlias host
> </VirtualHost>`

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 spécifier 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