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

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.

| Modules Apparentés | Directives Apparentées | |---|---|

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

Par exemple, si la directive

contient DocumentRoot/var/www/html

, une requête pour http://www.example.com/fish/guppies.html

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

. Par exemple, supposons que DirectoryIndexDocumentRoot

ait été définie comme précédemment, et que vous ayez défini DirectoryIndex

Si httpd reçoit alors une requête pour http://www.example.com/fish/

Si aucun de ces fichiers existe, httpd tentera de générer et d'afficher un index du répertoire, à condition que

ait été chargé et configuré pour le permettre.mod_autoindex

httpd supporte aussi les Hôtes virtuels, ce qui lui permet de traiter des requêtes pour plusieurs hôtes. Dans ce cas, un

différent peut être défini pour chaque hôte virtuel; les directives fournies par le module DocumentRoot

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

est définie dans le fichier de configuration de votre serveur principal (DocumentRootapache2.conf

), mais peut aussi être redéfinie pour chaque Hôte virtuel supplémentaire que vous avez créé.

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

pour le répertoire concerné contiennent OptionsFollowSymLinks

pour rattacher toute portion du système de fichiers à l'arborescence du site web. Par exemple, avecAlias

Alias /docs /var/web

fonctionne de la même manière, excepté que tout contenu localisé dans le chemin cible sera traité comme un script ScriptAliasCGI.

Pour les situations qui nécessitent plus de flexibilité, vous disposez des directives

qui permettent des substitutions et comparaisons puissantes basées sur les ScriptAliasMatchexpressions 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

, et traitera le fichier résultant comme un script CGI.

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

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 UserDirUserdir public_html

, l'URL ci-dessus correspondra à un fichier dont le chemin sera du style /home/user/public_html/file.html

met à votre disposition de nombreuses formes différentes pour les systèmes où /etc/passwd

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

pour obtenir l'effet désiré. Par exemple, pour faire correspondre AliasMatchhttp://www.example.com/upages/user/file.html

, utilisez la directive AliasMatch

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

est déplacé vers le nouveau répertoire DocumentRoot/bar/

, vous pouvez demander aux clients de le requérir à sa nouvelle localisation comme suit :

Ceci aura pour effet de rediriger tout chemin d'URL commençant par /foo/

. Vous pouvez rediriger les clients non seulement sur le serveur d'origine, mais aussi vers n'importe quel autre serveur.

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

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

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/

et les renvoie au client comme s'ils appartenaient au serveur local.

ProxyPassReverse /foo/ http://internal.example.com/bar/

ProxyPassReverseCookieDomain internal.example.com public.example.com

configure le serveur pour rapatrier les documents appropriés, alors que la directive ProxyPass

réécrit les redirections provenant de ProxyPassReverseinternal.example.com

de telle manière qu'elles ciblent le répertoire approprié sur le serveur local. De manière similaire, les directives

réécrivent les cookies élaborés par le serveur d'arrière-plan.ProxyPassReverseCookiePath

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

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

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, modrewrite 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 modrewrite sont discutés dans la modrewritedocumentation détaillée de modrewrite.

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

(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é, modspeling 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.modspeling

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

fournit la directive mod_dir

qui permet d'associer des URIs virtuels à une ressource réelle qui peut ainsi les servir. Cette directive remplace avantageusement FallbackResource

lors de l'implémentation d'un "contrôleur frontal".mod_rewrite

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

et peut être personnalisée de manière très flexible comme discuté dans le document ErrorDocumentRéponses personnalisées aux erreurs.

- Permet une mise en correspondance basique d'un slash terminal dans un fichier index comme index.html

- Met en correspondance une requête avec une URL en fonction de la zone d'une image intégrée à un document HTML dans laquelle un utilisateur clique.mod_negotiation

- Sélectionne le document approprié en fonction de préférences du client telles que la langue ou la compression du contenu.

Modules | Directives | FAQ | Glossaire | Plan du site

Serveur Apache HTTP Version 2.4