Mapping URLs to the Filesystem : french translation

[Ivan Couvreur <n_...@hotmail.fr>]

Here's a french translation of "Mapping URLs to the Filesystem".
I don't exactly know how to submit it (in what format it should be), I let it in html.

To be more convenient, you can see it here : http://www.membres.lycos.fr/nbah/urlmapping.html





Correspondance des URL avec l'emplacement du système de fichiers - Apache HTTP Server





Modules | Directives | FAQ | Glossaire | Plan du Site
Apache HTTP Server Version 2.2



Apache > HTTP Server > Documentation > Version 2.2Correspondances des URL avec l'emplacement du système de fichiers

Langues disponibles :  en  |
 fr  |
 ja  |
 ko 


    Ce document explique comment Apache utilise  l'URL d'une requête pour déterminer l'emplacement du système de fichiers depuis lequel servir un fichier.
  
 Modules et Directives affairants
 DocumentRoot
 Fichiers hors du DocumentRoot
 Répertoires utilisateurs
 Redirection d'URL
 Proxy inverse
 Moteur de réécritutre
 Fichier introuvables



Modules et Directives affairants

Modules affairantsDirectives affairantesmod_aliasmod_proxymod_rewritemod_userdirmod_spelingmod_vhost_aliasAliasAliasMatchCheckSpellingDocumentRootErrorDocumentOptionsProxyPassProxyPassReverseProxyPassReverseCookieDomainProxyPassReverseCookiePathRedirectRedirectMatchRewriteCondRewriteMatchScriptAliasScriptAliasMatchUserDir


DocumentRoot 

    Pour décider quel fichier servir à une requête donnée, le comportement par défaut d'Apache est de prendre le chemin de l'URL en tant que requête (la partie de l'URL qui suit le nom d'hôte et le port), et de l'ajouter à la fin du DocumentRoot défini dans les fichiers de configuration. Ainsi, les fichiers et les répertoires en-dessous du DocumentRoot forme l'arborescence de base des documents qui seront visible depuis internet.

    Apache peut également faire du Virtual
    Hosting (hébergement virtuel), lorsque le serveur reçoit des requêtes pour plus d'un hôte. Dans ce cas, un DocumentRoot différent peut être défini pour chaque hôte virtuel. Il est également possible d'utiliser les directives fournies par le module mod_vhost_alias pour déterminer dynamiquement l'emplacement du contenu à servir, en se basant sur l'adresse IP ou le nom d'hôte.


Fichiers hors du DocumentRoot

    Il est fréquent de devoir autoriser l'accès depuis internet à quelque partie du système de fichiers, qui n'est pas directement sous le DocumentRoot. Apache offre plusieurs façons de remplir cette mission. Sur les systèmes UNIX, les liens symboliques peuvent porter d'autres parties du système de fichiers sous le DocumentRoot. Pour des raisons de sécurité, Apache ne suivra ces liens symboliques que si le paramètre d'Options pour le répertoire en question, inclut FollowSymLinks ou SymLinksIfOwnerMatch.

    Autrement, la directive Alias retranscrira n'importe quelle partie du système de fichiers dans l'espace internet. Par exemple, avec

Alias /docs /var/web

    l'URL http://www.example.com/docs/dir/file.html sera servi depuis /var/web/dir/file.html. La directive ScriptAlias fonctionne de la même façon, avec pour effet supplémentaire de traiter en tant que scripts CGI tout le contenu situé dans le chemin de la cible.

    Pour les cas où vous avez besoin de plus de flexibilité, vous pouvez utiliser les directives AliasMatch et ScriptAliasMatch pour faire des recherches et/ou des substitutions puissantes basées sur des expressions régulièresPar exemple,

ScriptAliasMatch ^/~([a-zA-Z0-9]+)/cgi-bin/(.+)
      /home/$1/cgi-bin/$2

    ce qui transcrira une requête vers 
    http://example.com/~user/cgi-bin/script.cgi vers le chemin /home/user/cgi-bin/script.cgi, et traitera le fichier trouvé comme un script CGI.


Répertoires utilisateur

    Traditionnellement sur les systèmes UNIX, on peut faire féférence au répertoire personnel d'un utilisateur en utilisant ~user/. Le module mod_userdir étend cette idée à internet en autorisant des fichiers sous le répertoire personnel de chaque utilisateur à être accessibles en utilisant des URL telle que

http://www.example.com/~user/file.html

    Pour des raisons de sécurité, il n'est pas approprié de donné un accès direct au répertoire personnel d'un utilisateur depuis internet. Ainsi, la directive UserDir définit un répertoire sous le répertoire personnel de l'utilisateur où sont rassemblées les fichiers internet.. En utilisant la configuration par défaut de Userdir public_html, l'URL ci-dessus transcrit un fichier dans le répertoire tel que /home/user/public_html/file.html où /home/user/ est le répertoire personnel de l'utilisateur tel que définit dans /etc/passwd.

    Il existe d'autres formes de la directive Userdir que vous pouvez utiliser avec des systèmes sur lesquels /etc/passwd ne contient pas le chemin du répertoire personnel des utilisateurs.

    Certaines personnes pensent que le symbole "~" (dont le code internet est %7e) est maladroit, et préfèrent utiliser un autre caractère pour représenter le répertoire personnel d'un utilisateur. Cette fonctionnalité n'est pas supportée par mod_userdir. Cependant, si les répertoires des utilisateurs sont structurés de la bonne manière, il est alors possible d'utiliser la directiveAliasMatch pour obtenir l'effet désiré. Par exemple, pour faire en sorte que
    http://www.example.com/upages/user/file.html corresponde à
    /home/user/public_html/file.html, utilisez la directive
    AliasMatch suivante :

AliasMatch ^/upages/([a-zA-Z0-9]+)/?(.*)
      /home/$1/public_html/$2


Redirection d'URL

    La configuration des directives dont nous avons parlé jusque là demande à Apache d'obtenir le contenu depuis un emplacement particulier, et de le renvoyer au client.
Parfois, il est préférable, à la place, d'informer le client que le contenu demandé est situé à une URL différente, et lui demander de formuler une nouvelle requête avec la nouvelle URL. Ceci est appelé redirection et est implété par la directive Redirect. Par exemple, si le contenu du répertoire /foo/ sous le DocumentRoot est déplacé dans le nouveau répertoire /bar/, vous pouvez dire aux clients de demander le contenu à un nouvel emplacement comme suit :

Redirect permanent /foo/
      http://www.example.com/bar/

    Cela va rediriger tous les chemins d'URL débutant par /foo/ vers le même chemin URL sur le serveur www.example.com, en substituant /bar/ à /foo/. Vous pouvez rediriger des clients vers n'importe quel serveur, pas seulement le serveur original.

    Apache fournit également une directive RedirectMatch pour simplifier les problèmes de réécriture. Par exemple, pour rediriger des requêtes pour une page d'accueil d'un serveur vers un site différent, en conservant les autres requêtes, usez de la configuration suivante :

RedirectMatch permanent ^/$
      http://www.example.com/startpage.html

    Sinon, pour rediriger temporairement toutes les pages d'un site vers une page d'un autre site, utilisez ce qui suit :

RedirectMatch temp .*
      http://othersite.example.com/startpage.html


Proxy inverse

Apache permet également de porter des documents distants dans l'espace URL du serveur local. Cette technique est appelé service mandataire inverse parceque le serveur web agit comme un serveur mandataire en allant chercher les documents sur un serveur distant, et en les retournant au client. Ce qui diffère d'un service mandataire normal en  ce que, pour le client, les documents semblent provenir du serveur mandataire inverse.

Dans l'exemple suivant, lorsque des clients demandent des documents sous le répertoire /foo/, le serveur va chercher ces documents dans le répertoire /bar/ sur internal.example.com et les retourne au client comme s'ils étaient sur le 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/


Le ProxyPassconfigure le serveur pour aller chercher les documents appropriés, alors que la directive ProxyPassReverseréécrit les redirections provenant deinternal.example.comde façon à ce qu'elles reprétent le répertoire approprié sur le serveur local. De la même manière, la directive ProxyPassReverseCookieDomain
and ProxyPassReverseCookiePathr&ecute;écrivent les cookies établis par le serveur final.
Il est important de noter, cependant, que les liens à l'intérieur des documents ne seront pas réécrits. Donc, tous les liens absolus sur internal.example.com provoqueront une rupture entre le serveur mandataire et le client, qui exétera ses requê directement sur internal.example.com.  Un module tiers mod_proxy_htmlest disponible afin de r&eacutre;écrire des liens en HTML et XHTML.



Moteur de réécriture

    Lorsqu'une substitution plus puissante est requise, le moteur de ré&eacutecriture fourni par mod_rewrite peut être utile. Les directives fournies par ce module utilise des caractéristiques de la requête telles que le type de navigateur ou l'adresse IP source en décidant d'où servir du contenu. Le moteur de réécriture est capable d'accomplir des trois types de correspondances présentées plus haut : redirections internes (alias), redirections externe, et service mandataire. De nombreux exemples concrets sont présentés dans le Guide de Réécriture d'URL.


File Not Found

    Inévitablement, des URL pour lesquelles il n'existe pas de fichier correspondant sur le système de fichiers seront demandées. Ceci peut arriver pour de multiples raisons. Dans certains cas, cela peutêtre le ré d'un fichier déplacé d'un endroit à un autre. Dans ce cas, il est préférable d'utiliser la Redirection d'URL pour informer les clients du nouvel emplavement de la ressource. De cette manière, vous pouvez être sûr que d'anciens signets et d'anciens liens continueront de fonctionner, bien que la ressource soit dans un nouvel emplacement.

    Une autre cause courante d'erreur "Fichier introuvable" est une faute de frappe accidentelle dans l'URL, que ce soit directement dans le navigateur, ou dans un lien HTML. Apache fournit le modulemod_speling (sic) pour résoudre ce problème. Quand ce module est activé, il intercepte les erreurs "Fichier introuvable" et cherche une ressource qui porte un nom similaire. Si un tel fichier est trouvé, 'mod_speling' enverra une redirection HTTP au client qui l'informera de l'emplacement correct. Si plusieurs fichiers "proches" sont trouvés, un e liste des alternatives disponibles seront affichées au client.

    Un caractéristique particulièrement utile de 'mod-speling', est qu'il va comparer les noms des fichiers sans respecter la casse. Ce qui peut aider lorsque les utilisateur ne connaissent pas la nature sensible à la casse des URL et du système de fichiers d'UNIX. Mais utiliser 'mod_speling' pour quoi que ce soit d'autre que la correction occasionnelle d'URL peut augmenter la charge du serveur, puisque chaque requête "incorrecte" est suivie par une redirection d'URL eet une nouvelle requête du client.

    Si toutes les tentatives pour localiser le contenu &ecute;houent, Apache retourne une page d'erreur portant le code d'état 404 (fichier introuvable). L'apparence de cette page est contrôlée par la directive ErrorDocument, et peut être personnalisée de manière souple telle que présentée dans le document Réponse personnalisée à une erreur.


Langues disponibles :  en  |
 fr  |
 ja  |
 ko 

Copyright 2008 The Apache Software Foundation.Sous licence Apache License, Version 2.0.
Modules | Directives | FAQ | Glossaire | Plan du Site


_________________________________________________________________
Retouchez, classez et partagez vos photos gratuitement avec le logiciel Galerie de Photos !
http://www.windowslive.fr/galerie/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org