From: Lucien Gentis Date: Fri, 6 Apr 2012 15:04:52 +0000 (+0000) Subject: Updates. X-Git-Tag: 2.2.23~193 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=e95f3297f57db5a9f8eaf00700a42645959ea6fe;p=thirdparty%2Fapache%2Fhttpd.git Updates. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x@1310381 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/core.xml.fr b/docs/manual/mod/core.xml.fr index ba1acd6c503..b1734eecfaa 100644 --- a/docs/manual/mod/core.xml.fr +++ b/docs/manual/mod/core.xml.fr @@ -1,7 +1,7 @@ - + @@ -3265,6 +3265,14 @@ serveurs virtuels à base de nom # ...
</VirtualHost> + +

La recherche du serveur virtuel à base de nom qui correspond le + mieux s'effectue selon l'ordre d'apparition des sections virtualhost dans le fichier + de configuration. Le premier serveur virtuel dont le ServerName ou le ServerAlias correspond est choisi, sans + préférence si le nom contient des caractères génériques ou pas.

UseCanonicalName Documentation sur les serveurs virtuels diff --git a/docs/manual/mod/mod_rewrite.xml.fr b/docs/manual/mod/mod_rewrite.xml.fr index b276283e862..8f3e830b767 100644 --- a/docs/manual/mod/mod_rewrite.xml.fr +++ b/docs/manual/mod/mod_rewrite.xml.fr @@ -1,7 +1,7 @@ - + @@ -630,105 +630,51 @@ recherche externe n'intervient qu'une seule fois ! Définit l'URL de base pour les réécritures au niveau répertoire RewriteBase chemin URL -Voir utilisation pour plus d'informations. +None directory.htaccess FileInfo -

La directive RewriteBase définit - explicitement l'URL de base pour les réécritures au niveau du - répertoire. Comme vous le verrez plus loin, la directive - RewriteRule peut - être utilisée dans les fichiers de configuration au niveau du - répertoire (.htaccess). Elle agit alors localement, - en amputant le répertoire local de son préfixe avant traitement, - et en n'appliquant les règles de réécriture que sur ce qui reste - de l'URL. Lorsque le traitement est terminé, le préfixe est - automatiquement rajouté à l'URL. La valeur par défaut est - RewriteBase - chemin répertoire physique

- -

Lorsqu'une substitution intervient pour une nouvelle URL, ce - module doit réinjecté l'URL dans le traitement du serveur. Pour - y parvenir, il doit connaître le préfixe de l'URL ou l'URL de - base correspondants. Par défaut, le préfixe est le chemin du - fichier correspondant lui-même. Cependant, pour la - plupart des sites web, les URLs ne correspondent PAS directement - aux chemins des fichiers physiques, cette assertion s'avère - ainsi souvent fausse !. C'est pourquoi vous pouvez - utiliser la directive RewriteBase pour spécifier - le préfixe correct.

- - Si les URLs de votre serveur web ne correspondent -pas directement aux chemins physiques des fichiers, -vous devrez utiliser RewriteBase dans chaque -fichier .htaccess où vous voudrez utiliser des -directives RewriteRule. - +

La directive RewriteBase permet de + spécifier le préfixe d'URL à utiliser dans un contexte de + répertoire (htaccess) pour les directives + RewriteRule qui réécrivent vers un chemin + relatif.

+

Cette directive est obligatoire si vous utilisez un + chemin relatif dans une substitution, et dans un contexte de + répertoire (htaccess), sauf si au moins une de ces conditions est + vérifiée :

+
    +
  • La requête initiale, ainsi que la substitution, sont dans + la DocumentRoot (c'est à + dire que pour y accéder, il n'est pas nécessaire d'utiliser + une directive telle qu'Alias).
    • +
  • Le chemin du système de fichiers vers le répertoire + contenant la RewriteRule, suffixé par + la substitution relative est aussi valide en tant qu'URL sur + le serveur (ce qui est rare).
    • +
-

Par exemple, considérons le fichier de configuration de - répertoire suivant :

+

Dans l'exemple ci-dessous, la directive +RewriteBase est nécessaire afin d'éviter une +réécriture en http://example.com/opt/myapp-1.2.3/welcome.html car la +ressource n'était pas relative à la racine des documents. Cette erreur +de configuration aurait conduit le serveur à rechercher un répertoire +"opt" à la racine des documents.

-#
-#  /abc/def/.htaccess -- fichier de configuration pour le répertoire
-/abc/def
-#  Rappel : /abc/def est le chemin physique de /xyz,
-#  ce qui veut dire que la configuration du serveur comporte
-#  une directive du style 'Alias /xyz /abc/def'.
-#
-
+DocumentRoot /var/www/example.com
+Alias /myapp /opt/myapp-1.2.3
+<Directory /opt/myapp-1.2.3>
 RewriteEngine On
-
-#  faisons savoir au serveur qu'on nous a atteint via /xyz et non par
-#  le chemin physique /abc/def
-RewriteBase   /xyz
-
-#  maintenant les règles de réécriture
-RewriteRule   ^avant\.html$  après.html
+RewriteBase /myapp/
+RewriteRule ^index\.html$  welcome.html 
+</Directory>
- -

Dans l'exemple précédent, une requête pour - /xyz/avant.html sera correctement réécrite sous - sous sa forme chemin physique - /abc/def/après.html.

- -Pour les hackers d'Apache -

La liste suivante fournit des informations détaillées à propos des -étapes du traitement interne :

-
-Requête :
-  /xyz/avant.html
-
-Traitement interne :
-  /xyz/avant.html     -> /abc/def/avant.html  (Alias au niveau serveur)
-  /abc/def/avant.html -> /abc/def/après.html  (RewriteRule au niveau répertoire)
-  /abc/def/après.html -> /xyz/après.html      (RewriteBase au niveau répertoire)
-  /xyz/après.html     -> /abc/def/après.html  (Alias au niveau serveur)
-
-Résultat :
-  /abc/def/après.html
-
-
-

Tout ceci paraît très compliqué, mais correspond - réellement au traitement interne d'Apache. Comme la - réécriture au niveau du répertoire intervient plus tard - au cours du traitement, la requête de réécriture doit être - réinjectée dans le noyau d'Apache, comme s'il s'agissait - d'une nouvelle requête (Voir les détails techniques à - propos de mod_rewrite). La surcharge - correspondante n'est pas aussi importante qu'il n'y - paraît, car la réinjection est entièrement prise en charge - en interne par Apache (comme c'est d'ailleurs le cas pour - de nombreuses autres opérations effectuées à l'intérieur - d'Apache).

- - diff --git a/docs/manual/vhosts/ip-based.xml.fr b/docs/manual/vhosts/ip-based.xml.fr index 31f55766f5f..7cfcc117216 100644 --- a/docs/manual/vhosts/ip-based.xml.fr +++ b/docs/manual/vhosts/ip-based.xml.fr @@ -1,8 +1,9 @@ - - + + +

SuexecUserGroup peut être - utilisée à l'intérieur d'une directive VirtualHost si l'exécution se fait + utilisées à l'intérieur d'une directive VirtualHost si l'exécution se fait sous suEXEC. (Voir suEXEC).

SÉCURITÉ : lorsque vous spécifiez où écrire les