From fe39ffb8b90ae4e002ed73fe98617cd590abb467 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sat, 27 Apr 2024 08:33:50 +0200 Subject: Adding upstream version 2.4.56. Signed-off-by: Daniel Baumann --- docs/manual/urlmapping.html.fr.utf8 | 402 ++++++++++++++++++++++++++++++++++++ 1 file changed, 402 insertions(+) create mode 100644 docs/manual/urlmapping.html.fr.utf8 (limited to 'docs/manual/urlmapping.html.fr.utf8') diff --git a/docs/manual/urlmapping.html.fr.utf8 b/docs/manual/urlmapping.html.fr.utf8 new file mode 100644 index 0000000..aea08c7 --- /dev/null +++ b/docs/manual/urlmapping.html.fr.utf8 @@ -0,0 +1,402 @@ + + + + + + Mise en correspondance des URLs avec le système de fichiers - Serveur HTTP Apache 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.

+
+ +
top
+
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 + (httpd.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 :

+
    +
  • mod_actions - Met une URL en correspondance + avec un script CGI en fonction de la méthode de la requête, ou du + type MIME de la ressource.
  • +
  • mod_dir - Permet une mise en correspondance + basique d'un slash terminal dans un fichier index comme + index.html.
  • +
  • mod_imagemap - 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.
  • +
+ +
+
+

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 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 Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file -- cgit v1.2.3