Serveur Apache HTTP Version 2.3
Serveur Apache HTTP Version 2.3
Ce document explique comment Apache utilise l'URL contenue dans une requête pour déterminer le noeud du système de fichier à partir duquel le fichier devra être servi.
| Modules Apparentés | Directives Apparentées |
|---|---|
La méthode par défaut d'Apache pour déterminer quel fichier servir pour
une requête donnée, consiste à extraire le chemin du fichier de la requête
(la partie de l'URL qui suit le nom d'hôte et le port), puis de l'ajouter
à la fin de la valeur de la directive
DocumentRoot définie dans vos fichiers
de configuration.
Ainsi, les fichiers et répertoires
situés en dessous de DocumentRoot
constituent l'arborescence de base des documents qui seront visibles
depuis le web.
Par exemple, si la directive
DocumentRoot contient
/var/www/html, une requête pour
http://www.example.com/fish/guppies.html retournera le
fichier /var/www/html/fish/guppies.html au client.
Apache supporte aussi les Hôtes virtuels,
ce qui lui permet de traiter des requêtes pour plusieurs hôtes.
Dans ce cas, un DocumentRoot
différent peut être défini pour chaque hôte virtuel;
les directives fournies par le module
mod_vhost_alias peuvent aussi être utilisées afin de
déterminer dynamiquement le noeud approprié du système de fichiers
à partir duquel servir un contenu en fonction de l'adresse IP
ou du nom d'hôte.
La directive DocumentRoot est
définie dans le fichier de configuration de votre serveur principal
(httpd.conf), mais peut aussi être redéfinie pour chaque
Hôte virtuel supplémentaire que vous avez créé.
Il existe de nombreuses circonstances pour lesquelles il est nécessaire
d'autoriser l'accès web à des portions du système de fichiers qui ne se
trouvent pas dans l'arborescence DocumentRoot. Apache propose de nombreuses
solutions pour réaliser cela. Sur les systèmes Unix, les liens
symboliques permettent de rattacher d'autres portions du système de
fichiers au DocumentRoot. Pour des raisons de sécurité,
Apache ne suivra les liens symboliques que si les Options pour le répertoire concerné contiennent
FollowSymLinks ou SymLinksIfOwnerMatch.
Une autre méthode consiste à utiliser la directive Alias pour rattacher toute portion
du système de fichiers à l'arborescence du site web. Par exemple, avec
Alias /docs /var/web
l'URL http://www.example.com/docs/dir/file.html
correspondra au fichier /var/web/dir/file.html. La
directive
ScriptAlias
fonctionne de la même manière, excepté que tout contenu localisé dans le
chemin cible sera traité comme un script CGI.
Pour les situations qui nécessitent plus de flexibilité, vous disposez
des directives AliasMatch
et ScriptAliasMatch
qui permettent des substitutions et comparaisons puissantes basées
sur les expressions rationnelles.
Par exemple,
ScriptAliasMatch ^/~([a-zA-Z0-9]+)/cgi-bin/(.+)
/home/$1/cgi-bin/$2
fera correspondre une requête du style
http://example.com/~user/cgi-bin/script.cgi au chemin
/home/user/cgi-bin/script.cgi, et traitera le fichier résultant
comme un script CGI.
Sur les systèmes Unix, on peut traditionnellement faire référence
au répertoire personnel d'un utilisateur particulier à l'aide de
l'expression ~user/.
Le module mod_userdir
étend cette idée au web en autorisant l'accès aux fichiers situés dans les
répertoires home des utilisateurs à l'aide d'URLs
comme dans ce qui suit :
http://www.example.com/~user/file.html
Pour des raisons de sécurité, il est déconseillé de permettre un accès
direct à un répertoire home d'utilisateur depuis le web. A cet effet, la
directive UserDir
spécifie un répertoire où sont situés les fichiers accessibles depuis le web
dans le répertoire home de l'utilisateur.
Avec la configuration par défaut
Userdir public_html, l'URL ci-dessus correspondra à un fichier
dont le chemin sera du style
/home/user/public_html/file.html où
/home/user/ est le répertoire home de l'utilisateur tel qu'il
est défini dans /etc/passwd.
La directive Userdir met à votre disposition de nombreuses
formes différentes pour les systèmes où /etc/passwd ne
spécifie pas la localisation du répertoire home.
Certains jugent le symbole "~" (dont le code sur le web est souvent
%7e) inapproprié et préfèrent utiliser une chaîne de
caractères différente pour représenter les répertoires utilisateurs.
mod_userdir ne supporte pas cette fonctionnalité. Cependant, si les
répertoires home des utilisateurs sont structurés de manière rationnelle,
il est possible d'utiliser la directive
AliasMatch
pour obtenir l'effet désiré. Par exemple, pour faire correspondre
http://www.example.com/upages/user/file.html à
/home/user/public_html/file.html, utilisez la directive
AliasMatch suivante :
AliasMatch ^/upages/([a-zA-Z0-9]+)/?(.*)
/home/$1/public_html/$2
Les directives de configuration décrites dans les sections précédentes
demandent à Apache d'extraire un contenu depuis un emplacement spécifique
du système de fichiers
et de la retourner au client. Il est cependant parfois
souhaitable d'informer le
client que le contenu demandé est localisé à une URL différente, et de
demander au client d'élaborer une nouvelle requête avec la nouvelle URL.
Ce processus se nomme redirection et est implémenté par la
directive Redirect.
Par exemple, si le contenu du répertoire /foo/ sous
DocumentRoot est déplacé vers le
nouveau répertoire /bar/, vous pouvez demander aux clients
de le requérir à sa nouvelle localisation comme suit :
Redirect permanent /foo/ http://www.example.com/bar/
Ceci aura pour effet de rediriger tout chemin d'URL commençant par
/foo/ vers le même chemin d'URL sur le serveur
www.example.com en remplaçant /foo/ par
/bar/. Vous pouvez rediriger les clients non seulement sur le
serveur d'origine, mais aussi vers n'importe quel autre serveur.
Apache propose aussi la directive RedirectMatch pour traiter les problèmes
de réécriture d'une plus grande complexité. Par exemple, afin de rediriger
les requêtes pour la page d'accueil du site vers un site différent, mais
laisser toutes les autres requêtes inchangées, utilisez la
configuration suivante :
RedirectMatch permanent ^/$
http://www.example.com/startpage.html
De même, pour rediriger temporairement toutes les pages d'un site vers une page particulière d'un autre site, utilisez ce qui suit :
RedirectMatch temp .*
http://othersite.example.com/startpage.html
Apache vous permet aussi de rapatrier des documents distants dans l'espace des URL du serveur local. Cette technique est appelée mandataire inverse ou reverse proxying car le serveur web agit comme un serveur mandataire en rapatriant les documents depuis un serveur distant puis les renvoyant au client. Ceci diffère d'un service de proxy usuel car, pour le client, les documents semblent appartenir au serveur mandataire inverse.
Dans l'exemple suivant, quand les clients demandent des documents situés
dans le répertoire
/foo/, le serveur rapatrie ces documents depuis le répertoire
/bar/ sur internal.example.com
et les renvoie au client comme s'ils appartenaient au serveur local.
ProxyPass /foo/ http://internal.example.com/bar/
ProxyPassReverse /foo/ http://internal.example.com/bar/
ProxyPassReverseCookieDomain internal.example.com public.example.com
ProxyPassReverseCookiePath /foo/ /bar/
La directive ProxyPass configure
le serveur pour rapatrier les documents appropriés, alors que la directive
ProxyPassReverse
réécrit les redirections provenant de
internal.example.com de telle manière qu'elles ciblent le
répertoire approprié sur le serveur local. De manière similaire, les directives
ProxyPassReverseCookieDomain
et ProxyPassReverseCookiePath
réécrivent les cookies élaborés par le serveur d'arrière-plan.
Il est important de noter cependant, que les liens situés dans les documents
ne seront pas réécrits. Ainsi, tout lien absolu sur
internal.example.com fera décrocher le client
du serveur mandataire et effectuer sa requête directement sur
internal.example.com. Un module tiers
mod_proxy_html
permet de réécrire les liens dans les documents HTML et XHTML.
Le moteur de réécriture mod_rewrite peut s'avérer
utile lorsqu'une substitution plus puissante est nécessaire.
Les directives fournies par ce module utilisent des caractéristiques de la
requête comme le type de navigateur ou l'adresse IP source afin de décider
depuis où servir le contenu. En outre, mod_rewrite peut utiliser des
fichiers ou programmes de bases de données externes pour déterminer comment
traiter une requête. Le moteur de réécriture peut effectuer les trois types
de mise en correspondance discutés plus haut :
redirections internes (aliases), redirections externes, et services mandataires.
De nombreux exemples pratiques utilisant mod_rewrite sont discutés dans le
Guide de réécriture des URLs.
Inévitablement, apparaîtront des URLs qui ne correspondront à aucun fichier du système de fichiers. Ceci peut arriver pour de nombreuses raisons. Il peut s'agir du déplacement de documents d'une localisation vers une autre. Dans ce cas, le mieux est d'utiliser la redirection d'URL pour informer les clients de la nouvelle localisation de la ressource. De cette façon, vous êtes sur que les anciens signets et liens continueront de fonctionner, même si la ressource est déplacée.
Une autre cause fréquente d'erreurs "File Not Found" est l'erreur de
frappe accidentelle dans les URLs, soit directement dans le navigateur,
soit dans les liens HTML. Apache propose le module
mod_speling (sic) pour tenter de résoudre ce problème.
Lorsque ce module est activé, il intercepte les erreurs
"File Not Found" et recherche une ressource possédant un nom de fichier
similaire. Si un tel fichier est trouvé, mod_speling va envoyer une
redirection HTTP au client pour lui communiquer l'URL correcte.
Si plusieurs fichiers proches sont trouvés, une liste des alternatives
possibles sera présentée au client.
mod_speling possède une fonctionnalité particulièrement utile : il compare les noms de fichiers sans tenir compte de la casse. Ceci peut aider les systèmes où les utilisateurs ne connaissent pas la sensibilité des URLs à la casse et bien sûr les systèmes de fichiers unix. Mais l'utilisation de mod_speling pour toute autre chose que la correction occasionnelle d'URLs peut augmenter la charge du serveur, car chaque requête "incorrecte" entraîne une redirection d'URL et une nouvelle requête de la part du client.
Si toutes les tentatives pour localiser le contenu échouent, Apache
retourne une page d'erreur avec le code de statut HTTP 404
(file not found). L'apparence de cette page est contrôlée à l'aide de la
directive ErrorDocument
et peut être personnalisée de manière très flexible comme discuté dans le
document
Réponses personnalisées aux erreurs.
