From: Lucien Gentis Date: Sat, 15 Oct 2011 16:39:18 +0000 (+0000) Subject: Updates. X-Git-Tag: 2.3.15~119 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=8ee73a5b63989e8e4e995daf3f14e93c6f78c953;p=apache Updates. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1183669 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/core.xml.fr b/docs/manual/mod/core.xml.fr index f8ef4c00cd..5149ce28ed 100644 --- a/docs/manual/mod/core.xml.fr +++ b/docs/manual/mod/core.xml.fr @@ -1,7 +1,7 @@ - + @@ -538,7 +538,7 @@ All pour les versions antérieures

Example:

- AllowOverride None + AllowOverride None
AllowOverrideList Redirect RedirectMatch @@ -549,7 +549,7 @@ All pour les versions antérieures

Example:

- AllowOverride AuthConfig + AllowOverride AuthConfig
AllowOverrideList CookieTracking CookieName @@ -1972,6 +1972,11 @@ host le sous-répertoire bin de votre répertoire d'installation, afin de déterminer les noms d'hôtes associés aux adresses IP journalisées.

+ +

Enfin, si vous avez des directives Require à base de + nom, une recherche de nom d'hôte sera effectuée quelle que soit + la définition de la directive HostnameLookups.

diff --git a/docs/manual/mod/mod_rewrite.xml.fr b/docs/manual/mod/mod_rewrite.xml.fr index 8334b4f4c4..ad6dae0f58 100644 --- a/docs/manual/mod/mod_rewrite.xml.fr +++ b/docs/manual/mod/mod_rewrite.xml.fr @@ -1,7 +1,7 @@ - + @@ -986,7 +986,7 @@ RewriteRule ^/$ /homepage.std.html [L] requête ; les expressions suivantes sont comparées à la sortie de la dernière règle de réécriture qui a été appliquée.

-Qu'est-ce qui est comparé ? +<a id="what_is_matched" name="what_is_matched">Qu'est-ce qui est comparé ?</a>

Dans un contexte de serveur virtuel VirtualHost, le modèle est tout @@ -1162,14 +1162,19 @@ substitution ! section de laquelle elles sont décrites. Ces trois types de variables sont évaluées dans l'ordre ci-dessus.

-

Comme mentionné précédemment, toutes les règles de - réécriture sont appliquées à la chaîne de Substitution - (selon l'ordre dans lequel elles sont définies dans le fichier - de configuration). L'URL est intégralement +

Chaque règle de réécriture s'applique au résultat de la règle + précédente, selon l'ordre dans lequel elles ont été définies dans + le fichier de configuration. L'URI du chemin du fichier (voir + ci-dessus Qu'est-ce qui est + comparé ?) est intégralement remplacée par la chaîne de Substitution et le processus de réécriture se poursuit jusqu'à ce que toutes les règles aient été appliquées, ou qu'il soit explicitement stoppé - par un drapeau L.

+ par un drapeau L, + ou par un autre drapeau qui implique un arrêt immédiat, comme + END ou + F.

Modifier la chaîne de requête

Par défaut, la chaîne de requête est transmise sans diff --git a/docs/manual/mod/mod_setenvif.xml.fr b/docs/manual/mod/mod_setenvif.xml.fr index b640433c68..93d38b070e 100644 --- a/docs/manual/mod/mod_setenvif.xml.fr +++ b/docs/manual/mod/mod_setenvif.xml.fr @@ -1,7 +1,7 @@ - + @@ -194,14 +194,6 @@ en compte que si aucune correspondance n'a été trouvée parm caractéristiques de la requête, et si attribut n'a pas été spécifié sous la forme d'une expression rationnelle. -

  • La référence à une extension d'un certificat client SSL, localisé -par son identifiant objet oid. Dans le cas d'une requête non -SSL, ou en l'absence d'oid configuré, aucune variable ne sera -définie. Si l'oid est trouvé plusieurs fois, les chaînes -individuelles seront concaténées, en les séparant par des virgules -','. L'oid doit faire référence à une extension -sous forme de chaîne. -

    • Le second argument (regex) est une :
    SetEnvIf objet_est_une_image xbm XBIT_PROCESSING=1
    :
    - SetEnvIf OID("2.16.840.1.113730.1.13") "(.*)" commentaire-netscape=$1
    - :
    SetEnvIf ^TS ^[a-z] HAVE_TS
    @@ -252,10 +242,6 @@ peuvent se présenter sous les formes suivantes :

    quelque part dans le site web www.mon-domaine.example.com.

    -

    La sixième ligne définit la variable d'environnement - commentaire-netscape avec la chaîne trouvée dans le - champ du certificat client SSL correspondant.

    -

    La dernière ligne définit la variable d'environnement HAVE_TS si la requête contient un en-tête dont le nom commence par "TS" et dont la valeur commence par tout caractère du diff --git a/docs/manual/mpm.xml.fr b/docs/manual/mpm.xml.fr index e46fb5d812..6aa7b04e1e 100644 --- a/docs/manual/mpm.xml.fr +++ b/docs/manual/mpm.xml.fr @@ -78,7 +78,7 @@ que la manière dont ces modules sont utilisés par le serveur HTTP autres modules Apache httpd. La principale différence réside dans le fait qu'un et un seul MPM à la fois doit être chargé lorsque le serveur s'exécute. La liste des - MPMs disponibles est fournie dans l'indexe des + MPMs disponibles est fournie dans l'index des modules.

    diff --git a/docs/manual/rewrite/tech.xml.fr b/docs/manual/rewrite/tech.xml.fr index 6da48f0a82..6c5b87e184 100644 --- a/docs/manual/rewrite/tech.xml.fr +++ b/docs/manual/rewrite/tech.xml.fr @@ -1,7 +1,7 @@ - + @@ -42,88 +42,94 @@ correspondance Techniques avancées Quand ne pas utiliser mod_rewrite -
    Fonctionnement interne - -

    Le fonctionnement interne de ce module est très complexe, mais - il est nécessaire de l'expliquer, même à l'utilisateur "standard", - afin d'éviter les erreurs courantes et de pouvoir exploiter toutes - ses fonctionnalités.

    -
    -
    Phases de l'API -

    Il faut tout d'abord bien comprendre que le traitement d'une - requête HTTP par Apache s'effectue en plusieurs phases. L'API - d'Apache fournit un point d'accroche (hook) pour chacune de ces - phases. Mod_rewrite utilise deux de ces hooks : le hook de - conversion des URLs en noms de fichiers qui est utilisé quand la - requête HTTP a été lue mais avant le démarrage de tout processus - d'autorisation, et le hook "Fixup" qui est déclenché après les - phases d'autorisation et après la lecture des fichiers de - configuration niveau répertoire (.htaccess), mais - avant que le gestionnaire de contenu soit activé.

    - -

    Donc, lorsqu'une requête arrive et quand Apache a déterminé le - serveur correspondant (ou le serveur virtuel), le moteur de - réécriture commence le traitement de toutes les directives de - mod_rewrite de la configuration du serveur principal dans la phase - de conversion URL vers nom de fichier. Une fois ces étapes - franchies, lorsque les repertoires de données finaux ont été - trouvés, les directives de configuration de mod_rewrite au niveau - répertoire sont éxécutées dans la phase Fixup. Dans les deux cas, - mod_rewrite réécrit les URLs soit en nouvelles URLs, soit en noms - de fichiers, bien que la distinction entre les deux ne soit pas - évidente. Cette utilisation de l'API n'était pas sensée s'opérer - de cette manière lorsque l'API fut conçue, mais depuis Apache 1.x, - c'est le seul mode opératoire possible pour mod_rewrite. Afin de - rendre les choses plus claires, souvenez-vous de ces deux points :

    - -
      -
    1. Bien que mod_rewrite réécrive les URLs en URLs, les URLs en - noms de fichiers et même des noms de fichiers en d'autres noms - de fichiers, l'API ne propose actuellement qu'un hook URL vers - nom de fichier. Les deux hooks manquants seront ajoutés dans - Apache à partir de la version 2.0 afin de rendre le processus - plus clair. Mais ce point ne présente pas d'inconvénient pour - l'utilisateur, il s'agit simplement d'un fait que vous devez - garder à l'esprit : Apache en fait plus avec le hook URL vers - nom de fichier que l'API n'a la prétention d'en faire.
      2. - -
    2. - Paradoxalement, mod_rewrite permet la manipulation d'URLs dans - un contexte de répertoire, c'est à dire dans les - fichiers .htaccess, bien que ces derniers - soient traités bien longtemps après que les URLs n'aient été - traduites en noms de fichiers. Les choses doivent se dérouler - ainsi car les fichiers .htaccess résident dans le - système de fichiers, et le traitement a déjà atteint - cette étape. Autrement dit, en accord avec les phases de - l'API, à ce point du traitement, il est trop tard pour - effectuer des manipulations d'URLs. Pour résoudre ce problème - d'antériorité, mod_rewrite utilise une astuce : pour effectuer - une manipulation URL/nom de fichier dans un contexte de - répertoire, mod_rewrite réécrit tout d'abord le nom de fichier - en son URL d'origine (ce qui est normalement impossible, mais - voir ci-dessous l'astuce utilisée par la directive - RewriteBase pour y parvenir), puis - initialise une nouvelle sous-requête interne avec la nouvelle - URL ; ce qui a pour effet de redémarrer le processus des - phases de l'API. - -

      Encore une fois, mod_rewrite fait tout ce qui est en son - pouvoir pour rendre la complexité de cette étape complètement - transparente à l'utilisateur, mais vous devez garder ceci à - l'esprit : alors que les manipulations d'URLs dans le contexte - du serveur sont vraiment rapides et efficaces, les réécritures - dans un contexte de répertoire sont lentes et inefficaces à - cause du problème d'antériorité précité. Cependant, c'est la - seule manière dont mod_rewrite peut proposer des manipulations - d'URLs (limitées à une branche du système de fichiers) à - l'utilisateur standard.

      -
      3. -
    - -

    Ne perdez pas de vue ces deux points!

    +

    Le traitement des requêtes par le serveur HTTP Apache se + déroule en plusieurs phases. Au cours de chaque phase, un ou + plusieurs modules peuvent être appelés pour traiter la partie + concernée du cycle de vie de la requête. Les différentes phases + peuvent consister en traduction d'URL en nom de fichier, + authentification, autorisation, gestion de contenu ou journalisation (la + liste n'est pas exhaustive).

    + +

    mod_rewrite agit dans deux de ces phases (ou accroches - hooks - + comme on les nomme souvent) pour la réécriture des URLs.

    + +

    Tout d'abord, il utilise le hook traduction URL vers nom de + fichier qui intervient après la lecture de la requête HTTP, mais + avant le processus d'autorisation. Ensuite, il utilise le hook + Fixup, qui intervient après les phases d'autorisation, après la + lecture des fichiers de configuration de niveau répertoire (fichiers + .htaccess), mais avant l'appel du gestionnaire de + contenu.

    + +

    Ainsi, lorsqu'une requête arrive et une fois le serveur + correspondant ou le serveur virtuel déterminé, le moteur de + réécriture commence à traiter toute directive apparaissant dans la + configuration de niveau serveur (autrement dit dans le + fichier de configuration principal du serveur et les sections + Virtualhost). + Tout ce processus s'exécute au cours de la phase de traduction URL + vers nom de fichier.

    + +

    Quelques étapes plus loin, une fois les répertoires de données + finaux trouvés, les directives de configuration de niveau répertoire + (fichiers .htaccess et sections Directory) sont appliquées. Ce processus + s'exécute au cours de la phase Fixup.

    + +

    Dans tous ces cas, mod_rewrite réécrit le + REQUEST_URI soit vers une nouvelle URL, soit vers un + nom de fichier.

    + +

    Dans un contexte de niveau répertoire (autrement dit dans les + fichiers .htaccess et les sections + Directory), les règles de réécriture s'appliquent après + la traduction de l'URL en nom de fichier. C'est pourquoi mod_rewrite + retraduit temporairement le nom de fichier en URL en supprimant le + chemin de répertoire avant d'appliquer les règles (Reportez-vous à + la directive RewriteBase + pour voir comment vous pourrez par la suite personnaliser la manière + dont tout ceci est traité). Ensuite, une nouvelle sous-requête + interne est initiée avec la nouvelle URL, ce qui redémarre le + traitement des phases de l'API.

    + +

    En conséquence de cette manipulation de l'URL , vous devrez + pensez à confectionner différemment vos règles de réécriture dans un + contexte de niveau répertoire. En particulier, rappelez-vous que le + chemin de répertoire sera absent de l'URL que vos règles de + réécriture verront. Voici quelques exemples qui permettront de + clarifier les choses :

    + + + + + + + + + + + + + + + + + + + + + + + +
    Position de la règleRègle
    Section VirtualHostRewriteRule ^/images/(.+)\.jpg /images/$1.gif
    Fichier .htaccess à la racine des documentsRewriteRule ^images/(.+)\.jpg images/$1.gif
    Fichier .htaccess dans le répertoire imagesRewriteRule ^(.+)\.jpg $1.gif
    + +

    Pour une étude plus approfondie de la manière dont mod_rewrite + manipule les URLs dans les différents contextes, vous pouvez + consulter les entrées du + journal générées au cours du processus de réécriture.

    +
    Traitement du jeu de règles diff --git a/docs/manual/upgrading.xml.fr b/docs/manual/upgrading.xml.fr index e67b13f82b..d8c2935961 100644 --- a/docs/manual/upgrading.xml.fr +++ b/docs/manual/upgrading.xml.fr @@ -3,7 +3,7 @@ - +