You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by sl...@apache.org on 2001/06/19 05:04:48 UTC
cvs commit: httpd-docs-1.3/htdocs/manual/mod core.html.fr
slive 01/06/18 20:04:48
Added: htdocs/manual/mod core.html.fr
Log:
French translation of core.html.
Submitted by: Valery Fremaux, Herve Dumont <hd...@club-internet.fr>
Revision Changes Path
1.1 httpd-docs-1.3/htdocs/manual/mod/core.html.fr
Index: core.html.fr
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!--Traduction anglais 1.188 -->
<html>
<head>
<meta http-equiv="Content-Type" content=
"text/html; charset=iso-8859-1">
<title>Noyau d'Apache</title>
</head>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<body bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink=
"#000080" alink="#FF0000">
<!--#include virtual="header.html" -->
<h1 align="center">Noyau d'Apache</h1>
<p>Ces paramètres de configuration contrôlent les
fonctionnalités premières d'Apache, et sont
toujours disponibles.</p>
<h2>Directives</h2>
<ul>
<li><a href="#accessconfig">AccessConfig</a></li>
<li><a href="#accessfilename">AccessFileName</a></li>
<li><a href="#adddefaultcharset">AddDefaultCharset</a></li>
<li><a href="#addmodule">AddModule</a></li>
<li><a href="#allowoverride">AllowOverride</a></li>
<li><a href="#authname">AuthName</a></li>
<li><a href="#authtype">AuthType</a></li>
<li><a href="#bindaddress">BindAddress</a></li>
<li><a href="#bs2000account">BS2000Account</a></li>
<li><a href="#clearmodulelist">ClearModuleList</a></li>
<li><a href="#contentdigest">ContentDigest</a></li>
<li><a href="#coredumpdirectory">CoreDumpDirectory</a></li>
<li><a href="#defaulttype">DefaultType</a></li>
<li><a href="#directory"><Directory></a></li>
<li><a href="#directorymatch"><DirectoryMatch></a></li>
<li><a href="#documentroot">DocumentRoot</a></li>
<li><a href="#ebcdicconvert">EBCDICConvert</a></li>
<li><a href="#ebcdicconvertbytype">EBCDICConvertByType</a></li>
<li><a href="#ebcdickludge">EBCDICKludge</a></li>
<li><a href="#errordocument">ErrorDocument</a></li>
<li><a href="#errorlog">ErrorLog</a></li>
<li><a href="#files"><Files></a></li>
<li><a href="#filesmatch"><FilesMatch></a></li>
<li><a href="#group">Group</a></li>
<li><a href="#hostnamelookups">HostNameLookups</a></li>
<li><a href="#identitycheck">IdentityCheck</a></li>
<li><a href="#ifdefine"><IfDefine></a></li>
<li><a href="#ifmodule"><IfModule></a></li>
<li><a href="#include">Include</a></li>
<li><a href="#keepalive">KeepAlive</a></li>
<li><a href="#keepalivetimeout">KeepAliveTimeout</a></li>
<li><a href="#limit"><Limit></a></li>
<li><a href="#limitexcept"><LimitExcept></a></li>
<li><a href="#limitrequestbody">LimitRequestBody</a></li>
<li><a href="#limitrequestfields">LimitRequestFields</a></li>
<li><a href=
"#limitrequestfieldsize">LimitRequestFieldsize</a></li>
<li><a href="#limitrequestline">LimitRequestLine</a></li>
<li><a href="#listen">Listen</a></li>
<li><a href="#listenbacklog">ListenBacklog</a></li>
<li><a href="#location"><Location></a></li>
<li><a href="#locationmatch"><LocationMatch></a></li>
<li><a href="#lockfile">LockFile</a></li>
<li><a href="#loglevel">LogLevel</a></li>
<li><a href="#maxclients">MaxClients</a></li>
<li><a href="#maxkeepaliverequests">MaxKeepAliveRequests</a></li>
<li><a href="#maxrequestsperchild">MaxRequestsPerChild</a></li>
<li><a href="#maxspareservers">MaxSpareServers</a></li>
<li><a href="#minspareservers">MinSpareServers</a></li>
<li><a href="#namevirtualhost">NameVirtualHost</a></li>
<li><a href="#options">Options</a></li>
<li><a href="#pidfile">PidFile</a></li>
<li><a href="#port">Port</a></li>
<li><a href="#require">require</a></li>
<li><a href="#resourceconfig">ResourceConfig</a></li>
<li><a href="#rlimitcpu">RLimitCPU</a></li>
<li><a href="#rlimitmem">RLimitMEM</a></li>
<li><a href="#rlimitnproc">RLimitNPROC</a></li>
<li><a href="#satisfy">Satisfy</a></li>
<li><a href="#scoreboardfile">ScoreBoardFile</a></li>
<li><a href=
"#scriptinterpretersource">ScriptInterpreterSource</a></li>
<li><a href="#sendbuffersize">SendBufferSize</a></li>
<li><a href="#serveradmin">ServerAdmin</a></li>
<li><a href="#serveralias">ServerAlias</a></li>
<li><a href="#servername">ServerName</a></li>
<li><a href="#serverpath">ServerPath</a></li>
<li><a href="#serverroot">ServerRoot</a></li>
<li><a href="#serversignature">ServerSignature</a></li>
<li><a href="#servertokens">ServerTokens</a></li>
<li><a href="#servertype">ServerType</a></li>
<li><a href="#startservers">StartServers</a></li>
<li><a href="#threadsperchild">ThreadsPerChild</a></li>
<li><a href="#threadstacksize">ThreadStackSize</a></li>
<li><a href="#timeout">TimeOut</a></li>
<li><a href="#usecanonicalname">UseCanonicalName</a></li>
<li><a href="#user">User</a></li>
<li><a href="#virtualhost"><VirtualHost></a></li>
</ul>
<hr>
<h2><a name="accessconfig">Directive AccessConfig</a></h2>
<!--%plaintext <?INDEX {\tt AccessConfig} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> AccessConfig <em>nomfichier</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>AccessConfig
conf/access.conf</code><br>
<a href="directive-dict.html#Context" rel=
"Help"><strong>Context:</strong></a> configuration serveur,
hôtes virtuels<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>Le serveur lit dans ce fichier des directives
supplémentaires après avoir ouvert le fichier <a
href="#resourceconfig">ResourceConfig</a>. <em>nomfichier</em>
est exprimé relativement à <a href=
"#serverroot">ServerRoot</a>. Cette fonctionnalité peut
être désactivée en écrivant :</p>
<blockquote><code>AccessConfig /dev/null</code></blockquote>
ou sur les serverus Win32
<blockquote><code>AccessConfig nul</code></blockquote>
<p>Historiquement, ce fichier ne contenait que des sections <a
href="#directory"><Directory></a>; en fait, il pourra
maintenant contenir toute directive "serveur" autorisée
dans le contexte de la <em>configuration serveur</em>.</p>
<p>Une nouveauté de la version d'Apache 1.3.13 est la
possibilité qu'<code>AccessConfig</code> 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.</p>
<p>Voir également <a href=
"#resourceconfig">ResourceConfig</a>.</p>
<hr>
<h2><a name="accessfilename">Directive AccessFileName</a></h2>
<!--%plaintext <?INDEX {\tt AccessFileName} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> AccessFileName <em>nomfichier</em>
[<em>nomfichier</em>] ...<br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>AccessFileName
.htaccess</code><br>
<a href="directive-dict.html#Context" rel=
"Help"><strong>Context:</strong></a> configuration serveur,
hôte virtuel<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> AccessFileName
ne peut accepter plusieurs noms de fichiers qu'à partir de
la version 1.3 d'Apache
<p>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:</p>
<blockquote><code>AccessFileName .acl</code></blockquote>
<p>Avant de servir le document
<code>/usr/local/web/index.html</code>, le serveur lira les
fichiers <code>/.acl</code>, <code>/usr/.acl</code>,
<code>/usr/local/.acl</code> et <code>/usr/local/web/.acl</code>
à la recherche de directives, sauf si celles-ci ont
été désactivées par
l'écriture</p>
<blockquote><code><Directory /> AllowOverride None
</Directory></code></blockquote>
<p><strong>Voir également :</strong> <a href=
"#allowoverride">AllowOverride</a></p>
<hr>
<h2><a name="adddefaultcharset">Directive
AddDefaultCharset</a></h2>
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> AddDefaultCharset On|Off|<em>charset</em><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> tous<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a>
<code>AddDefaultCharset Off</code><br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a>
AddDefaultCharset n'est disponible qu'à partir de la
version 1.3.12
<p>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 <code>META</code>. La mise de
<code>AddDefaultCharset Off</code> désactive cette
fonctionnalité. <code>AddDefaultCharset On</code> active
la table de caractère <code>iso-8859-1</code> par
défaut d'Apache. Vous pouvez également
définir une autre table de caractères à
employer. Par exemple <code>AddDefaultCharset utf-8</code>.</p>
<hr>
<h2><a name="addmodule">Directive AddModule</a></h2>
<!--%plaintext <?INDEX {\tt AddModule} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> AddModule <em>module</em> [<em>module</em>]
...<br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur <br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a>
<tt>AddModule</tt> n'est disponible qu'à partir de la
version 1.2 d'Apache
<p>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 <a href=
"#clearmodulelist">ClearModuleList</a>.</p>
<hr>
<h2><a name="allowoverride">Directive AllowOverride</a></h2>
<!--%plaintext <?INDEX {\tt AllowOverride} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> AllowOverride All|None|<em>type de directive</em>
[<em>type de directive</em>] ... <br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>AllowOverride
All All</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> répertoire<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>Lorsque le serveur trouve un fichier .htaccess (comme
spécifié par <a href=
"#accessfilename">AccessFileName</a>) il doit savoir quelles
directives declarées dans ce fichier peuvent outrepasser
les droits fixés par des directives
précédentes.</p>
<p>Si la directive est définie à <code>None</code>,
les fichier .htaccess sont ignorés. Dans ce cas, le
serveur n'essaie même pas de lire les fichiers
.htaccess.</p>
<p>Si la directive est définie à <code>All</code>
toutes les directives possibles dans le <a href=
"directive-dict.html#Context">contexte</a> .htacces sont
autorisées dans les fichiers .htaccess.</p>
<p>Les <em>types de directives</em> peuvent être parmi ces
groupes de directives :</p>
<dl>
<dt>AuthConfig</dt>
<dd><!--%plaintext <?INDEX {\tt AuthConfig} override> -->
Autorise l'usage de la directive Authorization (<a href=
"mod_auth_dbm.html#authdbmgroupfile">AuthDBMGroupFile</a>, <a
href="mod_auth_dbm.html#authdbmuserfile">AuthDBMUserFile</a>, <a
href="mod_auth.html#authgroupfile">AuthGroupFile</a>, <a href=
"#authname">AuthName</a>, <a href="#authtype">AuthType</a>, <a
href="mod_auth.html#authuserfile">AuthUserFile</a>, <a href=
"#require">Require</a>, etc.).</dd>
<dt>FileInfo</dt>
<dd><!--%plaintext <?INDEX {\tt FileInfo} override> -->
Autorise l'usage de directives contrôlant l'accès
aux types de documents (<a href=
"mod_mime.html#addencoding">AddEncoding</a>, <a href=
"mod_mime.html#addlanguage">AddLanguage</a>, <a href=
"mod_mime.html#addtype">AddType</a>, <a href=
"#defaulttype">DefaultType</a>, <a href=
"#errordocument">ErrorDocument</a>, <a href=
"mod_negotiation.html#languagepriority">LanguagePriority</a>,
etc.).</dd>
<dt>Indexes</dt>
<dd><!--%plaintext <?INDEX {\tt Indexes} override> -->
Autorise l'usage de directives contrôlant l'indexation des
répertoires (<a href=
"mod_autoindex.html#adddescription">AddDescription</a>, <a href=
"mod_autoindex.html#addicon">AddIcon</a>, <a href=
"mod_autoindex.html#addiconbyencoding">AddIconByEncoding</a>, <a
href="mod_autoindex.html#addiconbytype">AddIconByType</a>, <a
href="mod_autoindex.html#defaulticon">DefaultIcon</a>, <a href=
"mod_dir.html#directoryindex">DirectoryIndex</a>, <a href=
"mod_autoindex.html#fancyindexing">FancyIndexing</a>, <a href=
"mod_autoindex.html#headername">HeaderName</a>, <a href=
"mod_autoindex.html#indexignore">IndexIgnore</a>, <a href=
"mod_autoindex.html#indexoptions">IndexOptions</a>, <a href=
"mod_autoindex.html#readmename">ReadmeName</a>, etc.).</dd>
<dt>Limit</dt>
<dd><!--%plaintext <?INDEX {\tt Limit} override> -->
Autorise l'usage de directives contrôlant les accès
de certains hôtes (allow, deny et order).</dd>
<dt>Options</dt>
<dd><!--%plaintext <?INDEX {\tt Options} override> -->
Autorise l'usage de directives contrôlant certaines
fonctionnalités spécifiques des répertoires
(<a href="#options">Options</a> et <a href=
"mod_include.html#xbithack">XBitHack</a>).</dd>
</dl>
<p><strong>Voir également :</strong> <a href=
"#accessfilename">AccessFileName</a></p>
<hr>
<h2><a name="authname">Directive AuthName</a></h2>
<!--%plaintext <?INDEX {\tt AuthName} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> AuthName <em>domaine-autorisé</em><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> répertoire, .htaccess<br>
<a href="directive-dict.html#Override" rel=
"Help"><strong>Surcharge :</strong></a> AuthConfig<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>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. <samp>AuthName</samp> 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 <a href="#authtype">AuthType</a> et <a href=
"#require">require</a>, et de directives telles que <a href=
"mod_auth.html#authuserfile">AuthUserFile</a> et <a href=
"mod_auth.html#authgroupfile">AuthGroupFile</a>.</p>
<hr>
<h2><a name="authtype">Directive AuthType</a></h2>
<!--%plaintext <?INDEX {\tt AuthType} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> AuthType <em>type</em><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> répertoire, .htaccess<br>
<a href="directive-dict.html#Override" rel=
"Help"><strong>Surcharge :</strong></a> AuthConfig<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>Cette directive selectionne le type d'authentification pour un
répertoire. Seul les types <code>Basic</code> et
<code>Digest</code> sont actuellement implémentés.
<!--%plaintext <?INDEX {\tt Basic} authentication scheme> -->
Pour fonctionner correctement, elle devra être
accompagnée des directives <a href=
"#authname">AuthName</a> et <a href="#require">require</a>, et de
directives telles que <a href=
"mod_auth.html#authuserfile">AuthUserFile</a> et <a href=
"mod_auth.html#authgroupfile">AuthGroupFile</a>.</p>
<hr>
<h2><a name="bindaddress">Directive BindAddress</a></h2>
<!--%plaintext <?INDEX {\tt BindAddress} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> BindAddress *|<em>addresse IP</em>|<em>nom de
domaine</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>BindAddress
*</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>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 <em>adresse IP</em>
spécifique ou d'un <em>nom de domaine</em> Internet.</p>
<p>Une et une seule directive <tt>BindAddress</tt> peut
être utilisée. Pour contrôler plus finement
quels ports et adresses Apache écoute, utilisez la
directive <a href="#listen">Listen</a> au lieu de
<tt>BindAddress</tt>.</p>
<p><tt>BindAddress</tt> peut être utilisée comme
alternative à l'implantation d'<a href=
"../vhosts/">hôtes virtuels</a> utilisant des serveurs
multiples indépendants, soit au lieu d'utiliser les
sections <a href="#virtualhost"><VirtualHost></a>.</p>
<p><strong>Voir aussi:</strong> <a href=
"../dns-caveats.html">Apache et DNS</a><br>
<strong>Voir aussi:</strong> <a href="../bind.html">Configurer
les ports et adresses utilisés par Apache</a></p>
<hr>
<h2><a name="bs2000account">BS2000Account directive</a></h2>
<!--%plaintext <?INDEX {\tt BS2000Account} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> BS2000Account <em>account</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <em>none</em><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> BS2000Account
n'est valable que pour les machines BS2000, à partir de la
version 1.3 d'Apache.
<p>La directive <code>BS2000Account</code> 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 <a href="#user">User</a> ). 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 <samp>SYSROOT</samp>.<br>
Seulement une directive <code>BS2000Account</code> peut
être utilisée.</p>
<p><strong>Voir également:</strong> <a href=
"../ebcdic.html">Portage EBCDIC d'Apache</a></p>
<hr>
<h2><a name="clearmodulelist">Directive ClearModuleList</a></h2>
<!--%plaintext <?INDEX {\tt ClearModuleList} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> ClearModuleList<br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a>
<tt>ClearModuleList</tt> n'est disponible qu'à partir de
la version 1.2 d'Apache
<p>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 <a href=
"#addmodule">AddModule</a>.</p>
<hr>
<h2><a name="contentdigest">Directive ContentDigest</a></h2>
<!--%plaintext <?INDEX {\tt ContentDigest} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> ContentDigest <em>on|off</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>ContentDigest
off</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôtes virtuels,
répertoire, .htaccess<br>
<a href="directive-dict.html#Override" rel=
"Help"><strong>Surcharge :</strong></a> Options<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> expérimental
<p><a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> ContentDigest
n'est disponible qu'à partir de la version 1.1
d'Apache</p>
<p>Cette directive active la génération
d'en-têtes <code>Content-MD5</code> conformes aux RFC1864
et RFC2068.</p>
<p>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é".</p>
<p>L'en-tête <code>Content-MD5</code> 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:</p>
<pre>
Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==
</pre>
<p>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).</p>
<p><code>Content-MD5</code> 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.</p>
<hr>
<h2><a name="coredumpdirectory">Directive
CoreDumpDirectory</a></h2>
<!--%plaintext <?INDEX {\tt CoreDumpDirectory} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> CoreDumpDirectory
<em>nomrépertoire</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> même
répertoire que ServerRoot<br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>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 <a href=
"#serverroot">ServerRoot</a>, 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 souhaîtez 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.</p>
<hr>
<h2><a name="defaulttype">Directive DefaultType</a></h2>
<!--%plaintext <?INDEX {\tt DefaultType} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> DefaultType <em>mime-type</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>DefaultType
text/html</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôtes virtuels,
répertoire, .htaccess<br>
<a href="directive-dict.html#Override" rel=
"Help"><strong>Surcharge :</strong></a> FileInfo<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>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.</p>
<p>Le serveur doit informer le client du type de contenu
(Content-type) du document. Dans le cas d'un type inconnu, il
utilisera le <tt>DefaultType</tt>. Par exemple :</p>
<blockquote><code>DefaultType image/gif</code></blockquote>
<p>sera approprié dans un répertoire contenant une
majorité d'images gif dont certaines ne présentent
pas explicitement l'extension .gif.</p>
<hr>
<h2><a name="directory">Directive <Directory></a></h2>
<!--%plaintext <?INDEX {\tt Directory} section directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> <Directory <em>nomrépertoire</em>>
... </Directory> <br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôtes virtuels<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p><tt><Directory></tt> et <tt></Directory></tt> 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.
<em>nomrépertoire</em> 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:</p>
<pre>
<Directory /usr/local/httpd/htdocs>
Options Indexes FollowSymLinks
</Directory>
</pre>
<p><strong>A partir d'Apache 1.2 :</strong> peuvent être
utilisées les "expressions régulières",
lesquelles devront être précédées du
caractère <code>~</code>. Par exemple :</p>
<pre>
<Directory ~"^/www/.*/[0-9]{3}">
</pre>
correspondrait à des répertoires dans /www/ dont le
nom serait constitué de trois digits.
<p>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 <a href="#accessfilename">.htaccess</a>.
Par exemple, avec l'écriture</p>
<blockquote><code><Directory /> AllowOverride None
</Directory> <Directory /home/*> AllowOverride
FileInfo </Directory></code></blockquote>
<p>pour le contrôle d'accès au document
<code>/home/web/dir/doc.html</code> les étapes
d'évaluation sont les suivantes :</p>
<ul>
<li>Applique la directive <code>AllowOverride None</code>
(désactivant les fichiers <code>.htaccess</code>).</li>
<li>Appliquela directive <code>AllowOverride FileInfo</code>
(pour le répertoire <code>/home/web</code>).</li>
<li>Applique toutes les directives <tt>FileInfo</tt> de
<code>/home/web/.htaccess</code></li>
</ul>
<p>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</p>
<blockquote><code><Directory ~ abc$> ... directives ici ...
</Directory></code></blockquote>
<p>Supposez que le nom de fichier demandé soit
<code>/home/abc/public_html/abc/index.html</code>. Le serveur
considère chacune des sections <code>/</code>,
<code>/home</code>, <code>/home/abc</code>,
<code>/home/abc/public_html</code>, et
<code>/home/abc/public_html/abc</code> dans cet ordre. Sous
Apache 1.2, lorsque <code>/home/abc</code> 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" <tt><Directory>s</tt> et
celles des fichiers <code>.htaccess</code> n'ont pas
été appliquées. A ce moment seulement
l'expression régulière reconnaîtra
<code>/home/abc/public_html/abc</code> et les directives seront
appliquées.</p>
<p><strong>Notez que l'accès par défaut d'Apache
pour les sections <tt><Directory></tt> est <code>Allow from
All</code>. 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</strong></p>
<pre>
<Directory />
Order Deny,Allow
Deny from All
</Directory>
</pre>
<p><strong>puis désactiver sélectivement la
protection pour les répertoires devant rester accessibles.
Voir la page <a href="../misc/security_tips.html">Trucs sur la
sécurité</a> pour plus de
détails.</strong></p>
<p>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
<a href="#limit"><Limit></a> ou <a href=
"#limitexcept"><LimitExcept></a>.</p>
<p><strong>Voir aussi</strong> : <a href=
"../sections.html">Comment fonctionnent les sections concernant
les répertoires, chemins et fichiers</a> pour une
explication plus précise concernant la manière dont
ces sections sont combinées lorsqu'une requête est
traitée.</p>
<hr>
<h2><a name="directorymatch">Directive
<DirectoryMatch></a></h2>
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> <DirectoryMatch <em>regex</em>> ...
</DirectoryMatch><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôtes virtuels<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> Core<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> Disponible
à partir de la version 1.3 d'Apache
<p><tt><DirectoryMatch></tt> et
<tt></DirectoryMatch></tt> 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 <a href=
"#directory"><Directory></a>. Cependant, elle n'accepte
comme argument qu'une expression régulière. Par
exemple :</p>
<blockquote><code><DirectoryMatch
"^/www/.*/[0-9]{3}"></code></blockquote>
<p>correspondrait aux répertoires de /www/ dont le nom
consiste en trois chiffres.</p>
<p><strong>Voir aussi :</strong> <a href=
"#directory"><Directory></a> pour une description de la
manière dont les définitions par expression
régulière sont combinées aux sections
<tt><Directory></tt> "normales".<br>
<strong>Voir aussi</strong> : <a href="../sections.html">Comment
fonctionnent les sections concernant les répertoires,
chemins et fichiers</a> pour une explication plus précise
concernant la manière dont ces sections sont
combinées lorsqu'une requête est traitée</p>
<hr>
<h2><a name="documentroot">Directive DocumentRoot</a></h2>
<!--%plaintext <?INDEX {\tt DocumentRoot} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> DocumentRoot <em>directory-filename</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>DocumentRoot
/usr/local/apache/htdocs</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôtes virtuels<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>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 :</p>
<blockquote><code>DocumentRoot /usr/web</code></blockquote>
<p>Un accès à
<code>http://www.my.host.com/index.html</code> se réferre
au document <code>/usr/web/index.html</code>.</p>
<p>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.</p>
<hr>
<h2><a name="ebcdicconvert">EBCDICConvert</a></h2>
<!--%plaintext <?INDEX {\tt EBCDICConvert} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> EBCDICConvert On|Off[=<em>direction</em>]
<em>extension</em> [<em>extension</em>] ...<br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôte virtuel,
répertoire, .htaccess<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Override" rel=
"Help"><strong>Surcharge :</strong></a> FileInfo<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> la conversion
EBCDIC est disponible à partir de la version 1.3.19
d'Apache sur les plate-formes basées sur EBCDIC.
<p>La directive EBCDICConvert associe une extension de fichier
à une possible conversion (<samp>On</samp> ou
<samp>Off</samp>). Les extensions de fichiers peuvent commencer
ou non par un point.</p>
<p>Si le format optionnel <samp>On=<i>direction</i></samp> (or
<samp>Off=<i>direction</i></samp>) est employé, où
<i>direction</i> est choisi parmi <samp>In</samp>,
<samp>Out</samp> ou <samp>InOut</samp>, alors la directive ne
s'applique seulement que dans une direction de transfert
donnée (<samp>In</samp> : contenu reçu par une
requête PUT ou POST , <samp>Out</samp> : contenu
renvoyé à une requete GET ou POST, et
<samp>InOut</samp> : conversion dans les deux directions).<br>
Sinon, <samp>InOut</samp> (conversion dans les deux directions)
est défini.</p>
<p>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).</p>
<p><strong>Exemple</strong>:<br>
Avec la configuration suivante, les fichiers <samp>*.html</samp>
contiennent du texte HTML au format EBCDIC, tandis que les
fichiers <samp>*.ahtml</samp> contiennent du texte HTML au format
ASCII :</p>
<pre>
# *.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
</pre>
<br>
<br>
<p><strong>Voir également</strong>: <a href=
"#ebcdicconvertbytype">EBCDICConvertByType</a> et <a href=
"../ebcdic.html#ebcdic">Aperçu des fonctions de conversion
EBCDIC</a></p>
<hr>
<h2><a name="ebcdicconvertbytype">EBCDICConvertByType</a></h2>
<!--%plaintext <?INDEX {\tt EBCDICConvertByType} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> EBCDICConvertByType On|Off[=<em>direction</em>]
<em>mimetype</em> [<em>mimetype</em>] ...<br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôte virtuel,
répertoire, .htaccess<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Override" rel=
"Help"><strong>Surcharge :</strong></a> FileInfo<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> la conversion
EBCDIC est disponible à partir de la version 1.3.19
d'Apache sur les plate-formes basées sur EBCDIC.
<p>La directive EBCDICConvertByType associe un type MIME (pouvant
contenir une *) à une éventuelle conversion
(<samp>On</samp> ou <samp>Off</samp>).</p>
<p>Si le format optionnel <samp>On=<i>direction</i></samp> (or
<samp>Off=<i>direction</i></samp>) est employé, où
<i>direction</i> est choisi parmi <samp>In</samp>,
<samp>Out</samp> ou <samp>InOut</samp>, alors la directive ne
s'applique seulement que dans une direction de transfert
donnée (<samp>In</samp> : contenu reçu par une
requête PUT ou POST , <samp>Out</samp> : contenu
renvoyé à une requete GET ou POST, et
<samp>InOut</samp> : conversion dans les deux directions).<br>
Sinon, <samp>InOut</samp> (conversion dans les deux directions)
est défini.</p>
<p><strong>Par exemple</strong>:<br>
Une configuration standard pratique devrait au moins contenir ces
directives :</p>
<pre>
# 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 */*
</pre>
Si vous servez seulement que des documents ASCII, par exemple
provenant d'un montage NFS d'un serveur Unix, utilisez :
<pre>
# Tous les documents sont déjà en ASCII:
EBCDICConvertByType Off */*
</pre>
<p><strong>Voir également</strong>: <a href=
"#ebcdicconvert">EBCDICConvert</a> et <a href=
"../ebcdic.html#ebcdic">Aperçu des fonctions de conversion
EBCDIC</a></p>
<hr>
<h2><a name="ebcdickludge">EBCDICKludge</a></h2>
<!--%plaintext <?INDEX {\tt EBCDICKludge} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> EBCDICKludge On|Off<br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Default:</strong></a> <code>EBCDICKludge
Off</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôte virtuel,
répertoire, .htaccess<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Override" rel=
"Help"><strong>Surcharge :</strong></a> FileInfo<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> 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.<br>
<p>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
"<samp>text/<b>x-ascii-</b><i>sous-type</i></samp>", et ne sera
donc pas converti. A la place, le préfixe
"<samp><b>x-ascii-</b></samp>" était supprimé du
type, obtenant ainsi le type MIME
"<samp>text/<i>sous-type</i></samp>" comme type du document
retourné.</p>
<p>Si la directive EBCDICKludge est mise à
<samp>On</samp>, et si aucune des extensions de fichiers ne
correspondent aux directives <a href=
"#ebcdicconvert">EBCDICConvert</a> définis dans le
contexte , alors le serveur teste avec le type MIME de format
<samp><i>type/</i><b>x-ascii-</b><i>sous-type</i></samp>. Si le
document a un tel type alors la chaîne
"<samp><b>x-ascii-</b></samp>" est supprimée et la
conversion est mise à <samp>Off</samp>. 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.<br>
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 <a
href="#ebcdicconvertbytype">EBCDICConvertByType</a> 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</p>
<p><strong>Voir également</strong> : <a href=
"#ebcdicconvert">EBCDICConvert</a>, <a href=
"#ebcdicconvertbytype">EBCDICConvertByType</a> and <a href=
"../ebcdic.html#ebcdic">Aperçu des fonctions de conversion
EBCDIC</a></p>
<hr>
<h2><a name="errordocument">Directive ErrorDocument</a></h2>
<!--%plaintext <?INDEX {\tt ErrorDocument} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> ErrorDocument <em>code d'erreur document</em><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôtes virtuels,
répertoire, .htaccess<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Override" rel=
"Help"><strong>Surcharge :</strong></a> FileInfo<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> Les contextes
répertoire et .htaccess ne sont utilisables qu'à
partir de la version 1.1 d'Apache.
<p>Dans l'éventualité d'un problème ou d'une
erreur, Apache peut exécuter l'une des quatre actions
suivantes :</p>
<ol>
<li>sortie d'un message d'erreur simple standard</li>
<li>sortie d'un message personnalisé</li>
<li>redirection vers une URL locale pour traiter le
problème (ou l'erreur)</li>
<li>redirection vers une URL externe pour traiter le
problème (ou l'erreur)</li>
</ol>
<p>La première option est celle par défaut, les
options 2 à 4 seront obtenues en utilisant la directive
<tt>ErrorDocument</tt>, suivi du code HTTP d'erreur et du message
textuel d'erreur, ou une URL.</p>
<p><em>Messages</em> dans ce contexte, commence par un guillemet
simple (<code>"</code>), qui ne fait pas partie du message
lui-même. Apache ajoutera souvent des informations
complémentaires explicitant le problème (ou
l'erreur).</p>
<p>L'URL peut débuter par un slash (/) pour des URL
locales, ou être complètement qualifiées.
Exemples:</p>
<blockquote><code>ErrorDocument 500
http://foo.example.com/cgi-bin/tester<br>
ErrorDocument 404 /cgi-bin/bad_urls.pl<br>
ErrorDocument 401 /subscription_info.html<br>
ErrorDocument 403 "Sorry can't allow you access
today</code></blockquote>
<p>Notez que lorsque vous spécifiez un
<tt>ErrorDocument</tt> 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 <code>ErrorDocument 401</code> 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.</p>
<p><strong>Voir aussi:</strong> <a href=
"../custom-error.html">documentation sur les réponses
personnalisées.</a></p>
<hr>
<h2><a name="errorlog">Directive ErrorLog</a></h2>
<!--%plaintext <?INDEX {\tt ErrorLog} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> ErrorLog <em>nomfichier</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>ErrorLog
logs/error_log</code> (Unix)<br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>ErrorLog
logs/error.log</code> (Windows et OS/2)<br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôtes virtuels<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>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
à <a href="#serverroot">ServerRoot</a>. Exemple:</p>
<blockquote><code>ErrorLog /dev/null</code></blockquote>
<p>Cette expression a pour effet de désactiver la trace
d'erreurs.</p>
Si le fichier commence par une barre verticale (|), il est
censé être une commande à exécuter
pour ttraiter le message d'erreur.<br>
<br>
<p><strong>Apache 1.3 et ultérieur:</strong> en utilisant
<code>syslog</code> à 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
<code>local7</code>, mais vous pouvez remplacer ceci en utilisant
la syntaxe <code>syslog:</code><em>service</em> où
<em>service</em> peut être un des noms documenté
dans syslog(1).</p>
<p><strong>Sécurité :</strong> Voir la page <a
href="../misc/security_tips.html">note sur la securité</a>
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.</p>
<hr>
<h2><a name="files">Directive <Files></a></h2>
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> <Files <em>nomfichier</em>> ...
</Files><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôtes virtuels,
.htaccess<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> Disponible
à partir de la version 1.2 d'Apache.
<p>La directive <tt><Files></tt> permet une gestion de
contrôle d'accès fichier par fichier. Elle est
comparable aux directives <a href=
"#directory"><Directory></a> et <a href=
"#location"><Location></a>. Elle doit s'apparier à
une directive <tt></Files></tt>. Les directives applicables
au fichier indiqué sont encapsulées entre ces deux
balises. Les sections <tt><Files></tt> sont traitées
dans l'ordre où elles apparaissent dans le fichier de
configuration, une fois traitées les sections
<tt><Directory></tt> et les fichiers .htaccess, mais avant
les sections <tt><Location></tt>.</p>
<p>L'argument <em>filename</em> 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
<code>~</code>. Par exemple :</p>
<pre>
<Files ~"\.(gif|jpe?g|png)$">
</pre>
<p>correspondrait à la majorité des fichiers
graphiques utilisés sur Internet. A partir de la version
1.3 d'Apache, l'usage de la directive <a href=
"#filesmatch"><FilesMatch></a> est cependant
préférable.</p>
<p>Notez que, contrairement aux sections <a href=
"#directory"><Directory></a> et <a href=
"#location"><Location></a>, les sections
<tt><Files></tt> peuvent apparaître dans des fichiers
<code>.htaccess</code>. 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 <code>.htaccess</code>, si <em>nomfichier</em> ne
commence pas par un slash (/), le répertoire courant
contenant ledit fichier <code>.htaccess</code> y sera
préfixé automatiquement.</p>
<p><strong>Voir aussi :</strong> <a href=
"../sections.html">Comment fonctionnent les sections concernant
les répertoires, chemins et fichiers</a> pour une
explication plus précise concernant la manière dont
ces sections sont combinées lorsqu'une requête est
traitée</p>
<hr>
<h2><a name="filesmatch">Directive <FilesMatch></a></h2>
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> <FilesMatch <em>regex</em>> ...
</Files><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôtes virtuels,
.htaccess<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> Disponible
à partir de la version 1.3 d'Apache.
<p>La directive <tt><FilesMatch></tt> permet un
contrôle d'accès fichier par fichier, tout comme la
directive <a href="#files"><Files></a>. Cependant, elle
n'accepte qu'un argument sous forme d'expression
régulière. Par exemple :</p>
<blockquote><code><FilesMatch
"\.(gif|jpe?g|png)$"></code></blockquote>
<p>qui correspondrait à la plupart des fichiers graphiques
utilisés sur Internet.</p>
<p><strong>Voir aussi :</strong> <a href=
"../sections.html">Comment fonctionnent les sections concernant
les répertoires, chemins et fichiers</a> pour une
explication plus précise concernant la manière dont
ces sections sont combinées lorsqu'une requête est
traitée</p>
<hr>
<h2><a name="group">Directive Group</a></h2>
<!--%plaintext <?INDEX {\tt Group} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> Group <em>groupeUnix</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>Group
#-1</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôte virtuel<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>La directive <tt>Group</tt> 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". <em>groupeUnix</em> est à choisir parmi :</p>
<dl>
<dt>un nom de groupe</dt>
<dd>se réfère à un groupe unix par son
nom.</dd>
<dt># suivi d'unnuméro de groupe.</dt>
<dd>se réfère à un groupe par son
indice.</dd>
</dl>
<p>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 <code>nobody</code>, mais ceci n'est pas toujours
possible ou souhaîtable.</p>
<p><strong>Note :</strong> 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.</p>
<p><strong>Note spéciale :</strong> L'utilisation de cette
directive dans un contexte <tt><VirtualHost></tt>
nécessite un <a href="../suexec.html">suEXEC wrapper</a>
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.</p>
<p><strong>Sécurité :</strong> Voir <a href=
"#user">Utilisateur</a> pour une discussion plus
détaillée sur les aspects utilisateurs.</p>
<hr>
<h2><a name="hostnamelookups">Directive HostNameLookups</a></h2>
<!--%plaintext <?INDEX {\tt HostNameLookups} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> HostNameLookups <em>on | off | double</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>HostNameLookups
off</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôte virtuel,
répertoire, .htaccess<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a>
<code>double</code> n'est disponible qu'à partir de la
version 1.3 d'Apache.<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> La valeur par
défaut était <code>on</code> pour toute version
antérieure à la version 1.3 d'Apache.
<p>Cette directive autorise la résolution DNS pour la
trace d'accès (et pour les passer aux CGI/SSI en
<code>REMOTE_HOST</code>). La valeur <code>double</code> 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
<code>PARANOID</code>.)</p>
<p>Indépendamment du mode choisi, lorsque <a href=
"mod_access.html">mod_access</a> 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
<samp>HostnameLookups double</samp> est activée. Par
exemple, si l'option est simplement <samp>HostnameLookups
on</samp> 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
<code>REMOTE_HOST</code>.</p>
<p>Par défaut, l'état choisi était
<code>on</code> dans les versions d'apache antérieures
à la version 1.3. Elle est aujourd'hui à
<code>off</code> 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 à <code>off</code>, dans
la mesure où une recherche DNS peut consommer un temps non
négligeable. L'utilitaire <code>logresolve</code>, fourni
dans le répertoire <i>/support</i>, peut être
utilisé pour résoudre des noms d'hôtes
à partir des adresses IP tracées en mode
"offline".</p>
<hr>
<h2><a name="identitycheck">Directive IdentityCheck</a></h2>
<!--%plaintext <?INDEX {\tt IdentityCheck} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> IdentityCheck <em>booléen</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>IdentityCheck
off</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôte virtuel,
répertoire, .htaccess<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>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 <code>access
log</code>. <em>booléen</em> vaut soit <code>on</code> ou
<code>off</code>.</p>
<p>Cette information n'est absolument pas certifiée et ne
peut être considérée que pour une analyse
sommaire.</p>
<p>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.</p>
<hr>
<h2><a name="ifdefine"><IfDefine> directive</a></h2>
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> <IfDefine [!]<em>nom-paramètre</em>>
<em>...</em> </IfDefine><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> aucun<br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> tous<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a>
<IfDefine> est disponible à partir de la version
1.3.1
<p>La section <IfDefine <em>test</em>>...</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 <em>test</em>
est vraie. Si <em>test</em> est faux, tout ce qui se trouve entre
le marqueur de début et celui de fin est
ignoré.</p>
<p>Le <em>test</em> de la section <IfDefine> peut exister
sous deux formes :</p>
<ul>
<li><em>nom-paramètre</em></li>
<li><code>!</code><em>nom-paramètre</em></li>
</ul>
<p>Dans le premier cas, les directives entre les marqueurs de
début et de fin ne sont traité que si le
paramètre nommé <em>nom-paramètre</em> 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é <em>nom-paramètre</em>
n'est <strong>pas</strong> défini.</p>
<p>L'argument <em>nom-paramètre</em> est une
définition qui peut être donnée en ligne de
commande d'httpd en utilisant l'option
<code>-D</code><em>nom-paramètre</em>, au lancement du
serveur.</p>
<p>Les sections <IfDefine> peuvent s'imbriquer, ce qui
permet de réaliser des test sur plusieurs
paramètres. Par exemple :</p>
<pre>
$ httpd -DReverseProxy ...
# httpd.conf
<IfDefine ReverseProxy>
LoadModule rewrite_module libexec/mod_rewrite.so
LoadModule proxy_module libexec/libproxy.so
</IfDefine>
</pre>
<hr>
<h2><a name="ifmodule">Directive <IfModule></a></h2>
<b>Syntaxe :</b> <IfModule [!]<i>nomModule</i>> <i>...</i>
</IfModule><br>
<b>Défaut :</b> aucun<br>
<b>Contexte :</b> tous<br>
<b>Statut :</b> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> IfModule n'est
disponible qu'à partir de la version 1.2 d'Apache.
<p>La section <tt><IfModule
<i>test</i>></tt>...</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 <i>test</i> est
vérifié. Si <i>test</i> vaut faux, toute directive
inclue entre la balise de début et celle de fin sont
ignorées.</p>
<p>Le <em>test</em> d'une section <tt><IfModule></tt> peut
prendre l'une des formes suivantes :</p>
<ul>
<li><i>nomModule</i></li>
<li>!<i>nomModule</i></li>
</ul>
<p>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 <em>nomModule</em> est compilé dans
votre version d'Apache. La seconde forme inverse le sens du test,
et ne traite les directives que si le module <em>nomModule</em>
n'est <b>pas</b> compilé.</p>
<p>L'argument <em>nomModule</em> spécifie un nom de module
par son nom de fichier source, tel qu'appelé par la
compilation. Par exemple, <code>mod_rewrite.c</code>.</p>
<p>Les sections <tt><IfModule></tt> peuvent être
imbriquées, ce qui peut être utile pour
implémenter simplement des tests multi-modules.</p>
<hr>
<h2><a name="include">Directive Include</a></h2>
<strong>Syntaxe :</strong> Include <em>nomfichier</em><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> Include n'est
disponible qu'à partir de la version 1.3 d'Apache.
<p>Cette directive permet l'inclusion d'autres fichiers de
configuration à partir d'autres fichiers de configuration
serveur.</p>
<p>A partir de la version Apache 1.3.13, si <code>Include</code>
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.</p>
<hr>
<h2><a name="keepalive">Directive KeepAlive</a></h2>
<strong>Syntaxe : (Apache 1.1)</strong> KeepAlive
<em>requêtesMax</em><br>
<strong>Défaut : (Apache 1.1)</strong> <code>KeepAlive
5</code><br>
<strong>Syntaxe : (Apache 1.2)</strong> KeepAlive
<em>on/off</em><br>
<strong>Défaut : (Apache 1.2)</strong> <code>KeepAlive
On</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> KeepAlive est
disponible à partir de la version 1.1 d'Apache.
<p>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 <code>KeepAlive On</code>.</p>
<p>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.</p>
<p><strong>Sous Apache 1.1</strong>: Mettre
<em>requêtesMax</em> 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 <code>0</code>
pour désactiver ce support. A partir de la version 1.2,
ceci est contrôlé par la directive
MaxKeepAliveRequests</p>
Voir aussi la directive <a href=
"#maxkeepaliverequests">MaxKeepAliveRequests</a>.<br>
<br>
<hr>
<h2><a name="keepalivetimeout">Directive
KeepAliveTimeout</a></h2>
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> KeepAliveTimeout <em>secondes</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a>
<code>KeepAliveTimeout 15</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a>
<tt>KeepAliveTimeout</tt> est disponible à partir de la
version 1.1 d'Apache.
<p>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 <a href=
"#timeout">Timeout</a> s'applique.</p>
<p>Mettre <code>KeepAliveTimeout</code> à 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.</p>
<hr>
<h2><a name="limit">Directive <Limit></a></h2>
<!--%plaintext <?INDEX {\tt Limit} section directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> <Limit <em>méthode méthode</em>
... > ... </Limit><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> tous<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>Les contrôles d'accès sont normalement actives
pour <strong>toutes</strong> les méthodes d'accès,
et ceci est le comportement normal. <strong>En
général, les directives de contrôle
d'accès ne doivent être placées à
l'intérieur d'une section
<code><limit></code>.</strong></p>
<p>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>
<strong>sont sans effets</strong>. 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 :</p>
<blockquote><code><Limit POST PUT DELETE><br>
Require valid-user<br>
</Limit></code></blockquote>
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. <strong>Le nom de
la méthode est sensible à la casse.</strong> Si GET
est employé, il restreindra également les
requêtes HEAD.
<hr>
<h2><a name="limitexcept">Directive <LimitExcept></a></h2>
<!--%plaintext <?INDEX {\tt LimitExcept} section directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> <LimitExcept <em>méthode</em>
[<em>méthode</em>] ... > ... </LimitExcept><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> tous<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> disponible
à partir de la version 1.3.5 d'Apache.
<p><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
<strong>pas</strong> en arguments Cette directive est
l'oppsée de <a href="#limit"><Limit></a> et peut
être employée pour contrôler les
méthodes non reconnues ou non standard. Voir la
documentation de <a href="#limit"><Limit></a> pour plus de
détails.</p>
<hr>
<h2><a name="limitrequestbody">Directive
LimitRequestBody</a></h2>
<!--%plaintext <?INDEX {\tt LimitRequestBody} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> LimitRequestBody <em>octets</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a>
<code>LimitRequestBody 0</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôte virtuel,
répertoire .htaccess<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a>
LimitRequestBody est disponible à partir de la version
1.3.2.
<p>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
<code>DEFAULT_LIMIT_REQUEST_BODY</code> (0 dans les
distributions).</p>
<p>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.</p>
<p>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.</p>
<hr>
<h2><a name="limitrequestfields">Directive
LimitRequestFields</a></h2>
<!--%plaintext <?INDEX {\tt LimitRequestFields} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> LimitRequestFields <em>number</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a>
<code>LimitRequestFields 100</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a>
LimitRequestFields est disponible à partir de la version
1.3.2.
<p><em>Number</em> est un entier allant de 0 (signifiant sans
limite) à 32767. La valeur par défaut est
définie à la compilation par la constante
<code>DEFAULT_LIMIT_REQUEST_FIELDS</code> (100 dans la
distribution).</p>
<p>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.</p>
<p>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.</p>
<hr>
<h2><a name="limitrequestfieldsize">Directive
LimitRequestFieldsize</a></h2>
<!--%plaintext <?INDEX {\tt LimitRequestFieldsize} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> LimitRequestFieldsize <em>octets</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a>
<code>LimitRequestFieldsize 8190</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a>
LimitRequestFieldsize est disponible à partir de la
version 1.3.2.
<p>Cette directive indique la taille maximale de l'en-tête
d'une requête HTTP et peut aller de 0 <em>octets</em>
à la valeur définit à la compilation par la
constante <code>DEFAULT_LIMIT_REQUEST_FIELDSIZE</code> (8190 dans
la distribution standard).</p>
<p>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.</p>
<p>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.</p>
<hr>
<h2><a name="limitrequestline">Directive
LimitRequestLine</a></h2>
<!--%plaintext <?INDEX {\tt LimitRequestLine} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> LimitRequestLine <em>octets</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a>
<code>LimitRequestLine 8190</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a>
LimitRequestLine est disponible à partir de la version
1.3.2.
<p>Cette directive indique la taille maximale d'une requête
HTTP et peut aller de 0 <em>octets</em> à la valeur
définit à la compilation par la constante
<code>DEFAULT_LIMIT_REQUEST_LINE</code> (8190 dans la
distribution standard).</p>
<p>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.</p>
<p>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.</p>
<hr>
<h2><a name="listen">Directive Listen</a></h2>
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> Listen
[<em>adresseIp</em>:]<em>numéroPort</em><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> Listen est
disponible à partir de la version 1.1 d'Apache.
<p>La directive <tt>Listen</tt> 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 <a href="#port">Port</a>.</p>
<tt>Listen</tt> peut être utilisée à la place
de <tt><a href="#bindaddress">BindAddress</a></tt> et
<tt>Port</tt>. 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 <tt>Port</tt>. 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.<br>
<br>
<p>Notez que vous avez toujours besoin de la directive
<tt>Port</tt> qui permettent à Apache de
générer les URL de retour vers votre serveur.</p>
<p>Plusieurs directives <tt>Listen</tt> 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.</p>
<p>Par exemple, pour autoriser le serveur à accepter des
connexions sur les ports 80 et 8000, écrire :</p>
<blockquote>
<pre>
<code>Listen 80
Listen 8000
</code>
</pre>
</blockquote>
<p>Pour autoriser un serveur à accepter des connexions sur
deux "sockets" qualifiés, écrire :</p>
<pre>
Listen 192.170.2.1:80
Listen 192.170.2.5:8000
</pre>
<p><strong>Voir aussi:</strong> <a href=
"../dns-caveats.html">Apache et DNS</a><br>
<strong>Voir aussi:</strong> <a href="../bind.html">Configurer
les ports et adresses utilisée par Apache</a><br>
<strong>Voir aussi :</strong> <a href=
"http://www.apache.org/info/known_bugs.html#listenbug">Bogues
connus</a></p>
<hr>
<h2><a name="listenbacklog">Directive ListenBacklog</a></h2>
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> ListenBacklog <em>backlog</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>ListenBacklog
511</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a>
<tt>ListenBacklog</tt> n'est disponible qu'à partir de la
version 1.2.0 d'Apache.
<p>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
<code>listen(2)</code>.</p>
<p>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).</p>
<hr>
<h2><a name="location">Directive <Location></a></h2>
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> <Location <em>URL</em>> ...
</Location><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôtes virtuels<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a>
<tt>Location</tt> est disponible à partir des versions 1.1
d'Apache.
<p>La directive <tt><Location></tt> permet d'instaurer un
contrôle d'accès sur une base URL. Elle est
comparable à la directive <a href=
"#directory"><Directory></a>, et doit s'apparier à
une directive <tt></Location></tt>. Les directives
s'appliquant à l'URL précisée seront
à inclure entre ces deux balises. Les sections
<tt><Location></tt> sont traitées dans l'ordre
où elles apparaissent dans le fichier de configuration,
une fois les sections <tt><Directory></tt> et les fichiers
<code>.htaccess</code> traités.</p>
<p>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.</p>
<p>Le <em>préfixe d'URL</em> devra, sauf pour des
requêtes à un proxy, être de la forme
<code>/chemin/</code>, et ne devra pas inclure de mention
<code>http://nomserveur</code>. 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
<code>scheme://nomserveur/serveur</code>, et vous devez inclure
le préfixe.</p>
<p><strong>Apache 1.2 et plus :</strong> Des expression
régulières peuvent être utilisées,
à condition de les faire précéder du
caractère <code>~</code>. Par exemple :</p>
<blockquote><code><Location ~
"/(extra|special)/data"></code></blockquote>
<p>correspondrait à des URL contenant la sous-chaîne
"/extra/data" ou "/special/data". Cependant, sous Apache 1.3,
l'utilisation de la directive <a href=
"#locationmatch"><LocationMatch></a> est
conseillée.</p>
<p>La fonctionnalité <tt>Location</tt> est
particulièrement pratique lorsque combinée à
la directive <a href="mod_mime.html#sethandler">SetHandler</a>.
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 :</p>
<blockquote>
<pre>
<code><Location /status>
SetHandler server-status
order deny,allow
deny from all
allow from .foo.com
</Location>
</code>
</pre>
</blockquote>
<p><strong>Note sur / (barre oblique) pour les version
supérieures à 1.3</strong>: 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
<code>/home///foo</code> est identique à
<code>/home/foo</code>). Dans le monde des URL ceci n'est pas
obligatoirement vrai. La directive
<code><LocationMatch></code> et la version avec expression
régulière de <code><Location></code> demande
de spécifier plusieurs caractères obliques si ceci
est votre intention. Par exemple, <code><LocationMatch
^/abc></code> fonctionnera avec l'URL <code>/abc</code> mais
pas avec l'URL <code>//abc</code>. La directive (sans expression
régulière) <code><Location></code> 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)
<code><Location></code> est utilisée pour des
requêtes sans proxy, il associera implicitement plusieurs
obliques à un seul. Par exemple, si vous spécifiez
<code><Location /abc/def></code> et que la requête
est <code>/abc//def</code> celle ci correspondra.</p>
<p><strong>Voir aussi</strong>: <a href=
"../sections.html">Comment fonctionnent les sections concernant
les répertoires, chemins et fichiers</a> pour une
explication plus précise concernant la manière dont
ces sections sont combinées lorsqu'une requête est
traitée.</p>
<hr>
<h2><a name="locationmatch">Directive
<LocationMatch></a></h2>
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> <LocationMatch <em>regex</em>> ...
</LocationMatch><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôte virtuel<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> Location est
disponible à partir de la version 1.3 d'Apache.
<p>La directive <tt><LocationMatch></tt> permet
l'établissement d'un contrôle d'accès sur une
base URL, d'une façon identique à la directive <a
href="#location"><Location></a>. Cependant, elle n'accepte
qu'une expression régulière comme argument. Par
exemple :</p>
<blockquote><code><LocationMatch
"/(extra|special)/data"></code></blockquote>
représente des URL contenant l'une des sous-chaînes
"/extra/data" ou "/special/data". <br>
<br>
<strong>Voir aussi</strong> : <a href="../sections.html">Comment
fonctionnent les sections concernant les répertoires,
chemins et fichiers</a> pour une explication plus précise
concernant la manière dont ces sections sont
combinées lorsqu'une requête est traitée.
<hr>
<h2><a name="lockfile">Directive LockFile</a></h2>
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> LockFile <em>nomfichier</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>LockFile
logs/accept.lock</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>La directive <tt>LockFile</tt> indique le chemin
d'accès du fichier de verrouillage utilisé
lorsqu'Apache est compilé en mode
<code>USE_FCNTL_SERIALIZED_ACCEPT</code> ou
<code>USE_FLOCK_SERIALIZED_ACCEPT</code>. 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 (<code>logs</code>) 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.</p>
<p><strong>SECURITE :</strong> il vaut mieux éviter de
metttre ce fichier dans un répertoire inscriptible par
tout le monde tel que <code>/var/tmp</code> 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.</p>
<hr>
<h2><a name="loglevel">Directive LogLevel</a></h2>
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> LogLevel <em>niveau</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>LogLevel
error</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôtes virtuels<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> LogLevel est
disponible à partir de la version 1.3.
<p>LogLevel ajuste le niveau de verbosité des messages
inscrits dans les traces d'erreur (voir la directive <a href=
"#errorlog">ErrorLog</a>). Les niveaux possibles sont par ordre
de gravité décroissante :</p>
<table>
<tr>
<th align="LEFT"><strong>Niveau</strong> </th>
<th align="LEFT"><strong>Description</strong> </th>
</tr>
<tr>
<th></th>
<th align="LEFT"><strong>Exemple</strong> </th>
</tr>
<tr>
<td><code>emerg</code> </td>
<td>Urgences - le système est inutilisable.</td>
</tr>
<tr>
<td></td>
<td>"Child cannot open lock file. Exiting"</td>
</tr>
<tr>
<td><code>alert</code> </td>
<td>Une action doit être prise immédiatement.</td>
</tr>
<tr>
<td></td>
<td>"getpwuid: couldn't determine user name from uid"</td>
</tr>
<tr>
<td><code>crit</code> </td>
<td>Conditions critiques.</td>
</tr>
<tr>
<td></td>
<td>"socket: Failed to get a socket, exiting child"</td>
</tr>
<tr>
<td><code>error</code> </td>
<td>Cas d'erreur.</td>
</tr>
<tr>
<td></td>
<td>"Premature end of script headers"</td>
</tr>
<tr>
<td><code>warn</code> </td>
<td>Avertissements.</td>
</tr>
<tr>
<td></td>
<td>"child process 1234 did not exit, sending another
SIGHUP"</td>
</tr>
<tr>
<td><code>notice</code> </td>
<td>Normal mais condition significative.</td>
</tr>
<tr>
<td></td>
<td>"httpd: caught SIGBUS, attempting to dump core in ..."</td>
</tr>
<tr>
<td><code>info</code> </td>
<td>Pour information.</td>
</tr>
<tr>
<td></td>
<td>"Server seems busy, (you may need to increase StartServers,
or Min/MaxSpareServers)..."</td>
</tr>
<tr>
<td><code>debug</code> </td>
<td>Messages de déboguage</td>
</tr>
<tr>
<td></td>
<td>"Opening config file ..."</td>
</tr>
</table>
<p>Quand un niveau est spécifié, les messages des
niveaux de plus haute gravité seront également
rapportés. Par exemple, quand la directive <code>LogLevel
info</code> est définie, les messages de niveau
<code>notice</code> et <code>warn</code> seront aussi
notifiés.</p>
<p>L'utilisation d'un niveau de gravité d'au moins
<code>crit</code> est recommandé.</p>
<hr>
<h2><a name="maxclients">Directive MaxClients</a></h2>
<!--%plaintext <?INDEX {\tt MaxClients} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> MaxClients <em>nombre</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>MaxClients
256</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>La directive <tt>MaxClients</tt> 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.</p>
<p>Les tentatives de connexions au delà de MaxClients sont
normalement mises en attente, jusqu'à une limite
fixée par la directive <a href=
"#listenbacklog">ListenBacklog</a>. Une fois qu'un processus fils
est libre à la fin d'une requête différente,
la connexion en attente est traitée.</p>
<hr>
<h2><a name="maxkeepaliverequests">Directive
MaxKeepAliveRequests</a></h2>
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> MaxKeepAliveRequests <em>nombre</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a>
<code>MaxKeepAliveRequests 100</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> Uniquement
à partir de la version 1.2 d'Apache.
<p>La directive <tt>MaxKeepAliveRequests</tt> limite le nombre de
requêtes permises pour une connexion unique lorsque la
directive <a href="#keepalive">KeepAlive</a> est activée.
Si <em>nombre</em> vaut "<code>0</code>", 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</p>
<hr>
<h2><a name="maxrequestsperchild">Directive
MaxRequestsPerChild</a></h2>
<!--%plaintext <?INDEX {\tt MaxRequestsPerChild} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> MaxRequestsPerChild <em>nombre</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a>
<code>MaxRequestsPerChild 0</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>La directive <tt>MaxRequestsPerChild</tt> indique le nombre
limite de requêtes qu'un processus serveur fils peut
traîter. Après <tt>MaxRequestsPerChild</tt>
requêtes, ce processus fils meurt. Si ce paramètre
est fixé à 0, alors les processus fils ne meurent
jamais.</p>
<p>Le fait de mettre <tt>MaxRequestsPerChild</tt> à une
valeur non nulle a deux conséquences
bénéfiques :</p>
<ul>
<li>cela limite le volume de mémoire qu'un processus peut
consommer (accidentellement) et évite une saturation
mémoire ;</li>
<li>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.</li>
</ul>
<p>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 <a href=
"#threadsperchild">ThreadsPerChild</a>.</p>
<p><strong>NOTE:</strong> pour les requêtes
<em>KeepAlive</em> requests, seule la première
requête est comptée. En réalité, il
change le comportement afin de limiter le nombre de
<em>connexions</em> par fils.</p>
<hr>
<h2><a name="maxspareservers">Directive MaxSpareServers</a></h2>
<!--%plaintext <?INDEX {\tt MaxSpareServers} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> MaxSpareServers <em>nombre</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>MaxSpareServers
10</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>La directive <tt>MaxSpareServers</tt> indique le nombre
maximal de processus fils en <em>attente</em>. Un processus en
attente est un processus qui existe, mais qui ne traite pas de
requête. S'il existe plus de <tt>MaxSpareServers</tt> de
ces processus, alors le père viendra tuer les processus en
supplémentaires.</p>
<p>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.</p>
<p>Cette directive n'a aucun effet quand elle est employée
sur les plates-formes WIndows.</p>
<p>Voir aussi <a href="#minspareservers">MinSpareServers</a> et
<a href="#startservers">StartServers</a>.</p>
<hr>
<h2><a name="minspareservers">Directive MinSpareServers</a></h2>
<!--%plaintext <?INDEX {\tt MinSpareServers} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> MinSpareServers <em>nombre</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>MinSpareServers
5</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>La directive <tt>MinSpareServers</tt> indique le nombre
minimum de processus fils en <em>attente</em> qu'un serveur
pourra conserver. S'il existe moins de <tt>MinSpareServers</tt>
processus serveurs fils en attente, le processus père
recréera des processus fils au rythme de 1 par
seconde.</p>
<p>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.</p>
<p>Cette directive n'a aucun effet quand elle est employée
sur les plates-formes WIndows.</p>
<p>Voir aussi <a href="#maxspareservers">MaxSpareServers</a> et
<a href="#startservers">StartServers</a>.</p>
<hr>
<h2><a name="namevirtualhost">Directive NameVirtualHost</a></h2>
<!--%plaintext <?INDEX {\tt NameVirtualHost} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> NameVirtualHost <em>addr</em>[:<em>port</em>]<br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a>
<tt>NameVirtualHost</tt> n'est disponible qu'à partir de
la version 1.3 d'Apache.
<p>La directive <tt>NameVirtualHost</tt> est nécessaire si
vous souhaitez configurer <a href="../vhosts/index.html">des
hôtes virtuels nommés</a>.</p>
<p>Bien que <em>addr</em> puisse être exprimée comme
un nom d'hôte, il est recommandé d'utiliser une
adresse IP, exemple :</p>
<blockquote><code>NameVirtualHost
111.22.33.44</code></blockquote>
<p>Avec cette directive <tt>NameVirtualHost</tt>, 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).</p>
<p>Note: le "serveur principal" et tous les serveurs "par
défaut" ne seront <strong>jamais</strong> 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).</p>
<p>En option, vous pouvez préciser un numéro de
port sur lequel l'hôte virtuel nommé sera atteint,
par exemple :</p>
<blockquote><code>NameVirtualHost
111.22.33.44:8080</code></blockquote>
A partir de la version 1.3.13, vous pouvez donner comme adresse
<code>*</code> 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 <a href=
"#virtualhost"><VirtualHost></a>. 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.<br>
<br>
<strong>Voir aussi :</strong> <a href="../vhosts/">Hôtes
virtuels sur Apache</a>
<hr>
<h2><a name="options">Directive Options</a></h2>
<!--%plaintext <?INDEX {\tt Options} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> Options <em>[+|-]option [+|-]option ...</em><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôte virtuel,
répertoire, .htaccess<br>
<strong>Surcharge:</strong> Options<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>La directive <tt>Options</tt> contrôle quelles fonctions
du serveur sont disponibles dans un répertoire
particulier.</p>
<p><em>option</em> peut valoir <code>None</code>, auquel cas
aucune fonction supplémentaire n'est disponible, ou une ou
plus des possibilités suivantes :</p>
<dl>
<dt>All</dt>
<dd>toutes options sauf MultiViews.</dd>
<dt>ExecCGI</dt>
<dd><!--%plaintext <?INDEX {\tt ExecCGI} option> -->
L'exécution des scripts CGI est autorisée.</dd>
<dt>FollowSymLinks</dt>
<dd><!--%plaintext <?INDEX {\tt FollowSymLinks} option> -->
Le serveur est autorisé à suivre les liens
symboliques dans ce répertoire.
<p><strong>Note</strong>: même si le serveur suit le lien
symbolique, il <b>ne</b> doit <b>pas</b> changer le chemin
d'accès afin de ne pas entrer en contradiction avec les
sections <tt><Directory></tt>.</p>
</dd>
<dt>Includes</dt>
<dd><!--%plaintext <?INDEX {\tt Includes} option> -->
Les inclusions par Server-Side-Include sont permises.</dd>
<dt>IncludesNOEXEC</dt>
<dd><!--%plaintext <?INDEX {\tt IncludesNOEXEC} option> -->
Les SSI sont autorisés, mais pas la commande #exec ni
<code>#include</code> des scripts CGI.</dd>
<dt>Indexes</dt>
<dd><!--%plaintext <?INDEX {\tt Indexes} option> -->
Si une URL requise pointe sur un répertoire, et aucun
fichier défini par <tt>DirectoryIndex</tt> (ex.
index.html) n'existe dans ce répertoire, alors le serveur
retourne une liste formatée du contenu du
répertoire.</dd>
<dt>MultiViews</dt>
<dd><!--%plaintext <?INDEX {\tt MultiViews} option> -->
<a href="../content-negotiation.html">Un contenu
négocié</a> en <code>MultiViews</code> est
permis.</dd>
<dt>SymLinksIfOwnerMatch</dt>
<dd>
<!--%plaintext <?INDEX {\tt SymLinksIfOwnerMatch} option> -->
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.</dd>
</dl>
<p>Normalement, si plusieurs options <code>Options</code> peuvent
être appliquées à un répertoire, alors
la plus restrictive est appliquée ; les options ne sont
pas combinées. Cependant, si <i>all</i> les options dans
la directive <code>Options</code>
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.</p>
<p>Par exemple, sans symboles + ni - :</p>
<blockquote>
<pre>
<code><Directory /web/docs>
Options Indexes FollowSymLinks
</Directory>
<Directory /web/docs/spec>
Options Includes
</Directory>
</code>
</pre>
</blockquote>
<p>seul <code>Includes</code> sera activé pour le
répertoire <code>/web/docs/spec</code>. Cependant, si la
seconde directive d'<code>Options</code> utilise les symboles +
et - :</p>
<blockquote>
<pre>
<code><Directory /web/docs>
Options Indexes FollowSymLinks
</Directory>
<Directory /web/docs/spec>
Options +Includes -Indexes
</Directory>
</code>
</pre>
</blockquote>
<p>alors les options <code>FollowSymLinks</code> et
<code>Includes</code> sont validées pour le
répertoire <code>/web/docs/spec</code>.</p>
<hr>
<h2><a name="pidfile">Directive PidFile</a></h2>
<!--%plaintext <?INDEX {\tt PidFile} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> PidFile <em>filename</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>PidFile
logs/httpd.pid</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>La directive <tt>PidFile</tt> 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 <a href=
"#serverroot">ServerRoot</a>. Le fichier <tt>PidFile</tt> n'est
utilisé que dans le mode <a href=
"#servertype">standalone</a>.</p>
<p>Il est souvent utile de pouvoir envoyer un signal au serveur,
pour qu'il referme et réouvre ses fichiers <a href=
"#errorlog">ErrorLog</a> et <tt>TransferLog</tt>, 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
<tt>PidFile</tt>.</p>
<p>Le fichier <tt>PidFile</tt> est concerné par les
mêmes problèmes d'emplacement et de <a href=
"../misc/security_tips.html">securité</a> que les fichiers
de trace.</p>
<hr>
<h2><a name="port">Directive Port</a></h2>
<!--%plaintext <?INDEX {\tt Port} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> Port <em>numéro</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>Port
80</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p><em>numéro</em> 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"
<code>/etc/services</code>; le port standard assigné au
protocole http est le port 80.</p>
<p>La directive <tt>Port</tt> a deux comportements, le premier
est nécessaire pour assurer la compatibilité NCSA
(et qui peut préter à confusion dans le contexte
d'Apache).</p>
<ul>
<li>En absence de toute directive <a href="#listen">Listen</a> ou
<a href="#bindaddress">BindAddress</a> spécifiant un
numéro de port, la directive <tt>Port</tt> définit
le port réseau que le serveur écoute. S'il existe
une directive <tt>Listen</tt> ou <tt>BindAddress</tt>
spécifiant un <code>:numéro</code> alors la
directive Port n'a aucun effet quant au socket que le serveur
écoute.</li>
<li>La directive Port définit la variable d'environnement
<code>SERVER_PORT</code> (pour les <a href="mod_cgi.html">CGI</a>
et les <a href="mod_include.html">SSI</a>), 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).</li>
</ul>
<p>Dans aucun cas une définition du <tt>Port</tt> ne
définit à quel port un <a href=
"#virtualhost">VirtualHost</a> répond, la directive
<tt>VirtualHost</tt> elle-même se chargeant de cette
définition.</p>
<p>Le comportement premier de la directive <tt>Port</tt> doit
être considéré comme similaire à celui
de la directive <a href="#servername">ServerName</a>.
<tt>ServerName</tt> et <tt>Port</tt> spécifient
conjointement ce que vous considérez être l'adresse
<em>canonique</em> du serveur.</p>
<p>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
<code>root</code>. 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
<a href="#user">User</a>.</p>
<p>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.</p>
<p><strong>Sécurité :</strong> si vous
démarrez le serveur sous <code>root</code>, assurez vous
que la directive <a href="#user">User</a> ne mentionne pas
<code>root</code>. Si vous traitez des requêtes en
disposant toujours de super privilèges, vous ouvrez votre
système à des attaques majeures.</p>
<hr>
<h2><a name="require">Directive require</a></h2>
<!--%plaintext <?INDEX {\tt require} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> require <em>nomEntite Entite Entite...</em><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> répertoire, .htaccess<br>
<strong>Surcharge:</strong> AuthConfig<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>Cette directive choisi quels utilisateurs autorisés
peuvent accéder à un répertoire. Les
syntaxes valides sont :</p>
<ul>
<li>require user <em>utilisateur utilisateur ...</em>
<p>Seuls les utilisateurs nommés peuvent accéder au
répertoire.</p>
</li>
<li>require group <em>nomGroupe nomGroupe ...</em>
<p>Seuls les utilisateurs des groupes cités peuvent
accéder au répertoire.</p>
</li>
<li>require valid-user
<p>Tout utilisateur reconnu peut accéder au
répertoire (par opposition aux non utilisateurs).</p>
</li>
</ul>
<p>Si <code>require</code> apparaît dans une section <a
href="#limit"><Limit></a>, alors les restrictions ne sont
appliquées qu'aux méthodes http mentionnées.
Autrement, toutes les méthodes http sont restreintes.
Exemple :</p>
<blockquote>
<pre>
<code>AuthType Basic
AuthName unDomaine
AuthUserFile /web/users
AuthGroupFile /web/groups
<Limit GET POST>
require group admin
</Limit>
</code>
</pre>
</blockquote>
<p>Pour fonctionner correctement, la directive Require doit
être accompagné de directives <a href=
"#authname">AuthName</a> et <a href="#authtype">AuthType</a>, et
de directives de type <a href=
"mod_auth.html#authuserfile">AuthUserFile</a> et <a href=
"mod_auth.html#authgroupfile">AuthGroupFile</a> (servant à
définir les utilisateurs et les groupes).</p>
<hr>
<h2><a name="resourceconfig">Directive ResourceConfig</a></h2>
<!--%plaintext <?INDEX {\tt ResourceConfig} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> ResourceConfig <em>nomfichier</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>ResourceConfig
conf/srm.conf</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôte virtuel<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>Le serveur lit dans ce fichier des directives
supplémentaires, après avoir lu le fichier
<code>httpd.conf</code>. <em>nomfichier</em> est
considéré relativement à <a href=
"#serverroot">ServerRoot</a>. Cette fonctionnalité peut
être désactivée par l'écriture :</p>
<blockquote><code>ResourceConfig /dev/null</code></blockquote>
ou sur les serveurs Win32
<blockquote><code>ResourceConfig nul</code></blockquote>
<p>Historiquement, ce fichier contenait essentiellement les
directives autres que celles servant à la configuration du
serveur ou les sections <a href=
"#directory"><Directory></a> ; en fait, il peut contenir
maintenant toute directive admise dans le contexte
<em>configuration serveur</em>.</p>
<p>A partir de la version 1.3.13, si la directive
<code>ResourceConfig</code> 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.</p>
<p>Voir aussi <a href="#accessconfig">AccessConfig</a>.</p>
<hr>
<h2><a name="rlimit">Directive RLimitCPU</a> <a name=
"rlimitcpu"></a></h2>
<!--%plaintext <?INDEX {\tt RLimitCPU} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> RLimitCPU <em># ou 'max'</em> <em>[# ou
'max']</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <em>Non
précisé; utilise le défaut du système
d'exploitation</em><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôte virtuel<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> RLimitCPU
n'est disponible qu'à partir de la version 1.2 d'Apache
<p>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 <em>max</em> 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.</p>
<p>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.</p>
<p>La limite de ressources CPU est exprimée en secondes
par processus.</p>
<p>Voir aussi <a href="#rlimitmem">RLimitMEM</a> ou <a href=
"#rlimitnproc">RLimitNPROC</a>.</p>
<hr>
<h2><a name="rlimitmem">Directive RLimitMEM</a></h2>
<!--%plaintext <?INDEX {\tt RLimitMEM} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> RLimitMEM <em># ou 'max'</em> <em>[# ou
'max']</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <em>Non
précisé ; utilise le défaut du
système d'exploitation</em><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôte virtuel<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> RLimitMEM is
only available in Apache 1.2 and later
<p>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 <em>max</em> 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.</p>
<p>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.</p>
<p>Les ressources mémoire sont exprimées en octets
par processus.</p>
<p>Voir aussi <a href="#rlimitcpu">RLimitCPU</a> ou <a href=
"#rlimitnproc">RLimitNPROC</a>.</p>
<hr>
<h2><a name="rlimitnproc">Directive RLimitNPROC</a></h2>
<!--%plaintext <?INDEX {\tt RLimitNPROC} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> RLimitNPROC <em># ou 'max'</em> <em>[# ou
'max']</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <em>Unset; uses
operating system defaults</em><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôte virtuel<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> RLimitNPROC
n'est disponible qu'à partir de la version 1.2 d'Apache
<p>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 <em>max</em> 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.</p>
<p>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.</p>
<p>Cette limite contrôle le nombre de processus maximum par
utilisateur.</p>
<p><strong>Note :</strong> Si les processus CGI <b>ne</b>
tournent <b>pas</b> 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 <b><em>cannot fork</em></b> dans le fichier
error_log.</p>
<p>Voir aussi <a href="#rlimitmem">RLimitMEM</a> ou <a href=
"#rlimitcpu">RLimitCPU</a>.</p>
<hr>
<h2><a name="satisfy">Directive Satisfy</a></h2>
<!--%plaintext <?INDEX {\tt Satisfy} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> Satisfy <em>'any' ou 'all'</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> Satisfy all<br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> répertoire, .htaccess<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a>
<tt>Satisfy</tt> n'est disponible qu'à partir de la
version 1.2 d'Apache
<p>Politique d'accès si à la fois 'allow' et
'require' sont utilisés. Le paramètre peut valoir
soit <em>'all'</em> soit <em>'any'</em>. Cette directive n'est
utile que si l'accès à une zone particulière
est à la fois restreinte par un username/password
<em>et</em> 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 <em>et</em> 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
<em>ou</em> 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.</p>
<p>Voir aussi <a href="#require">Require</a> et <a href=
"mod_access.html#allow">Allow</a>.</p>
<hr>
<h2><a name="scoreboardfile">Directive ScoreBoardFile</a></h2>
<!--%plaintext <?INDEX {\tt ScoreBoardFile} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> ScoreBoardFile <em>nomfichier</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>ScoreBoardFile
logs/apache_status</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>La directive <tt>ScoreBoardFile</tt> 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.</p>
<p>Si vous devez utiliser un <tt>ScoreBoardFile</tt>, 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 <a href=
"../misc/security_tips.html">securité</a>.</p>
<p><i>A partir d'Apache 1.2 :</i></p>
<p>Les utilisateurs de Linux 1.x doivent pouvoir ajouter
<code>-DHAVE_SHMGET</code> aux <code>EXTRA_CFLAGS</code> dans
leur fichier de <code>Configuration</code>. Ceci devrait
fonctionner sur certaines installations en 1.x, mais pas
forcément sur toutes.</p>
<p>Les utilisateurs de SVR4 devront considérer
l'opportunité d'ajouter <code>-DHAVE_SHMGET</code> aux
<code>EXTRA_CFLAGS</code> dans leur fichier de
<code>Configuration</code>. Il semble que cela fonctionne, mais
nous n'avons pu le tester pour la version 1.2. (avant la version
1.3b4, <code>HAVE_SHMGET</code> devait suffire.)</p>
<br>
<br>
<p><strong>Voir aussi</strong> : <a href=
"../stopping.html">Arrêter et redémarrer
Apache</a></p>
<hr>
<h2><a name="scriptinterpretersource">ScriptInterpreterSource
directive</a></h2>
<!--%plaintext <?INDEX {\tt ScriptInterpreterSource} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> ScriptInterpreterSource registry|script<br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a>
<code>ScriptInterpreterSource script</code> <br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> répertoire, .htaccess<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau (seulement sur Windows)
<p>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).</p>
<hr>
<h2><a name="sendbuffersize">Directive SendBufferSize</a></h2>
<!--%plaintext <?INDEX {\tt SendBufferSize} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> SendBufferSize <em>octets</em><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>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).</p>
<hr>
<h2><a name="serveradmin">Directive ServerAdmin</a></h2>
<!--%plaintext <?INDEX {\tt ServerAdmin} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> ServerAdmin <em>adresseEMail</em><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôte virtuel<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>La directive <tt>ServerAdmin</tt> définit l'adresse
e-mail que le serveur inclut dans tout message d'erreur
retourné au client.</p>
<p>Il peut être utile de dédier une adresse
réservée à cet usage, par exemple :</p>
<blockquote><code>ServerAdmin
www-admin@foo.bar.com</code></blockquote>
<p>car les utilisateur ne rappellent pas toujours dans leur
message ce à propos de quoi ils interviennent!</p>
<hr>
<h2><a name="serveralias">Directive ServerAlias</a></h2>
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> ServerAlias <em>hôte1 hôte2
...</em><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> hôte virtuel<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a>
<tt>ServerAlias</tt> est disponible à partir de la version
1.1 d'Apache
<p>La directive <tt>ServerAlias</tt> défini un nom
secondaire pour un hôte, utilisable dans le contexte d'<a
href="../vhosts/name-based.html">hôte virtuels
nommés</a>.</p>
<p><strong>Voir aussi :</strong> <a href=
"../vhosts/index.html">Hôtes virtuels sur Apache</a></p>
<hr>
<h2><a name="servername">Directive ServerName</a></h2>
<!--%plaintext <?INDEX {\tt ServerName} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> ServerName <em>nom de domaine entièrement
qualifié</em><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôte virtuel<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>La directive <tt>ServerName</tt> 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 :</p>
<blockquote><code>ServerName www.wibble.com</code></blockquote>
<p>peut être défini lorsque le nom canonique
(principal) de la machine actuelle est
<code>monster.wibble.com</code>.</p>
<p>Si vous utilisez des <a href=
"../vhosts/name-based.html">hôtes virtuels
nommés</a>, la directive <code>ServerName</code> à
l'intérieur d'une section <a href=
"#virtualhost"><code><VirtualHost></code></a> impose que
quel nom d'hôte doit apparaître dans l'en-tête
<code>Host:</code> d'une requête pour être
associé à cet hôte virtuel.</p>
<p><strong>Voir aussi</strong> : <a href=
"../dns-caveats.html">Apache et DNS</a> <a href=
"../vhosts/">documentation sur les hôtes virtuels
Apache</a><br>
<a href="#usecanonicalname">UseCanonicalName</a><br>
<a href="#namevirtualhost">NameVirtualHost</a><br>
<a href="#serveralias">ServerAlias</a><br>
</p>
<hr>
<h2><a name="serverpath">Directive ServerPath</a></h2>
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> ServerPath <em>chemin</em><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> hôte virtuel<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a>
<tt>ServerPath</tt> est disponible à partir de la version
1.1 d'Apache.
<p>La directive <tt>ServerPath</tt> définit le chemin
d'accès servant de base pour les URL ciblant un <a href=
"../vhosts/index.html">hôte virtuel nommé</a>.</p>
<p><strong>Voir aussi :</strong> <a href=
"../vhosts/index.html">Hôtes virtuels sur Apache</a></p>
<hr>
<h2><a name="serverroot">Directive ServerRoot</a></h2>
<!--%plaintext <?INDEX {\tt ServerRoot} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> ServerRoot <em>nomrépertoire</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>ServerRoot
/usr/local/apache</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>La directive <tt>ServerRoot</tt> définit le
répertoire dans lequel se situe le serveur. Typiquement,
ce répertoire contiendra les sous-répertoires
<code>conf/</code> et <code>logs/</code>. Les chemins
d'accès relatifs pour d'autres fichiers de configuration
seront considérés relativement à ce
répertoire.<br>
Voir aussi <a href="../invoking.html">les <code>-d</code> options
de httpd</a>.</p>
<p>Voir aussi <a href="../misc/security_tips.html#serverroot">les
trucs de sécurité</a> pour plus d'informations sur
comment correctment définir les droits d'accès
à ServerRoot.</p>
<hr>
<h2><a name="serversignature">Directive ServerSignature</a></h2>
<!--%plaintext <?INDEX {\tt ServerSignature} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> ServerSignature On|Off|EMail<br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>ServerSignature
Off</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôte virtuel,
répertoire, .htaccess<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a>
ServerSignature est disponible à partir de la version 1.3.
<p>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.<br>
La valeur par défaut <samp>Off</samp> supprime la ligne
d'erreur (et est compatible avec le comportement d'Apache 1.2 et
précédents). La valeur <samp>On</samp> ajoute une
ligne contenant la version du serveur, la valeur de <a href=
"#servername">ServerName</a> de l'hôte virtuel et la valeur
<samp>EMail</samp> ajoute une référence "mailto:"
vers l'adresse <a href="#serveradmin">ServerAdmin</a> du document
demandé.</p>
<hr>
<h2><a name="servertokens">Directive ServerTokens</a></h2>
<!--%plaintext <?INDEX {\tt ServerTokens} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> ServerTokens Minimal|ProductOnly|OS|Full<br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>ServerTokens
Full</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur <br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> ServerTokens
est disponible à partir de la version 1.3 d'Apache. Le mot
clé <code>ProductOnly</code> est disponible à
pertir de la version 1.3.12
<p>Cette directive contrôle si le champ <samp>Server</samp>
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.</p>
<dl>
<dt><code>ServerTokens Prod[uctOnly]</code></dt>
<dd>Le serveur renvoie par exemple : <samp>Server:
Apache</samp></dd>
<dt><code>ServerTokens Min[imal]</code></dt>
<dd>Le serveur renvoie par exemple : <samp>Server:
Apache/1.3.0</samp></dd>
<dt><code>ServerTokens OS</code></dt>
<dd>Le serveur renvoie par exemple : <samp>Server: Apache/1.3.0
(Unix)</samp></dd>
<dt><code>ServerTokens Full</code> (ou non
spécifié)</dt>
<dd>Le serveur renvoie par exemple : <samp>Server: Apache/1.3.0
(Unix) PHP/3.0 MyMod/1.2</samp></dd>
</dl>
<p>Cette directive s'applique à la globalité du
serveur et ne paut pas être activé ou
désactivé sur la base d'hôtes virtuels.</p>
<hr>
<h2><a name="servertype">Directive ServerType</a></h2>
<!--%plaintext <?INDEX {\tt ServerType} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> ServerType <em>type</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>ServerType
standalone</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>La directive <tt>ServerType</tt> définit comment le
serveur est exécuté par le système
d'exploitation. <em>Type</em> peut prendre l'une des valeurs
suivantes :</p>
<dl>
<dt>inetd</dt>
<dd>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 <code>/etc/inetd.conf</code></dd>
<dt>standalone</dt>
<dd>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.
(<code>/etc/rc.local</code> ou <code>/etc/rc3.d/...</code>.)</dd>
</dl>
<p>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é.</p>
<p>Standalone est l'option la plus fréquente pour la
directive <tt>ServerType</tt> 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.</p>
<hr>
<h2><a name="startservers">Directive StartServers</a></h2>
<!--%plaintext <?INDEX {\tt StartServers} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> StartServers <em>nombre</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>StartServers
5</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>La directive <tt>StartServers</tt> 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.</p>
<p>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 <a href=
"#threadsperchild">ThreadsPerChild</a> contrôle le nombre
maximal de threads traitant les requêtes, ce qui a un effet
similaire à la directive Unix
<samp>StartServers</samp></p>
<p>Voir aussi <a href="#minspareservers">MinSpareServers</a> et
<a href="#maxspareservers">MaxSpareServers</a>.</p>
<hr>
<h2><a name="threadsperchild">Directive ThreadsPerChild</a></h2>
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> ThreadsPerChild <em>nombre</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>ThreadsPerChild
50</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau (Windows)<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> Disponible
seulement à partir de la version 1.3 pour Windows d'Apache
<p>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é.</p>
<p>Cette directive n'a aucun effet sur les systèmes Unix.
Les utilisateurs Unix regarderont les directives <a href=
"#startservers">StartServers</a> et <a href=
"#maxrequestsperchild">MaxRequestsPerChild</a>.</p>
<hr>
<h2><a name="threadstacksize">Directive ThreadStackSize</a></h2>
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> ThreadStackSize <em>nombre</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>ThreadStackSize
65536</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau (NetWare)<br>
<strong>Compatibilité :</strong> disponible à
partir de la version d'Apache 1.3 sur Netware.
<p>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.</p>
<p>Cette directive n'a aucun effet sur les autres
systèmes.</p>
<hr>
<h2><a name="timeout">Directive TimeOut</a></h2>
<!--%plaintext <?INDEX {\tt TimeOut} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> TimeOut <em>nombre</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>TimeOut
300</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>La directive <tt>TimeOut</tt> définit la temporisation
courante pendant laquelle Apache attendra l'une de ces trois
choses :</p>
<ol>
<li>Le temps total de réception d'une requête
GET.</li>
<li>Le temps entre la réception de paquets TCP lors d'une
requête POST ou PUT.</li>
<li>Le temps entre deux acquittements lors de la transmission de
paquets TCP de réponse.</li>
</ol>
<p>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.</p>
<hr>
<h2><a name="usecanonicalname">UseCanonicalName
directive</a></h2>
<!--%plaintext <?INDEX {\tt UseCanonicalName} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> UseCanonicalName on|off|dns<br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a>
<code>UseCanonicalName on</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôte virtuel,
répertoire<br>
<a href="directive-dict.html#Override" rel=
"Help"><strong>Surcharge :</strong></a> Options<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a>
UseCanonicalName est disponible à partir de la verion 1.3
<p>Dans beaucoup de situations, Apache doit construire des URL
<em>s'autoréférençant</em>, autremnet dit,
des URL référençant le même serveur.
Avec la directive <code>UseCanonicalName on</code> (dans les
versions d'Apache inférieures à 1.3) Apache utilise
les valeurs des directives <a href="#servername">ServerName</a>
et <a href="#port">Port</a> pour construire un nom canonique du
serveur. Ce nom est utilisé pour toutes les URL
autoréférentes et pour les valeurs de
<code>SERVER_NAME</code> et <code>SERVER_PORT</code> pour les
scripts CGI.</p>
<p>Avec <code>UseCanonicalName off</code>, 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 <a href=
"../vhosts/name-based.html">hôtes virtuels basés sur
des noms</a>, et sont disponibles pour les mêmes clients.
Les variable CGI <code>SERVER_NAME</code> et
<code>SERVER_PORT</code> seront aussi construites à partir
des valeurs fournies par les clients.</p>
<p>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
<code>www</code>. Vous noterez que si l'utilisateur tape un nom
court et que l'URL est un répertoire tel que
<code>http://www/splat</code>, <em>sans le caractère
oblique / final</em> , Apache redirigera la requête vers
<code>http://www.domain.com/splat/</code>. Si vous avez une
authentification active, lu'tilisateur devra s'authentifier deux
fois, (une première fois pour <code>www</code> 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 <code>www.domain.com</code>). Mais si la directive
<code>UseCanonicalName</code> est à off, Apache redirigera
vers <code>http://www/splat/</code>.</p>
<p>Il existe une troisième option, <code>UseCanonicalName
DNS</code>, 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 <code>Host:</code>. 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.</p>
<p><strong>Attention :</strong> si les scripts CGI font des
suppositions sur les valeurs de <code>SERVER_NAME</code> il
peuvent ne plus fonctionner avec cette option. Mais le script CGI
utilise uniquement <code>SERVER_NAME</code> pour construire des
URL autoréférentes, il ne evrait y avoir aucun
problèmes.</p>
<p><strong>Voir également :</strong> <a href=
"#servername">ServerName</a>, <a href="#port">Port</a></p>
<hr>
<h2><a name="user">Directive User</a></h2>
<!--%plaintext <?INDEX {\tt User} directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> User <em>utilisateurUnix</em><br>
<a href="directive-dict.html#Default" rel=
"Help"><strong>Défaut :</strong></a> <code>User
#-1</code><br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur, hôte virtuel<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> noyau
<p>La directive <tt>User</tt> définit l'utilisateur
associé au serveur. Pour utiliser cette directive, un
serveur standalone devra être lancé sous
<code>root</code>. <em>utilisateurUnix</em> est l'un parmi :</p>
<dl>
<dt>un nom d'utilisateur</dt>
<dd>se réfère à un utilisateur
déclaré du système.</dd>
<dt># suivi d'un numéro d'utilisateur.</dt>
<dd>se réfère à l'utilisateur
déclaré du système portant ce
numéro.</dd>
</dl>
<p>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
<code>nobody</code>, 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 <a href=
"mod_proxy.html#cacheroot"><code>CacheRoot</code></a> ).</p>
<p><strong>Note :</strong> 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
<code>root</code>, alors il sera normal que le processus
père continue à s'exécuter sous
<code>root</code>.</p>
<p><strong>Note spécifique :</strong> L'utilisation de
cette directive dans une section <tt><VirtualHost></tt>
nécessite un <a href="../suexec.html">wrapper suEXEC</a>
correctement configuré. Lorsqu'elle est utilisée de
cette façon dans une section <tt><VirtualHost></tt>,
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.</p>
<p><strong>Sécurité :</strong> Ne définissez
pas l'utilisateur (ni le <a href="#group">groupe</a>) comme
<code>root</code> sauf si vous savez exactement ce que vous
faites, et si vous êtes totalement conscients des risques
qui sont encourus.</p>
<hr>
<h2><a name="virtualhost">Directive <VirtualHost></a></h2>
<!--%plaintext <?INDEX {\tt VirtualHost} section directive> -->
<a href="directive-dict.html#Syntax" rel="Help"><strong>Syntaxe
:</strong></a> <VirtualHost <em>adresse</em>[:<em>port</em>]
...> ... </VirtualHost> <br>
<a href="directive-dict.html#Context" rel="Help"><strong>Contexte
:</strong></a> configuration serveur<br>
<a href="directive-dict.html#Status" rel="Help"><strong>Statut
:</strong></a> Core<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> la
"virtualisation" d'hôtes non basés sur l'adressage
IP n'est disponible qu'à partir de la version 1.1
d'Apache<br>
<a href="directive-dict.html#Compatibility" rel=
"Help"><strong>Compatibilité :</strong></a> le support
d'adresses multiples n'est disponible qu'à partir de la
version 1.2 d'Apache
<p>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. <em>Adresse</em>
peut être :</p>
<ul>
<li>l'adresse IP de l'hôte virtuel</li>
<li>un nom de domaine entièrement qualifié pour
l'adresse IP de cet hôte virtuel.</li>
</ul>
<p>Exemple :</p>
<blockquote>
<pre>
<code><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>
</code>
</pre>
</blockquote>
<p>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 <code>ifconfig alias</code> (si
votre OS l'accepte), ou par des patchs du kernel du type <a href=
"../misc/vif-info.html">VIF</a> (pour SunOS(TM) 4.1.x)).</p>
<p>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 :</p>
<blockquote><code><VirtualHost 192.168.1.2
204.255.176.199><br>
DocumentRoot /www/docs/host.foo.com<br>
ServerName host.foo.com<br>
ServerAlias host<br>
</VirtualHost></code></blockquote>
<p>Le nom prédéfini <code>_default_</code> 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.</p>
<p>Vous pouvez spécifier une commande <code>:port</code>
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 <code><a href="#port">Port</a></code> de la section
principale qui précède. Vous pouvez
également spécifier <code>:*</code> pour
reconnaître tous les ports à cette adresse. (Ceci
est conseillé lorsque l'hôte virtuel est le
<code>_default_</code>.)</p>
<p><strong>Sécurité</strong>: Voir les <a href=
"../misc/security_tips.html">conseils de
sécurité</a> 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.</p>
<p><strong>Note</strong>: L'utilisation de la directive
<VirtualHost> <strong>n'</strong> affecte
<strong>pas</strong> 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 <a href="#bindaddress">BindAddress</a> ou <a href=
"#listen">Listen</a>.</p>
<p><strong>Voir aussi :</strong> <a href=
"../vhosts/index.html">Hôtes virtuels sur Apache</a><br>
<a href="../dns-caveats.html">Avertissement concernant DNS et
Apache</a><br>
<a href="../bind.html">Configurer les ports et adresses
utilisés par Apache</a></p>
<p><strong>Voir aussi</strong> : <a href=
"../sections.html">Comment fonctionnent les sections concernant
les répertoires, chemins et fichiers</a> pour une
explication plus précise concernant la manière dont
ces sections sont combinées lorsqu'une requête est
traitée. <!--#include virtual="footer.html" -->
</p>
</body>
</html>