![[APACHE DOCUMENTATION]](../images/sub.gif)
Apache HTTP Server Version 1.3
Is this the version you want? For more recent versions, check our documentation index.
Is this the version you want? For more recent versions, check our documentation index.
Ces paramètres de configuration contrôlent les fonctionnalités premières d'Apache, et sont toujours disponibles.
AccceptFilter onAcceptFilter contrôle une optimisation
spécifique à BSD. Elle est compilée par
défaut et activée par défaut si votre
système l'implémente (option SO_ACCCEPTFILTER de
setsocketopt()). A l'heure actuelle, seul FreeBSD
l'implémente.
Se référer à la section concernant les filtres dans la documentation sur la performance pour de plus amples informations.
L'option de compilation AP_ACCEPTFILTER_OFF
peut être utilisée pour changer le défaut
à 'off'. httpd -V et httpd -L
affichent dorénavant les valeurs par défauts au
moment de la compilation, et si oui ou non SO_ACCEPTFILTER a
été défini pour cette compilation.
AccessConfig conf/access.confLe serveur lit dans ce fichier des directives supplémentaires après avoir ouvert le fichier ResourceConfig. nomfichier est exprimé relativement à ServerRoot. Cette fonctionnalité peut être désactivée en écrivant :
AccessConfig /dev/null
ou sur les serverus Win32
AccessConfig nul
Historiquement, ce fichier ne contenait que des sections <Directory>; en fait, il pourra maintenant contenir toute directive "serveur" autorisée dans le contexte de la configuration serveur.
Une nouveauté de la version d'Apache 1.3.13 est la
possibilité qu'AccessConfig
représente un répertoire plutot qu'un fichier.
Apache lira tous les fichiers de ce répertoire ainsi que
tous les sous-répertoires et analysera tous ces fichiers
de configuration.
Voir également ResourceConfig.
AccessFileName .htaccessLorsqu'il retourne un document au client, le serveur cherche le premier fichier de contrôle d'accès existant dans cette liste dans chacun des répertoires inscrit dans le chemin d'accès menant au document, pour déterminer si l'accès est autorisé dan chacun de ces répertoires. Par exemple:
AccessFileName .acl
Avant de servir le document
/usr/local/web/index.html, le serveur lira les
fichiers /.acl, /usr/.acl,
/usr/local/.acl et
/usr/local/web/.acl à la recherche de
directives, sauf si celles-ci ont été
désactivées par l'écriture
<Directory /> AllowOverride None
</Directory>
Voir également : AllowOverride
AddDefaultCharset OffCette directive spécifie le nom de la table de
caractères qui sera ajouté à toutes les
réponses qui n'ont aucun paramètre sur le type de
contenu dans l'en-tête HTTP. Elle remplace la table de
caractère spécifié dans le corps du
document par l'utilisation du marqueur META. La
mise de AddDefaultCharset Off désactive
cette fonctionnalité. AddDefaultCharset On
active la table de caractère iso-8859-1 par
défaut d'Apache. Vous pouvez également
définir une autre table de caractères à
employer. Par exemple AddDefaultCharset utf-8.
Le serveur peut intégrer des modules compilés qui ne sont pas mis en service. Cette directive peut être utilisée pour activer ou désactiver ces modules. Le serveur est installé avec une liste pré-configurée de modules actifs cette liste peut être effacée par la directive ClearModuleList.
AllowOverride All AllLorsque le serveur trouve un fichier .htaccess (comme spécifié par AccessFileName) il doit savoir quelles directives declarées dans ce fichier peuvent outrepasser les droits fixés par des directives précédentes.
Si la directive est définie à
None, les fichier .htaccess sont ignorés.
Dans ce cas, le serveur n'essaie même pas de lire les
fichiers .htaccess.
Si la directive est définie à All
toutes les directives possibles dans le contexte .htacces sont
autorisées dans les fichiers .htaccess.
Les types de directives peuvent être parmi ces groupes de directives :
Voir également : AccessFileName
Cette directive indique le nom du schéma d'autorisation pour un répertoire. Ce schéma sera donné au client de sorte que l'utilisateur sache quel nom et quel mot de passe envoyer. AuthName prend un seul argument. Si le schéma d'autorisation contient des espaces, il doit être entouré de guillemets. Pour fonctionner correctement, elle devra être accompagnée des directives AuthType et require, et de directives telles que AuthUserFile et AuthGroupFile.
Cette directive selectionne le type d'authentification pour
un répertoire. Seul les types Basic et
Digest sont actuellement
implémentés.
Pour fonctionner correctement, elle devra être
accompagnée des directives AuthName et require, et de directives telles que AuthUserFile et AuthGroupFile.
BindAddress *Un serveur http sous Unix® peut soit écouter toutes les adresses IP de la machine sur lequel il est exécuté, ou uniquement une de ces adresses. Si l'argument de cette directive est *, le serveur traitera les connections sur toutes les adresses IP. Sinon, le serveur peut écouter à partir d'une adresse IP spécifique ou d'un nom de domaine Internet.
Une et une seule directive BindAddress peut être utilisée. Pour contrôler plus finement quels ports et adresses Apache écoute, utilisez la directive Listen au lieu de BindAddress.
BindAddress peut être utilisée comme alternative à l'implantation d'hôtes virtuels utilisant des serveurs multiples indépendants, soit au lieu d'utiliser les sections <VirtualHost>.
Voir aussi: Apache et DNS
Voir aussi: Configurer
les ports et adresses utilisés par Apache
La directive BS2000Account n'est disponible que
pour les machines BS2000. Elle doit être employée
pour définir le numéro de compte pour
l'utilisateur non privilégié (qui est
défini par la directive User ). Ceci
est requis par le sous système POSIX du BS2000 afin de
changer l'environnement d'exécution sosu jacent du BS200
en effectuant une sous connexion, et éviter ainsi que
des scripts CGI puissent accéder à des ressources
accessible à l'utilisateur privilégié
utilisé pour lancer le serveur,
généralement SYSROOT.
Seulement une directive BS2000Account peut
être utilisée.
Voir également: Portage EBCDIC d'Apache
Le serveur dispose à l'installation d'une liste pré-configurée de modules actifs. Cette directive efface cette liste. Il est supposé que cette liste sera reconstruite à partir de directives AddModule.
ContentDigest offCompatibilité : ContentDigest n'est disponible qu'à partir de la version 1.1 d'Apache
Cette directive active la génération
d'en-têtes Content-MD5 conformes aux RFC1864
et RFC2068.
MD5 est un algorithme permettant d'extraire un "résumé" à partir d'un bloc de données de longueur arbitraire, avec un degré de confiance suffisant dans la mesure ou une moindre altération dans les données sera reflétée par un changement dans le "résumé".
L'en-tête Content-MD5 procure un test de
l'intégrité de message de bout en bout (MIC) sur
le corps d'entité. Un proxy ou client pourra tester cet
en-tête pour détecter des modifications
accidentelles du corps d'entité en cours de transfert.
Exemple d'en-tête:
Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==
Notez que ceci peut réduire les performances de votre serveur dans la mesure où le "résumé" est calculé à chaque requête (il ne peut être mis en cache).
Content-MD5 n'est émis que pour des
documents servis par le noyau, et à l'exception de tout
module. Par exemple, les documents SSI, la sortie de scripts
CGI, et des réponses en flux d'octet binaire ne pourront
utiliser cet en-tête.
Elle définit le répertoire auquel Apache tente d'accéder avant d'enregistrer un "noyau dump". Par défaut, il s'agit du répertoire ServerRoot, cependant, si ce répertoire n'est pas accessible en écriture par l'utilisateur sous lequel tourne le serveur, le "noyau dump" ne pourra être généré. Si vous souhaitez dans ce cas obtenir un "noyau dump" pour des nécessités de débogage, vous pouvez utiliser cette directive pour spécifier un autre répertoire dans lequel vous avez toute autorisation pour écrire.
DefaultType text/htmlIl peut arriver qu'une requête demande au serveur un document dont le type ne peut être déterminé par les tables de MIME.
Le serveur doit informer le client du type de contenu (Content-type) du document. Dans le cas d'un type inconnu, il utilisera le DefaultType. Par exemple :
DefaultType image/gif
sera approprié dans un répertoire contenant une majorité d'images gif dont certaines ne présentent pas explicitement l'extension .gif.
<Directory> et </Directory> sont utilisés pour "encapsuler" un groupe de directives applicables uniquement au réprtoire indiqué ainsi qu'à ses sous-répertoires. Toute directive autorisée dans un contexte de répertoire peut apparaître entre ces deux balises. nomrépertoire est soit le chemin entièrement qualifié du répertoire, ou un motif. Dans un motif, '?' remplace un caractère unique quelconque, et '*' remplace toute séquence de zéro ou plus caractères quelconques. Sur Apache 1.3, vous pouvez aussi utiliser les plages de caractères '[]' comme dans un shell UNIX. De plus aucun des métacaractères ne peut remplacer un '/', ce qui correspond plus intimement à la réaction des shells UNIX. Exemple:
<Directory /usr/local/httpd/htdocs> Options Indexes FollowSymLinks </Directory>
A partir d'Apache 1.2 : peuvent être
utilisées les "expressions régulières",
lesquelles devront être précédées du
caractère ~. Par exemple :
<Directory ~"^/www/.*/[0-9]{3}">
correspondrait à des répertoires dans /www/ dont
le nom serait constitué de trois digits.
Si plusieurs sections de répertoires pointent sur le répertoire d'un document (ou l'un de ses pères) sans qu'il s'agisse d'une expression régulière, alors les directives sont appliquées selon la loi de "la plus courte qualification d'abord", combinées aux directives des fichiers .htaccess. Par exemple, avec l'écriture
<Directory /> AllowOverride None
</Directory> <Directory /home/*> AllowOverride
FileInfo </Directory>
pour le contrôle d'accès au document
/home/web/dir/doc.html les étapes
d'évaluation sont les suivantes :
AllowOverride None
(désactivant les fichiers
.htaccess).AllowOverride FileInfo
(pour le répertoire /home/web)./home/web/.htaccessLes sections exprimant des répertoires sous forme d'expressions régulières sont gérés légèrement différemment par Apache 1.2 et 1.3. Sous Apache 1.2, elles sont combinées aux sections "normales" et s'appliquent dans l'ordre où elles apparaissent dans le fichier de configuration. Elles ne s'appliquent qu'une fois, seulement pour celles qui font partie de la section "à plus courte correspondance". Sous Apache 1.3 les sections basées sur des expressions régulières ne sont pas évaluées tant que toutes les sections "normales" n'ont pas été considérées. A ce moment, les sections "régulières" sont traitées dans l'ordre où elles apparaissent dans le fichier de configuration. Par exemple, avec l'écriture
<Directory ~ abc$> ... directives ici ...
</Directory>
Supposez que le nom de fichier demandé soit
/home/abc/public_html/abc/index.html. Le serveur
considère chacune des sections /,
/home, /home/abc,
/home/abc/public_html, et
/home/abc/public_html/abc dans cet ordre. Sous
Apache 1.2, lorsque /home/abc est pris en compte,
l'expression régulière correspondra et ses termes
seront appliqués. Sous Apache 1.3 l'expression
régulière n'est pas considérée du
tout à ce point de l'arbre. Elle ne le sera pas tant que
toutes les sections "normales" <Directory>s et
celles des fichiers .htaccess n'ont pas
été appliquées. A ce moment seulement
l'expression régulière reconnaîtra
/home/abc/public_html/abc et les directives seront
appliquées.
Notez que l'accès par défaut d'Apache
pour les sections <Directory> est Allow
from All. Ceci veut dire que par défaut, Apache
desservira tout fichier indiqué par une URL. Nous
recommandons de modifier ceci à l'aide d'un bloc tel
que
<Directory />
Order Deny,Allow
Deny from All
</Directory>
puis désactiver sélectivement la protection pour les répertoires devant rester accessibles. Voir la page Trucs sur la sécurité pour plus de détails.
Les sections de répertoires apparaissent habituellement dans le fichier access.conf, mais peuvent être présentes dans n'importe quel fichier de configuration. Les directives <Directory> ne peuvent être imbriquées, et ne peuvent petre incluses dans des sections <Limit> ou <LimitExcept>.
Voir aussi : Comment fonctionnent les sections concernant les répertoires, chemins et fichiers pour une explication plus précise concernant la manière dont ces sections sont combinées lorsqu'une requête est traitée.
<DirectoryMatch> et </DirectoryMatch> sont utilisés pour encapsuler un groupe de directives s'appliquant uniquement aux répertoires nommés et ses sous-répertoires, de manière identique à la directive <Directory>. Cependant, elle n'accepte comme argument qu'une expression régulière. Par exemple :
<DirectoryMatch "^/www/.*/[0-9]{3}">
correspondrait aux répertoires de /www/ dont le nom consiste en trois chiffres.
Voir aussi : <Directory> pour une description de
la manière dont les définitions par expression
régulière sont combinées aux sections
<Directory> "normales".
Voir aussi : Comment fonctionnent les sections
concernant les répertoires, chemins et fichiers pour
une explication plus précise concernant la
manière dont ces sections sont combinées
lorsqu'une requête est traitée
DocumentRoot /usr/local/apache/htdocsCette directive définit le répertoire racine à partir duquel httpd va distribuer les fichiers. Sauf si le répertoire est pointé par une directive telle que Alias, le serveur ajoute le chemin relatif mentionnée dans l'URL présentée à cette racine pour établir le chemin complet jusqu'au document. Exemple :
DocumentRoot /usr/web
Un accès à
http://www.my.host.com/index.html se
réferre au document
/usr/web/index.html.
Un bogue existe pour cette directive mod_dir, laquelle fonctionne mal lorsque DocumentRoot est donnée avec un '/' final (c-à-d. "DocumentRoot /usr/web/"). Il vaut mieux éviter cette écriture.
La directive EBCDICConvert associe une extension de fichier à une possible conversion (On ou Off). Les extensions de fichiers peuvent commencer ou non par un point.
Si le format optionnel On=direction (or
Off=direction) est employé,
où direction est choisi parmi In,
Out ou InOut, alors la directive ne
s'applique seulement que dans une direction de transfert
donnée (In : contenu reçu par une
requête PUT ou POST , Out : contenu
renvoyé à une requete GET ou POST, et
InOut : conversion dans les deux
directions).
Sinon, InOut (conversion dans les deux
directions) est défini.
La configuration de conversion basé sur un type de fichier est testé avant la configuration basé sur les types MIME, afin de permettre aux règles génériques MIME d'être surchargées par une extension spécifique (pplusieurs extensions de fichier peuvent exister pour le même type MIME).
Exemple:
Avec la configuration suivante, les fichiers
*.html contiennent du texte HTML au format EBCDIC,
tandis que les fichiers *.ahtml contiennent du
texte HTML au format ASCII :
# *.html et *.ahtml contiennet du texte HTML :
AddType text/html .html .ahtml
# *.ahtml n'est pas converti (il contient déjà du texte ASCII)
EBCDICConvert Off .ahtml
# Les autres fichiers text/html contiennent du texte EBCDIC:
EBCDICConvertByType On text/html
Voir également: EBCDICConvertByType et Aperçu des fonctions de conversion EBCDIC
La directive EBCDICConvertByType associe un type MIME (pouvant contenir une *) à une éventuelle conversion (On ou Off).
Si le format optionnel On=direction (or
Off=direction) est employé,
où direction est choisi parmi In,
Out ou InOut, alors la directive ne
s'applique seulement que dans une direction de transfert
donnée (In : contenu reçu par une
requête PUT ou POST , Out : contenu
renvoyé à une requete GET ou POST, et
InOut : conversion dans les deux
directions).
Sinon, InOut (conversion dans les deux
directions) est défini.
Par exemple:
Une configuration standard pratique devrait au moins contenir
ces directives :
# All text documents are stored as EBCDIC files:
# Tous les document textes sont stockés au format EBCDIC
EBCDICConvertByType On text/* message/* multipart/*
EBCDICConvertByType On application/x-www-form-urlencoded \
model/vrml application/postscript
# Les autres fichiers sont traités comme binaires.
EBCDICConvertByType Off */*
Si vous servez seulement que des documents ASCII, par exemple
provenant d'un montage NFS d'un serveur Unix, utilisez :
# Tous les documents sont déjà en ASCII:
EBCDICConvertByType Off */*
Voir également: EBCDICConvert et Aperçu des fonctions de conversion EBCDIC
EBCDICKludge
OffThe EBCDICKludge est proposée par compatibilité avec les versions d'Apache 1.3.0 à 1.3.18. Dans ces versions, tous les fichiers dont le type MIME commence par "text/", "message/" ou "multipart/" ou dont le type est "application/x-www-form-urlencoded" sont convertis par défaut, les autres documents sont retournés sans conversion. Un document est présumé être au format ASCII iuniquement si il est du type "text/x-ascii-sous-type", et ne sera donc pas converti. A la place, le préfixe "x-ascii-" était supprimé du type, obtenant ainsi le type MIME "text/sous-type" comme type du document retourné.
Si la directive EBCDICKludge est mise à
On, et si aucune des extensions de fichiers ne
correspondent aux directives EBCDICConvert définis dans le
contexte , alors le serveur teste avec le type MIME de format
type/x-ascii-sous-type. Si le
document a un tel type alors la chaîne
"x-ascii-" est supprimée et la
conversion est mise à Off. Cela permet de
surcharger l'assertion implicite que tous les fichiers sont
stockés au format EBCDIC, par exemple si Apache sert des
fichiers provenant d'un montage NFS d'un répertoire
contenant des documents ASCII.
En utilisant EBCDICKludge, Il n'y a aucun moyen de forcer un
des autres types MIME (par exemple model/vrml) d'être
traité au format EBCDIC. L'utilisation de la directive
EBCDICConvertByType est
préférable pour définir une telle
conversion. Avant Apache 1.3.19, il n'y avait aucun moyen de
forcer ces document binaires d'être traités comme
des fichiers textes EBCDIC
Voir également : EBCDICConvert, EBCDICConvertByType and Aperçu des fonctions de conversion EBCDIC
Dans l'éventualité d'un problème ou d'une erreur, Apache peut exécuter l'une des quatre actions suivantes :
La première option est celle par défaut, les options 2 à 4 seront obtenues en utilisant la directive ErrorDocument, suivi du code HTTP d'erreur et du message textuel d'erreur, ou une URL.
Messages dans ce contexte, commence par un
guillemet simple ("), qui ne fait pas partie du
message lui-même. Apache ajoutera souvent des
informations complémentaires explicitant le
problème (ou l'erreur).
L'URL peut débuter par un slash (/) pour des URL locales, ou être complètement qualifiées. Exemples:
ErrorDocument 500
http://foo.example.com/cgi-bin/tester
ErrorDocument 404 /cgi-bin/bad_urls.pl
ErrorDocument 401 /subscription_info.html
ErrorDocument 403 "Sorry can't allow you access today
Notez que lorsque vous spécifiez un
ErrorDocument qui pointe vers une URL externe (c'est
-à-dire toute adresse commençant par quelque
chose du style "http:") Apache émettra une requête
de redirection au client pour lui indiquer où trouver le
document. Ceci peut perturber les robots et d'autres clients
qui essaient de déterminer si une URL est valide en
testant le code retour de la requête. De plus, si vous
utilisez l'écriture ErrorDocument 401 le
client ne saura pas qu'il doit demander un mot de passe
puisqu'il ne recevra pas le code retour 401. Par
conséquent, il est impératif d'utiliser une URL
locale pour une directive "ErrorDocument 401". Ceci est induit
par la nature des schémas d'authentification de base
d'HTTP.
Voir aussi: documentation sur les réponses personnalisées.
ErrorLog
logs/error_log (Unix)ErrorLog
logs/error.log (Windows et OS/2)Cette directive définit le nom du fichier dans lequel le serveur marque la trace des erreurs rencontrées. Si le nom de fichier ne commence pas par un slash (/), alors la partie "chemin d'accès" est considérée relativement à ServerRoot. Exemple:
ErrorLog /dev/null
Cette expression a pour effet de désactiver la trace d'erreurs.
Si le fichier commence par une barre verticale (|), il est censé être une commande à exécuter pour ttraiter le message d'erreur.Apache 1.3 et ultérieur: en
utilisant syslog à la place d'un fichier
permet d'employer syslogd(8) si le système l'accepte. Le
défau est d'utiliser la fonction syslog
local7, mais vous pouvez remplacer ceci en
utilisant la syntaxe syslog:service
où service peut être un des noms
documenté dans syslog(1).
Sécurité : Voir la page note sur la securité pour plus d'information concernant une possibilité de brêche de sécurité si le répertoire d'accueil des fichiers de trace peut être écrit par tout autre utilisateur que le propriétaire du processus serveur.
La directive <Files> permet une gestion de contrôle d'accès fichier par fichier. Elle est comparable aux directives <Directory> et <Location>. Elle doit s'apparier à une directive </Files>. Les directives applicables au fichier indiqué sont encapsulées entre ces deux balises. Les sections <Files> sont traitées dans l'ordre où elles apparaissent dans le fichier de configuration, une fois traitées les sections <Directory> et les fichiers .htaccess, mais avant les sections <Location>.
L'argument filename peut inclure un nom de fichier,
où un motif, dans lequel '?' correspond à tout
caractère unique quelconque, et '*' correspond à
une séquence de zéro à un nombre
quelconque de caractères. Les "expressions
régulières" peuvent aussi être
utilisées, pourvu qu'elles soient
précédées du caractère
~. Par exemple :
<Files ~"\.(gif|jpe?g|png)$">
correspondrait à la majorité des fichiers graphiques utilisés sur Internet. A partir de la version 1.3 d'Apache, l'usage de la directive <FilesMatch> est cependant préférable.
Notez que, contrairement aux sections <Directory> et <Location>, les sections
<Files> peuvent apparaître dans des
fichiers .htaccess. Ceci permet aux utilisateurs
de contrôler l'accès à leurs propres
fichiers, sur un mode individuel. Lorsqu'elles sont
utilisées dans un fichier .htaccess, si
nomfichier ne commence pas par un slash (/), le
répertoire courant contenant ledit fichier
.htaccess y sera préfixé
automatiquement.
Voir aussi : Comment fonctionnent les sections concernant les répertoires, chemins et fichiers pour une explication plus précise concernant la manière dont ces sections sont combinées lorsqu'une requête est traitée
La directive <FilesMatch> permet un contrôle d'accès fichier par fichier, tout comme la directive <Files>. Cependant, elle n'accepte qu'un argument sous forme d'expression régulière. Par exemple :
<FilesMatch "\.(gif|jpe?g|png)$">
qui correspondrait à la plupart des fichiers graphiques utilisés sur Internet.
Voir aussi : Comment fonctionnent les sections concernant les répertoires, chemins et fichiers pour une explication plus précise concernant la manière dont ces sections sont combinées lorsqu'une requête est traitée
Group
#-1La directive Group définit le groupe dont les requêtes seront traitées par le serveur. Pour utiliser cette directive, le serveur stand-alone doit tout d'abord être exécuté par l'utilisateur "root". groupeUnix est à choisir parmi :
Il est recommendé de créer un nouveau groupe
d'utilisateurs pour les utilisateurs exécutant le
serveur. Certains administrateurs assignent le serveur à
l'utilisateur nobody, mais ceci n'est pas toujours
possible ou souhaîtable.
Note : si vous démarrez le serveur sous un compte utilisateur autre que "root", la commutation sur un autre groupe échouera, et le groupe utilisé restera le groupe initial de l'utilisateur.
Note spéciale : L'utilisation de cette directive dans un contexte <VirtualHost> nécessite un suEXEC wrapper correctement configuré. De cette manière et dans ce contexte, seul le groupe dans lequel sont exécutés les CGI sont affectés. Toute requête autre que CGI sont toujours lancées dans le groupe défini par la directive Group principale.
Sécurité : Voir Utilisateur pour une discussion plus détaillée sur les aspects utilisateurs.
HostNameLookups offdouble n'est disponible qu'à partir de la
version 1.3 d'Apache.on pour
toute version antérieure à la version 1.3
d'Apache.
Cette directive autorise la résolution DNS pour la
trace d'accès (et pour les passer aux CGI/SSI en
REMOTE_HOST). La valeur double
signifie une résolution DNS inverse double.
C'est-à-dire, après qu'une résolution
inverse soit effectuée, une résolution est
ensuite effectuée à partir du résultat
obtenu. Au moins une des adresses IP obtenues par la
deuxième résolution doit correspondre à
l'adresse originale. (Dans le langage des "fous de tcp" ceci
s'appelle PARANOID.)
Indépendamment du mode choisi, lorsque mod_access est utilisé pour
faire du contrôle d'accès par nom d'hôte,
une résolution inverse double sera effectuée.
Ceci est indispensable pour des raisons de
sécurité. Notez que le résultat de cette
résolution inverse double n'est en général
pas accessible sauf si l'option HostnameLookups
double est activée. Par exemple, si l'option est
simplement HostnameLookups on et une requête
est reçue vers un objet soumis à des restrictions
quant aux noms d'hôtes, et quelque soit le
résultat de la réslution inverse double, les CGI
recevront le résultat de la résolution inverse
dans la variable d'environnement REMOTE_HOST.
Par défaut, l'état choisi était
on dans les versions d'apache antérieures
à la version 1.3. Elle est aujourd'hui à
off afin de diminuer le trafic pour les sites qui
n'ont pas un besoin absolu de la résolution inverse.
C'est aussi un avantage pour les utilisateurs finaux qui
n'auront pas à attendre la fin du processus de
résolution avant d'être servis. Des sites
chargés devraient plutôt laisser cette opyion
à off, dans la mesure où une
recherche DNS peut consommer un temps non négligeable.
L'utilitaire logresolve, fourni dans le
répertoire /support, peut être
utilisé pour résoudre des noms d'hôtes
à partir des adresses IP tracées en mode
"offline".
IdentityCheck offCette directive autorise une trace conforme à la
RFC1413 du nom d'utilisateur pour chaque connexion, lorsque la
machine cliente exécute identd ou un procesus similaire.
Cette information est tracée dans le fichier
access log. booléen vaut soit
on ou off.
Cette information n'est absolument pas certifiée et ne peut être considérée que pour une analyse sommaire.
Notez que ce fontionnement peut rallonger notablement les délais d'accès à votre serveur dans la mesure où chaque requête nécessite l'exécution d'une résolution. Lorsque des "firewalls" sont présents chaque résolution peut éventuellement échouer et ajouter ainsi 30 secondes d'attente pour chaque accès. En conclusion, cette option n'est en général pas opportune pour des serveurs Internet ouverts au public.
La section <IfDefine test>...</IfDefine> est employée pour délimiter des directives conditionnelles. Les directives à l'intérieur d'un section IfDefine ne sont prises en compte que si test est vraie. Si test est faux, tout ce qui se trouve entre le marqueur de début et celui de fin est ignoré.
Le test de la section <IfDefine> peut exister sous deux formes :
!nom-paramètreDans le premier cas, les directives entre les marqueurs de début et de fin ne sont traité que si le paramètre nommé nom-paramètre est défini. Dans le deuxième cas, les directives entre les marqueurs de début et de fin ne sont traité que si le paramètre nommé nom-paramètre n'est pas défini.
L'argument nom-paramètre est une
définition qui peut être donnée en ligne de
commande d'httpd en utilisant l'option
-Dnom-paramètre, au lancement du
serveur.
Les sections <IfDefine> peuvent s'imbriquer, ce qui permet de réaliser des test sur plusieurs paramètres. Par exemple :
$ httpd -DReverseProxy ... # httpd.conf <IfDefine ReverseProxy> LoadModule rewrite_module libexec/mod_rewrite.so LoadModule proxy_module libexec/libproxy.so </IfDefine>
La section <IfModule test>...</IfModule> permet de rendre conditionnelles un groupe de directives. Les directives à l'intérieur d'une section IfModule ne sont considérées que si le test est vérifié. Si test vaut faux, toute directive inclue entre la balise de début et celle de fin sont ignorées.
Le test d'une section <IfModule> peut prendre l'une des formes suivantes :
Dans le premier cas, les directives entre les deux balises de début et de fin ne sont traitées que si le module indiqué par nomModule est compilé dans votre version d'Apache. La seconde forme inverse le sens du test, et ne traite les directives que si le module nomModule n'est pas compilé.
L'argument nomModule spécifie un nom de
module par son nom de fichier source, tel qu'appelé par
la compilation. Par exemple, mod_rewrite.c.
Les sections <IfModule> peuvent être imbriquées, ce qui peut être utile pour implémenter simplement des tests multi-modules.
Cette directive permet l'inclusion d'autres fichiers de configuration à partir d'autres fichiers de configuration serveur.
A partir de la version Apache 1.3.13, si
Include pointe vers un répertoire plutot
qu'un fichier, Apche lira tous fichiers de ce
répertoire, ou des sous-répertoires, et traitera
chacun de ces fichiers de configuration.
KeepAlive
5KeepAlive
OnL'extension Keep-Alive d'HTTP/1.0 et les connexions
persistantes d'HTTP/1.1 fournissent des sessions durables HTTP
, qui autorisent plusieurs requêtes à être
envoyées sur la même connexion. Dans certains cas,
il a été constaté une réduction de
50% du temps de latence ppour des documents HTML contenant de
nombreuses images. Pour activer les connexions persistantes
(keep-alive) à partir d'Apache 1.2 il faut
définir la directive KeepAlive On.
Pour les clients HTTP/1.1, Les connexions persistantes ne sont employées que si elles sont spécifiquement demandées par un client. De plus, une connexion persistantes ne peut être employées que si la taille du contenu est connu à l'avance. Ceci implique que les contenus dynamiques, tels que les scripts CGI, les pages SSI, et les listes de répertoires générés par le serveur n'utilisent pas de connexions persistentes pour les clients HTTP/1.0. Pour les clients HTTP/1.1, les connexions sont persistantes par défaut à moins d'être spécifiée. Si le client le demande, l'encodage par tranches est utilisé afin d'envoyer des contenus de tailles inconnus au travers de connxions persistantes.
Sous Apache 1.1: Mettre
requêtesMax au nombre maximum de requêtes
qu'Apache peut traiter par connexion persistante. Une
limitation est imposée pour éviter qu'un client
ne vienne asphyxier votre serveur en ressources. Mettre un
0 pour désactiver ce support. A partir de
la version 1.2, ceci est contrôlé par la directive
MaxKeepAliveRequests
KeepAliveTimeout 15Le nombre de secondes pendant lesquelles Apache attendra une requête postérieure avant de rompre une connexion. Dès qu'une requête est reçue, la valeur de la temporisation spécifiée par la directive Timeout s'applique.
Mettre KeepAliveTimeout à une grande
valeur peut créer des problèmes de performance
pour des serveurs chargés. Le plus grand est ce
délai, le plus les processus du serveur seront
occupés en attente de connexions avec des clients
inactifs.
Les contrôles d'accès sont normalement actives
pour toutes les méthodes
d'accès, et ceci est le comportement normal. En
général, les directives de contrôle
d'accès ne doivent être placées à
l'intérieur d'une section
<limit>.
Le but de la directive <Limit> est de restreindre la portée des contrôles d'accès à certaines méthodes HTTP. Pour toutes les autres méthodes, les restrictions d'accès qui sont situées à l'intérieur de <Limit> sont sans effets. L'exemple suivant applique le contrôle d'accès uniquement aux méthodes POST, PUT, and DELETE, laissant les autres méthodes non protégées :
<Limit POST PUT DELETE>
Require valid-user
</Limit>
Les noms de méthodes peuvent être choisis parmi
GET, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH,
PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, et UNLOCK.
Le nom de la méthode est sensible à la
casse. Si GET est employé, il restreindra
également les requêtes HEAD.
<LimitExcept> et </LimitExcept> sont employés pour entourer un groupe de directives de contrôle d'accès qui s'appliqueront pour n'importe quelle méthode d'accès ne se trouvant pas en arguments Cette directive est l'oppsée de <Limit> et peut être employée pour contrôler les méthodes non reconnues ou non standard. Voir la documentation de <Limit> pour plus de détails.
LimitRequestBody 0Cette directive détermine la taille maximale en
octets que peut avoir le corps d'une requête. Elle peut
aller de 0 (illimité) à 2147483647 (2GB). La
valeur par défaut est déterminée à
la compilation par la constante
DEFAULT_LIMIT_REQUEST_BODY (0 dans les
distributions).
La directive LimitRequestBody directive permet à l'utilisateur de fixer une limite à la taille du corps d'une requête à l'intérieur du contexte où cette directive est située (serveur, par répertoire, par fichier). Si le client effezctue une requête excédant cette limite, le serveur retournera un message d'erreur au lieu de traiter la requête. La taille d'une requête normale peut beaucoup varier en fonction de la nature de la ressource demandée et des méthodes d'accès permise sur cette ressource. Typiquement les scripts CGI utilise le corps du message pour passer des informations au serveur. Des implémentation de la méthode PUT nécessite une valeur au moins aussi grande que le serveur souhaite recevoir pour cette ressource.
Cette directive donne à l'administrateur un plus grand contrôle par rapport à des requêtes anormales de clients, et peut être utile pour éviter certaines formes d'attaques par déni de service.
LimitRequestFields 100Number est un entier allant de 0 (signifiant sans
limite) à 32767. La valeur par défaut est
définie à la compilation par la constante
DEFAULT_LIMIT_REQUEST_FIELDS (100 dans la
distribution).
La directive LimitRequestFields permet à l'administrateur du serveur de modifier le nombre maximum de champs autorisé à l'intérieur de l'en-tête d'une requête HTTP. Un serveur doit avoir cette valeur supérieure au nombre de champs qu'un client normal peut inclure. Le nombre de champs utilisé par un client excède rarement 20, mais ceci peut varier en fonction de l'implémentation des clients, le plus souvent il dépend du niveau auquel le client a configuré son butineur pour accepter une négociation de contenu très fine. Les extensions HTTP optionnelles sont exprimées en utilisant des champs dans l'en-tête de requête.
Cette directive permet à l'administrateur un meilleur contrôle par rapport à des requêtes anormales, ce qui peut être utile pour éviter certaines attaques par déni de service. Cette valeur doit être augmentée si certains clients obtiennent un message d'erreur à leurs requêtes indiquant que trop de champs sont envoyés dans la requête.
LimitRequestFieldsize 8190Cette directive indique la taille maximale de
l'en-tête d'une requête HTTP et peut aller de 0
octets à la valeur définit à la
compilation par la constante
DEFAULT_LIMIT_REQUEST_FIELDSIZE (8190 dans la
distribution standard).
La directive LimitRequestFieldsize permet à l'administrateur de limiter la taille autorisée pour le champ d'en-tête HTTP d'une requête à une valeur inférieure à celle définie à la compilation. Un serveur doit avoir cette valeur suffisamment grande pour pouvoir traiter les requêtes de clients normaux. La taille d'une requête noramle peut beaucoup varier en fonction de l'implémentation du client, le plus souvent il dépend du niveau auquel le client a configuré son butineur pour accepter une négociation de contenu très fine.
Cette directive permet l'administrateur d'avoir un meilleur contrôle sur des requêtes ayant un comportement anormale, ce qui peut être utile afin d'éviter certaines formes d'attaques par déni de service. Dans des conditions normales, cette valeur doit rester celle par défaut.
LimitRequestLine 8190Cette directive indique la taille maximale d'une
requête HTTP et peut aller de 0 octets à
la valeur définit à la compilation par la
constante DEFAULT_LIMIT_REQUEST_LINE (8190 dans la
distribution standard).
La directive LimitRequestLine permet à l'administrateur de réduire la limite fixée pour une requête HTTP en dessous de la valeur fixée à la compilation. Comme une requête est composée de la méthode HTTP, d'une URI et de la version du protocole utilisé, la directive LimitRequestLine place une restriction sur la taille maximale que peut avoir une URI dansune requête. Un serveur doit avoir cette valeur suffisamment grande pour pouvoir traiter n'importe quelle de ses ressources, en prenant en compte les informations qui pourrait être passées dans une requête GET.
Cette directive permet l'administrateur d'avoir un meilleur contrôle sur des requêtes ayant un comportement anormale, ce qui peut être utile afin d'éviter certaines formes d'attaques par déni de service. Dans des conditions normales, cette valeur doit rester celle par défaut.
La directive Listen enjoint Apache à écouter plus d'une adresse IP ou port; par défaut Apache répond aux requêtes reçues sur toutes les interfaces IP, mais seulement celles arrivant sur le port donné par la directive Port.
Listen peut être utilisée à la place de BindAddress et Port. Elle indique au serveur d'accepter des requêtes entrantes sur le port spécifié ou sur une combinaison adresse-port. Si le premier format est utilisé (avec seule mention d'un numéro de port), le serveur "écoutera" tous les ports spécifiés sur chacune des interfaces IP qu'il connaît, plutôt que sur le port donné par la directive Port. Si une adresse IP adresse IP est précisée en complément, le serveur restreindra son écoute à la combinaison adresse-port précisée.Notez que vous avez toujours besoin de la directive Port qui permettent à Apache de générer les URL de retour vers votre serveur.
Plusieurs directives Listen peuvent être utilisées pour spécifier un ensemble d'adresses et de ports à écouter. Le serveur répondra aux requêtes reçues sur n'importe laquelle des combinaisons adresse-port ainsi spécifiée.
Par exemple, pour autoriser le serveur à accepter des connexions sur les ports 80 et 8000, écrire :
Listen 80 Listen 8000
Pour autoriser un serveur à accepter des connexions sur deux "sockets" qualifiés, écrire :
Listen 192.170.2.1:80 Listen 192.170.2.5:8000
Voir aussi: Apache et DNS
Voir aussi: Configurer
les ports et adresses utilisée par Apache
Voir aussi : Bogues
connus
ListenBacklog 511La longueur maximale de la file d'attente des connexions en
attente. En général, aucun ajustement n'est
nécessaire, cependant, il est souhaitable sur certains
systèmes d'augmenter cette longueur de file pour
répondre à des attaques TCP SYN. Voir les
paramètres backlog dans l'appel système
listen(2).
Cette directive est limitée à un petit nombre par le système d'exploitation. Elle peut varier d'un système à un autre. Il faut également noter que pour la plupart des systèmes, la valeur réellement utilisée n'est pas celle spécifiée par la directive, mais un nombre basé sur cette valeur (généralement plus grande).
La directive <Location> permet d'instaurer un
contrôle d'accès sur une base URL. Elle est
comparable à la directive <Directory>, et doit s'apparier
à une directive </Location>. Les
directives s'appliquant à l'URL précisée
seront à inclure entre ces deux balises. Les sections
<Location> sont traitées dans l'ordre
où elles apparaissent dans le fichier de configuration,
une fois les sections <Directory> et les
fichiers .htaccess traités.
Il faut noter que les URL n'ont pas du tout à suivre la même organisation que le système de fichiers, et il faut souligner que la directive <Location> opère de manière totalement indépendante du système de fichiers.
Le préfixe d'URL devra, sauf pour des
requêtes à un proxy, être de la forme
/chemin/, et ne devra pas inclure de mention
http://nomserveur. Elle ne protège pas
nécessairement un répertoire (cela peut
être un fichier individuel, ou un ensemble de fichiers),
et peut inclure des métacaractères. Dans un motif
(avec des métacaractères), '?' remplace un
caractère quelconque, et '*' remplace toute chaîne
quelconque de 0 ou plus caractères. POur les
requêtes à un proxy, l'URL doitt être de la
forme scheme://nomserveur/serveur, et vous devez
inclure le préfixe.
Apache 1.2 et plus : Des expression
régulières peuvent être utilisées,
à condition de les faire précéder du
caractère ~. Par exemple :
<Location ~ "/(extra|special)/data">
correspondrait à des URL contenant la sous-chaîne "/extra/data" ou "/special/data". Cependant, sous Apache 1.3, l'utilisation de la directive <LocationMatch> est conseillée.
La fonctionnalité Location est particulièrement pratique lorsque combinée à la directive SetHandler. Par exemple, pour permettre des requêtes sur les rapports d'état, mais ne les autoriser que pour des agents requérant à partir du domaine foo.com, vous pourriez écrire :
<Location /status> SetHandler server-status order deny,allow deny from all allow from .foo.com </Location>
Note sur / (barre oblique) pour les version
supérieures à 1.3: La caractère
barre oblique à une signification particulière en
fonction de l'endroit où il se situe. Des personnes sont
habitués au comportement dans certains systèmes
de fichiers où de multiples caractères obliques
sont remplacés par un caractère unique (par
exemple /home///foo est identique à
/home/foo). Dans le monde des URL ceci n'est pas
obligatoirement vrai. La directive
<LocationMatch> et la version avec
expression régulière de
<Location> demande de spécifier
plusieurs caractères obliques si ceci est votre
intention. Par exemple, <LocationMatch
^/abc> fonctionnera avec l'URL /abc mais
pas avec l'URL //abc. La directive (sans
expression régulière)
<Location> se comporte de manière
similaire quand elle est employée pour des
requêtes proxy. Mais si la directive (sans expression
régulière) <Location> est
utilisée pour des requêtes sans proxy, il
associera implicitement plusieurs obliques à un seul.
Par exemple, si vous spécifiez <Location
/abc/def> et que la requête est
/abc//def celle ci correspondra.
Voir aussi: Comment fonctionnent les sections concernant les répertoires, chemins et fichiers pour une explication plus précise concernant la manière dont ces sections sont combinées lorsqu'une requête est traitée.
La directive <LocationMatch> permet l'établissement d'un contrôle d'accès sur une base URL, d'une façon identique à la directive <Location>. Cependant, elle n'accepte qu'une expression régulière comme argument. Par exemple :
<LocationMatch "/(extra|special)/data">
représente des URL contenant l'une des
sous-chaînes "/extra/data" ou "/special/data". LockFile
logs/accept.lockLa directive LockFile indique le chemin
d'accès du fichier de verrouillage utilisé
lorsqu'Apache est compilé en mode
USE_FCNTL_SERIALIZED_ACCEPT ou
USE_FLOCK_SERIALIZED_ACCEPT. Ce paramètre
sera laissé généralement dans son
état par défaut. La raison principale qui
conduirait à modifier ce paramètre serait le fait
que le répertoire des traces (logs) soit
monté sous NFS, le fichier de verrouillage devant de
préférence être situé sur un disque
local à la machine serveur pour autant que possible. Le
PID du processus serveur principal est automatiquement
rajouté au nom de fichier.
SECURITE : il vaut mieux éviter de
metttre ce fichier dans un répertoire inscriptible par
tout le monde tel que /var/tmp cas quelqu'un
pourrait créer une attaque par déni de service et
empécher le serveur de redémarrer en
créant un fichier de verrouillage de même nom que
celui que veut créer le serveur.
LogLevel
errorLogLevel ajuste le niveau de verbosité des messages inscrits dans les traces d'erreur (voir la directive ErrorLog). Les niveaux possibles sont par ordre de gravité décroissante :
| Niveau | Description |
|---|---|
| Exemple | |
emerg |
Urgences - le système est inutilisable. |
| "Child cannot open lock file. Exiting" | |
alert |
Une action doit être prise immédiatement. |
| "getpwuid: couldn't determine user name from uid" | |
crit |
Conditions critiques. |
| "socket: Failed to get a socket, exiting child" | |
error |
Cas d'erreur. |
| "Premature end of script headers" | |
warn |
Avertissements. |
| "child process 1234 did not exit, sending another SIGHUP" | |
notice |
Normal mais condition significative. |
| "httpd: caught SIGBUS, attempting to dump core in ..." | |
info |
Pour information. |
| "Server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers)..." | |
debug |
Messages de déboguage |
| "Opening config file ..." |
Quand un niveau est spécifié, les messages des
niveaux de plus haute gravité seront également
rapportés. Par exemple, quand la directive
LogLevel info est définie, les messages de
niveau notice et warn seront aussi
notifiés.
L'utilisation d'un niveau de gravité d'au moins
crit est recommandé.
MaxClients 256La directive MaxClients indique le nombre limite de requêtes simultanées pouvant être acceptées par le serveur ; il représente le nombre maximum de processus serveur fils qui peuvent tourner à un instant donné. Pour configurer plus de 256 clients, vous devez modifier la constante HARD_SERVER_LIMIT du fichier source d'Apache httpd.h et recompiler Apache.
Les tentatives de connexions au delà de MaxClients sont normalement mises en attente, jusqu'à une limite fixée par la directive ListenBacklog. Une fois qu'un processus fils est libre à la fin d'une requête différente, la connexion en attente est traitée.
MaxKeepAliveRequests 100La directive MaxKeepAliveRequests limite le nombre
de requêtes permises pour une connexion unique lorsque la
directive KeepAlive est
activée. Si nombre vaut "0",
chaque connexion peut admettre un nombre illimité de
requêtes. Nous recommendons que ce paramètre soit
réglé sur une valeur relativement haute pour
obtenir des performances optimales du serveur. Dans la version
1.1 d'Apache, ceci est contrôlé par la directive
Keepalive
MaxRequestsPerChild 0La directive MaxRequestsPerChild indique le nombre limite de requêtes qu'un processus serveur fils peut traîter. Après MaxRequestsPerChild requêtes, ce processus fils meurt. Si ce paramètre est fixé à 0, alors les processus fils ne meurent jamais.
Le fait de mettre MaxRequestsPerChild à une valeur non nulle a deux conséquences bénéfiques :
Cependant sur les systèmes Win32, il est recommandé de mettre cette valeur à 0. Si celle ci est à une valeur non nulle, quand le nombre de requêtes est atteint, le processus fils quitte, et est relancé en relisant les fichiers de configuration. Ceci peut conduire à un comportement imprévisible si vous avez modifié un fichier de configuration, mais ne souhaitez pas que ces changements soient pris en compte. Voir également ThreadsPerChild.
NOTE: pour les requêtes KeepAlive requests, seule la première requête est comptée. En réalité, il change le comportement afin de limiter le nombre de connexions par fils.
MaxSpareServers 10La directive MaxSpareServers indique le nombre maximal de processus fils en attente. Un processus en attente est un processus qui existe, mais qui ne traite pas de requête. S'il existe plus de MaxSpareServers de ces processus, alors le père viendra tuer les processus en supplémentaires.
L'activation de cette fonctionnalité ne devrait être nécessaire que sur les site vraiment très chargés. Régler ce paramètre sur une grande valeur est de toutes façon toujours une mauvaise idée.
Cette directive n'a aucun effet quand elle est employée sur les plates-formes WIndows.
Voir aussi MinSpareServers et StartServers.
MinSpareServers 5La directive MinSpareServers indique le nombre minimum de processus fils en attente qu'un serveur pourra conserver. S'il existe moins de MinSpareServers processus serveurs fils en attente, le processus père recréera des processus fils au rythme de 1 par seconde.
L'activation de cette fonctionnalité ne devrait être nécessaire que sur des sites très chargés. Régler ce paramètre sur une grande valeur est de toutes façons toujours une mauvaise idée.
Cette directive n'a aucun effet quand elle est employée sur les plates-formes WIndows.
Voir aussi MaxSpareServers et StartServers.
La directive NameVirtualHost est nécessaire si vous souhaitez configurer des hôtes virtuels nommés.
Bien que addr puisse être exprimée comme un nom d'hôte, il est recommandé d'utiliser une adresse IP, exemple :
NameVirtualHost 111.22.33.44
Avec cette directive NameVirtualHost, l'adresse nommée par le nom de votre hôte virtuel se résout. Si vous exploitez plusieurs hôtes nommés sur des adresses multiples, répétez cette directive autant de fois que nécessaire (pour chaque adresse).
Note: le "serveur principal" et tous les serveurs "par défaut" ne seront jamais servis pour une requête vers une adresse IP NameVirtualHost (à moins que pour une raison donnée vous définissiez NameVirtualHost mais qu'aucun VirtualHosts ne soit défini pour cette adresse).
En option, vous pouvez préciser un numéro de port sur lequel l'hôte virtuel nommé sera atteint, par exemple :
NameVirtualHost 111.22.33.44:8080
A partir de la version 1.3.13, vous pouvez donner comme adresse
* Ceci crée un NameVirtualHost qui
correspond à toutes les connexions venant de toutes les
adresses IP qui ne sont pas configurés avec une autre
directive NameVirtualHost ou un section <VirtualHost>. Cette option est
pratique si vous n'utilisez que des hôtes virtuels
nommés et que vous ne souhaitez pas coder en dur
l'adresse IP de votre machine dans le fichier de
configuration.La directive Options contrôle quelles fonctions du serveur sont disponibles dans un répertoire particulier.
option peut valoir None, auquel cas
aucune fonction supplémentaire n'est disponible, ou une
ou plus des possibilités suivantes :
Note: même si le serveur suit le lien symbolique, il ne doit pas changer le chemin d'accès afin de ne pas entrer en contradiction avec les sections <Directory>.
#include des scripts CGI.MultiViews est
permis.Normalement, si plusieurs options Options
peuvent être appliquées à un
répertoire, alors la plus restrictive est
appliquée ; les options ne sont pas combinées.
Cependant, si all les options dans la directive
Options sontprécédées d'un
symbole + ou -, alors les options sont alors combinées
entre elles. Toute option précédée d'un +
est ajoutée aux options en cours, toute option
précédée d'un - est
désactivée.
Par exemple, sans symboles + ni - :
<Directory /web/docs> Options Indexes FollowSymLinks </Directory> <Directory /web/docs/spec> Options Includes </Directory>
seul Includes sera activé pour le
répertoire /web/docs/spec. Cependant, si la
seconde directive d'Options utilise les symboles +
et - :
<Directory /web/docs> Options Indexes FollowSymLinks </Directory> <Directory /web/docs/spec> Options +Includes -Indexes </Directory>
alors les options FollowSymLinks et
Includes sont validées pour le
répertoire /web/docs/spec.
PidFile
logs/httpd.pidLa directive PidFile définit le fichier dans lequel le serveur enregistre l'identificateur de processus du démon. Si le nom de fichier ne commence pas par un slash (/) alors le fichier est défini relativement au ServerRoot. Le fichier PidFile n'est utilisé que dans le mode standalone.
Il est souvent utile de pouvoir envoyer un signal au serveur, pour qu'il referme et réouvre ses fichiers ErrorLog et TransferLog, et relise ses fichiers de configuration. Ceci peut être fait en envoyant un signal SIGHUP (kill -1) au processus identifié par l'identificateur de processus marqué dans PidFile.
Le fichier PidFile est concerné par les mêmes problèmes d'emplacement et de securité que les fichiers de trace.
Port
80numéro est un nombre compris entre 0 et
65535; certains numéros de ports (surtout en dessous de
1024) sont réservés pour des protocoles
spécifiques. Une liste des ports
prédéfinis est consultable dans la RFC 1340
"Assigned Numbers" /etc/services; le port standard
assigné au protocole http est le port 80.
La directive Port a deux comportements, le premier est nécessaire pour assurer la compatibilité NCSA (et qui peut préter à confusion dans le contexte d'Apache).
:numéro alors la directive Port n'a aucun
effet quant au socket que le serveur écoute.SERVER_PORT (pour les CGI et les SSI), laquelle est
utilisée lorsque le serveur génère une
URL qui point sur lui-même (par exemple lorsqu'il
indique une indirection externe vers lui-même).Dans aucun cas une définition du Port ne définit à quel port un VirtualHost répond, la directive VirtualHost elle-même se chargeant de cette définition.
Le comportement premier de la directive Port doit être considéré comme similaire à celui de la directive ServerName. ServerName et Port spécifient conjointement ce que vous considérez être l'adresse canonique du serveur.
Le Port 80 est l'un des ports prédéfinis
d'Unix. Tous les ports numérotés en dessous de
1024 sont réservés à un usage
système, c-à-d. que des utilisateurs non
privilégiés (non-root) ne peuvent les utiliser ;
ces derniers peuvent par contre utiliser des ports de plus haut
rang. Pour utiliser le port 80, le serveur doit être
exécuté sous root. Après
avoir lié le port (bind) et avant d'accepter des
requêtes, Apache changera son utilisateur associé
tel que défini par la directive User.
Si vous ne pouvez utiliser le port 80, choisissez tout autre port libre. Les utilisateurs non-root devront choisir un numéro de port supérieur à 1023, 8000 par exemple.
Sécurité : si vous
démarrez le serveur sous root, assurez vous
que la directive User ne mentionne pas
root. Si vous traitez des requêtes en
disposant toujours de super privilèges, vous ouvrez
votre système à des attaques majeures.
Cette directive choisi quels utilisateurs autorisés peuvent accéder à un répertoire. Les syntaxes valides sont :
Seuls les utilisateurs nommés peuvent accéder au répertoire.
Seuls les utilisateurs des groupes cités peuvent accéder au répertoire.
Tout utilisateur reconnu peut accéder au répertoire (par opposition aux non utilisateurs).
Si require apparaît dans une section <Limi