<-
Apache > Serveur HTTP > Documentation > Version 2.4

Mise en correspondance des URLs avec le syst�me de fichiers

Langues Disponibles:  en  |  fr  |  ja  |  ko  |  tr 

Ce document explique comment le serveur HTTP 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.

Voir aussi

top

Modules et directives concern�s

top

Racine des documents (DocumentRoot)

La m�thode par d�faut de httpd 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.

Si la requ�te concerne un r�pertoire (autrement dit un chemin se terminant par un slash /), le nom du fichier qui sera recherch� et servi depuis ce r�pertoire est d�fini via la directive DirectoryIndex. Par exemple, supposons que DocumentRoot ait �t� d�finie comme pr�c�demment, et que vous ayez d�fini DirectoryIndex comme suit :

DirectoryIndex index.html index.php

Si httpd re�oit alors une requ�te pour http://www.example.com/fish/, il tentera de servir le fichier /var/www/html/fish/index.html. Si ce fichier n'existe pas, il tentera de servir le fichier /var/www/html/fish/index.php.

Si aucun de ces fichiers existe, httpd tentera de g�n�rer et d'afficher un index du r�pertoire, � condition que mod_autoindex ait �t� charg� et configur� pour le permettre.

httpd 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 (apache2.conf), mais peut aussi �tre red�finie pour chaque H�te virtuel suppl�mentaire que vous avez cr��.

top

Fichiers situ�s en dehors de l'arborescence DocumentRoot

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. httpd 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�, httpd 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.

top

R�pertoires des utilisateurs

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/$3"
top

Redirection d'URL

Les directives de configuration d�crites dans les sections pr�c�dentes demandent � httpd 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.

httpd 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"
top

Mandataire inverse (Reverse Proxy)

httpd 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 mandataire usuel (direct) 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. Vous pouvez modifier ces liens (et d'utres contenus) situ�s dans la page au moment o� elle est envoy�e au client en utilisant le module mod_substitute.

Substitute "s/internal\.example\.com/www.example.com/i"

Le module mod_proxy_html rend possible une r��criture plus �labor�e des liens en HTML et XHTML. Il permet de cr�er des listes d'URLs et de leurs r��critures, de fa�on � pouvoir g�rer des sc�narios de r��criture complexes.

top

Moteur de r��criture

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 peuvent utiliser 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 la documentation d�taill�e de mod_rewrite.

top

Fichier non trouv� (File Not Found)

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

mod_dir fournit la directive FallbackResource qui permet d'associer des URIs virtuels � une ressource r�elle qui peut ainsi les servir. Cette directive remplace avantageusement mod_rewrite lors de l'impl�mentation d'un "contr�leur frontal".

Si toutes les tentatives pour localiser le contenu �chouent, httpd 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.

top

Autres modules de mise en correspondance des URLs

Les autres modules disponibles pour la mise en correspondance des URLs sont :

Langues Disponibles:  en  |  fr  |  ja  |  ko  |  tr 

top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.