mirror of
https://github.com/apache/httpd.git
synced 2025-11-03 17:53:20 +03:00
85829152b9
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@733287 13f79535-47bb-0310-9956-ffa450edef68
331 lines
18 KiB
Plaintext
331 lines
18 KiB
Plaintext
<?xml version="1.0" encoding="ISO-8859-1" ?>
|
|
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
|
|
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
|
|
<!-- French translation : Lucien GENTIS -->
|
|
<!-- Reviewed by : Vincent Deffontaines -->
|
|
<!-- English Revision: 732819 -->
|
|
|
|
<!--
|
|
Licensed to the Apache Software Foundation (ASF) under one or more
|
|
contributor license agreements. See the NOTICE file distributed with
|
|
this work for additional information regarding copyright ownership.
|
|
The ASF licenses this file to You under the Apache License, Version 2.0
|
|
(the "License"); you may not use this file except in compliance with
|
|
the License. You may obtain a copy of the License at
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
Unless required by applicable law or agreed to in writing, software
|
|
distributed under the License is distributed on an "AS IS" BASIS,
|
|
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
See the License for the specific language governing permissions and
|
|
limitations under the License.
|
|
-->
|
|
|
|
<manualpage metafile="urlmapping.xml.meta">
|
|
|
|
<title> Mise en correspondance des URLs avec le système de fichiers</title>
|
|
|
|
<summary>
|
|
<p>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.</p>
|
|
</summary>
|
|
|
|
<section id="related"><title>Modules et directives concernés</title>
|
|
|
|
<related>
|
|
<modulelist>
|
|
<module>mod_alias</module>
|
|
<module>mod_proxy</module>
|
|
<module>mod_rewrite</module>
|
|
<module>mod_userdir</module>
|
|
<module>mod_speling</module>
|
|
<module>mod_vhost_alias</module>
|
|
</modulelist>
|
|
<directivelist>
|
|
<directive module="mod_alias">Alias</directive>
|
|
<directive module="mod_alias">AliasMatch</directive>
|
|
<directive module="mod_speling">CheckSpelling</directive>
|
|
<directive module="core">DocumentRoot</directive>
|
|
<directive module="core">ErrorDocument</directive>
|
|
<directive module="core">Options</directive>
|
|
<directive module="mod_proxy">ProxyPass</directive>
|
|
<directive module="mod_proxy">ProxyPassReverse</directive>
|
|
<directive module="mod_proxy">ProxyPassReverseCookieDomain</directive>
|
|
<directive module="mod_proxy">ProxyPassReverseCookiePath</directive>
|
|
<directive module="mod_alias">Redirect</directive>
|
|
<directive module="mod_alias">RedirectMatch</directive>
|
|
<directive module="mod_rewrite">RewriteCond</directive>
|
|
<directive module="mod_rewrite">RewriteRule</directive>
|
|
<directive module="mod_alias">ScriptAlias</directive>
|
|
<directive module="mod_alias">ScriptAliasMatch</directive>
|
|
<directive module="mod_userdir">UserDir</directive>
|
|
</directivelist>
|
|
</related>
|
|
</section>
|
|
|
|
<section id="documentroot"><title>Racine des documents (DocumentRoot)</title>
|
|
|
|
<p>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
|
|
<directive module="core">DocumentRoot</directive> définie dans vos fichiers
|
|
de configuration.
|
|
Ainsi, les fichiers et répertoires
|
|
situés en dessous de <directive module="core">DocumentRoot</directive>
|
|
constituent l'arborescence de base des documents qui seront visibles
|
|
depuis le web.</p>
|
|
|
|
<p>Par exemple, si la directive
|
|
<directive module="core">DocumentRoot</directive> contient
|
|
<code>/var/www/html</code>, une requête pour
|
|
<code>http://www.example.com/fish/guppies.html</code> retournera le
|
|
fichier <code>/var/www/html/fish/guppies.html</code> au client.</p>
|
|
|
|
<p>Apache supporte aussi les <a href="vhosts/">Hôtes virtuels</a>,
|
|
ce qui lui permet de traiter des requêtes pour plusieurs hôtes.
|
|
Dans ce cas, un <directive module="core">DocumentRoot</directive>
|
|
différent peut être défini pour chaque hôte virtuel;
|
|
les directives fournies par le module
|
|
<module>mod_vhost_alias</module> 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.</p>
|
|
|
|
<p>La directive <directive module="core">DocumentRoot</directive> est
|
|
définie dans le fichier de configuration de votre serveur principal
|
|
(<code>httpd.conf</code>), mais peut aussi être redéfinie pour chaque
|
|
<a href="vhosts/">Hôte virtuel</a> supplémentaire que vous avez créé.</p>
|
|
</section>
|
|
|
|
<section id="outside"><title>Fichiers situés en dehors de
|
|
l'arborescence DocumentRoot</title>
|
|
|
|
<p>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 <directive
|
|
module="core">DocumentRoot</directive>. 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 <directive
|
|
module="core">DocumentRoot</directive>. Pour des raisons de sécurité,
|
|
Apache ne suivra les liens symboliques que si les <directive
|
|
module="core">Options</directive> pour le répertoire concerné contiennent
|
|
<code>FollowSymLinks</code> ou <code>SymLinksIfOwnerMatch</code>.</p>
|
|
|
|
<p>Une autre méthode consiste à utiliser la directive <directive
|
|
module="mod_alias">Alias</directive> pour rattacher toute portion
|
|
du système de fichiers à l'arborescence du site web. Par exemple, avec</p>
|
|
|
|
<example>Alias /docs /var/web</example>
|
|
|
|
<p>l'URL <code>http://www.example.com/docs/dir/file.html</code>
|
|
correspondra au fichier <code>/var/web/dir/file.html</code>. La
|
|
directive
|
|
<directive module="mod_alias">ScriptAlias</directive>
|
|
fonctionne de la même manière, excepté que tout contenu localisé dans le
|
|
chemin cible sera traité comme un script <glossary ref="cgi"
|
|
>CGI</glossary>.</p>
|
|
|
|
<p>Pour les situations qui nécessitent plus de flexibilité, vous disposez
|
|
des directives <directive module="mod_alias">AliasMatch</directive>
|
|
et <directive module="mod_alias">ScriptAliasMatch</directive>
|
|
qui permettent des substitutions et comparaisons puissantes basées
|
|
sur les <glossary ref="regex">expressions rationnelles</glossary>.
|
|
Par exemple,</p>
|
|
|
|
<example>ScriptAliasMatch ^/~([a-zA-Z0-9]+)/cgi-bin/(.+)
|
|
/home/$1/cgi-bin/$2</example>
|
|
|
|
<p>fera correspondre une requête du style
|
|
<code>http://example.com/~user/cgi-bin/script.cgi</code> au chemin
|
|
<code>/home/user/cgi-bin/script.cgi</code>, et traitera le fichier résultant
|
|
comme un script CGI.</p>
|
|
</section>
|
|
|
|
<section id="user"><title>Répertoires des utilisateurs</title>
|
|
|
|
<p>Sur les systèmes Unix, on peut traditionnellement faire référence
|
|
au répertoire personnel d'un <em>utilisateur</em> particulier à l'aide de
|
|
l'expression <code>~user/</code>.
|
|
Le module <module>mod_userdir</module>
|
|
é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 :</p>
|
|
|
|
<example>http://www.example.com/~user/file.html</example>
|
|
|
|
<p>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 <directive module="mod_userdir">UserDir</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
|
|
<code>Userdir public_html</code>, l'URL ci-dessus correspondra à un fichier
|
|
dont le chemin sera du style
|
|
<code>/home/user/public_html/file.html</code> où
|
|
<code>/home/user/</code> est le répertoire home de l'utilisateur tel qu'il
|
|
est défini dans <code>/etc/passwd</code>.</p>
|
|
|
|
<p>La directive <code>Userdir</code> met à votre disposition de nombreuses
|
|
formes différentes pour les systèmes où <code>/etc/passwd</code> ne
|
|
spécifie pas la localisation du répertoire home.</p>
|
|
|
|
<p>Certains jugent le symbole "~" (dont le code sur le web est souvent
|
|
<code>%7e</code>) 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
|
|
<directive module="mod_alias">AliasMatch</directive>
|
|
pour obtenir l'effet désiré. Par exemple, pour faire correspondre
|
|
<code>http://www.example.com/upages/user/file.html</code> à
|
|
<code>/home/user/public_html/file.html</code>, utilisez la directive
|
|
<code>AliasMatch</code> suivante :</p>
|
|
|
|
<example>AliasMatch ^/upages/([a-zA-Z0-9]+)/?(.*)
|
|
/home/$1/public_html/$2</example>
|
|
</section>
|
|
|
|
<section id="redirect"><title>Redirection d'URL</title>
|
|
|
|
<p>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 <em>redirection</em> et est implémenté par la
|
|
directive <directive module="mod_alias">Redirect</directive>.
|
|
Par exemple, si le contenu du répertoire <code>/foo/</code> sous
|
|
<directive module="core">DocumentRoot</directive> est déplacé vers le
|
|
nouveau répertoire <code>/bar/</code>, vous pouvez demander aux clients
|
|
de le requérir à sa nouvelle localisation comme suit :</p>
|
|
|
|
<example>Redirect permanent /foo/ http://www.example.com/bar/</example>
|
|
|
|
<p>Ceci aura pour effet de rediriger tout chemin d'URL commençant par
|
|
<code>/foo/</code> vers le même chemin d'URL sur le serveur
|
|
<code>www.example.com</code> en remplaçant <code>/foo/</code> par
|
|
<code>/bar/</code>. Vous pouvez rediriger les clients non seulement sur le
|
|
serveur d'origine, mais aussi vers n'importe quel autre serveur.</p>
|
|
|
|
<p>Apache propose aussi la directive <directive
|
|
module="mod_alias">RedirectMatch</directive> 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 :</p>
|
|
|
|
<example>RedirectMatch permanent ^/$
|
|
http://www.example.com/startpage.html</example>
|
|
|
|
<p>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 :</p>
|
|
|
|
<example>RedirectMatch temp .*
|
|
http://othersite.example.com/startpage.html</example>
|
|
</section>
|
|
|
|
<section id="proxy"><title>Mandataire inverse (Reverse Proxy)</title>
|
|
|
|
<p>Apache vous permet aussi de rapatrier des documents distants
|
|
dans l'espace des URL du serveur local.
|
|
Cette technique est appelée <em>mandataire inverse ou reverse
|
|
proxying</em> 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.</p>
|
|
|
|
<p>Dans l'exemple suivant, quand les clients demandent des documents situés
|
|
dans le répertoire
|
|
<code>/foo/</code>, le serveur rapatrie ces documents depuis le répertoire
|
|
<code>/bar/</code> sur <code>internal.example.com</code>
|
|
et les renvoie au client comme s'ils appartenaient au serveur local.</p>
|
|
|
|
<example>
|
|
ProxyPass /foo/ http://internal.example.com/bar/<br />
|
|
ProxyPassReverse /foo/ http://internal.example.com/bar/<br />
|
|
ProxyPassReverseCookieDomain internal.example.com public.example.com<br />
|
|
ProxyPassReverseCookiePath /foo/ /bar/
|
|
</example>
|
|
|
|
<p>La directive <directive module="mod_proxy">ProxyPass</directive> configure
|
|
le serveur pour rapatrier les documents appropriés, alors que la directive
|
|
<directive module="mod_proxy">ProxyPassReverse</directive>
|
|
réécrit les redirections provenant de
|
|
<code>internal.example.com</code> de telle manière qu'elles ciblent le
|
|
répertoire approprié sur le serveur local. De manière similaire, les directives
|
|
<directive module="mod_proxy">ProxyPassReverseCookieDomain</directive>
|
|
et <directive module="mod_proxy">ProxyPassReverseCookiePath</directive>
|
|
réécrivent les cookies élaborés par le serveur d'arrière-plan.</p>
|
|
<p>Il est important de noter cependant, que les liens situés dans les documents
|
|
ne seront pas réécrits. Ainsi, tout lien absolu sur
|
|
<code>internal.example.com</code> fera décrocher le client
|
|
du serveur mandataire et effectuer sa requête directement sur
|
|
<code>internal.example.com</code>. Un module tiers
|
|
<a href="http://apache.webthing.com/mod_proxy_html/">mod_proxy_html</a>
|
|
permet de réécrire les liens dans les documents HTML et XHTML.</p>
|
|
</section>
|
|
|
|
<section id="rewrite"><title>Moteur de réécriture</title>
|
|
|
|
<p>Le moteur de réécriture <module>mod_rewrite</module> 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 la
|
|
<a href="rewrite/">documentation détaillée de mod_rewrite</a>.</p>
|
|
</section>
|
|
|
|
<section id="notfound"><title>Fichier non trouvé (File Not Found)</title>
|
|
|
|
<p>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
|
|
<a href="#redirect">redirection d'URL</a> 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.</p>
|
|
|
|
<p>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
|
|
<module>mod_speling</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é, 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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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 <directive module="core">ErrorDocument</directive>
|
|
et peut être personnalisée de manière très flexible comme discuté dans le
|
|
document
|
|
<a href="custom-error.html">Réponses personnalisées aux erreurs</a>.</p>
|
|
</section>
|
|
|
|
</manualpage>
|