httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Couvreur <n_b_a_...@hotmail.fr>
Subject Mapping URLs to the Filesystem : french translation
Date Thu, 15 May 2008 14:51:03 GMT

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


Mime
View raw message