diff options
| author | Lucien Gentis <lgentis@apache.org> | 2011-10-15 18:39:18 +0200 |
|---|---|---|
| committer | Lucien Gentis <lgentis@apache.org> | 2011-10-15 18:39:18 +0200 |
| commit | 8ee73a5b63989e8e4e995daf3f14e93c6f78c953 (patch) | |
| tree | e3d28fc7406856bc24dc629aca696d04c929c374 | |
| parent | There is absolutely no reason to have two 4k-sized constant strmatch patterns (diff) | |
| download | apache2-8ee73a5b63989e8e4e995daf3f14e93c6f78c953.tar.xz apache2-8ee73a5b63989e8e4e995daf3f14e93c6f78c953.zip | |
Updates.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1183669 13f79535-47bb-0310-9956-ffa450edef68
| -rw-r--r-- | docs/manual/mod/core.xml.fr | 11 | ||||
| -rw-r--r-- | docs/manual/mod/mod_rewrite.xml.fr | 19 | ||||
| -rw-r--r-- | docs/manual/mod/mod_setenvif.xml.fr | 16 | ||||
| -rw-r--r-- | docs/manual/mpm.xml.fr | 2 | ||||
| -rw-r--r-- | docs/manual/rewrite/tech.xml.fr | 168 | ||||
| -rw-r--r-- | docs/manual/upgrading.xml.fr | 10 |
6 files changed, 118 insertions, 108 deletions
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 @@ <?xml version="1.0"?> <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd"> <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?> -<!-- English Revision : 1173140 --> +<!-- English Revision : 1182379 --> <!-- French translation : Lucien GENTIS --> <!-- Reviewed by : Vincent Deffontaines --> @@ -538,7 +538,7 @@ All pour les versions antérieures</default> <p>Example:</p> <example> - AllowOverride None + AllowOverride None<br /> AllowOverrideList Redirect RedirectMatch </example> @@ -549,7 +549,7 @@ All pour les versions antérieures</default> <p>Example:</p> <example> - AllowOverride AuthConfig + AllowOverride AuthConfig<br /> AllowOverrideList CookieTracking CookieName </example> @@ -1972,6 +1972,11 @@ host</context> le sous-répertoire <code>bin</code> de votre répertoire d'installation, afin de déterminer les noms d'hôtes associés aux adresses IP journalisées.</p> + + <p>Enfin, si vous avez des <a + href="mod_authz_host.html#reqhost">directives Require à base de + nom</a>, une recherche de nom d'hôte sera effectuée quelle que soit + la définition de la directive <code>HostnameLookups</code>.</p> </usage> </directivesynopsis> 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 @@ <?xml version="1.0"?> <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd"> <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?> -<!-- English Revision : 1174747 --> +<!-- English Revision : 1180879 --> <!-- French translation : Lucien GENTIS --> <!-- Reviewed by : Vincent Deffontaines --> @@ -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.</p> -<note><title>Qu'est-ce qui est comparé ?</title> +<note><title><a id="what_is_matched" name="what_is_matched">Qu'est-ce qui est comparé ?</a></title> <p>Dans un contexte de serveur virtuel <directive module="core">VirtualHost</directive>, le <em>modèle</em> 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.</p> - <p>Comme mentionné précédemment, toutes les règles de - réécriture sont appliquées à la chaîne de <em>Substitution</em> - (selon l'ordre dans lequel elles sont définies dans le fichier - de configuration). L'URL est <strong>intégralement + <p>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 <a href="#what_is_matched">Qu'est-ce qui est + comparé ?</a>) est <strong>intégralement remplacée</strong> par la chaîne de <em>Substitution</em> 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 <code><strong>L</strong></code>.</p> + par un drapeau <a + href="../rewrite/flags.html#flag_l"><code><strong>L</strong></code></a>, + ou par un autre drapeau qui implique un arrêt immédiat, comme + <code><strong>END</strong></code> ou + <code><strong>F</strong></code>.</p> <note><title>Modifier la chaîne de requête</title> <p>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 @@ <?xml version="1.0"?> <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd"> <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?> -<!-- English Revision : 1174747 --> +<!-- English Revision : 1180828 --> <!-- French translation : Lucien GENTIS --> <!-- Reviewed by : Vincent Deffontaines --> @@ -194,14 +194,6 @@ en compte que si aucune correspondance n'a été trouvée parm caractéristiques de la requête, et si <em>attribut</em> n'a pas été spécifié sous la forme d'une expression rationnelle.</li> -<li>La référence à une extension d'un certificat client SSL, localisé -par son identifiant objet <em>oid</em>. Dans le cas d'une requête non -SSL, ou en l'absence d'<em>oid</em> configuré, aucune variable ne sera -définie. Si l'<em>oid</em> est trouvé plusieurs fois, les chaînes -individuelles seront concaténées, en les séparant par des virgules -<code>','</code>. L'<em>oid</em> doit faire référence à une extension -sous forme de chaîne. -</li> </ol> <p>Le second argument (<em>regex</em>) est une <glossary @@ -240,8 +232,6 @@ peuvent se présenter sous les formes suivantes :</p> :<br /> SetEnvIf objet_est_une_image xbm XBIT_PROCESSING=1<br /> :<br /> - SetEnvIf OID("2.16.840.1.113730.1.13") "(.*)" commentaire-netscape=$1<br /> - :<br /> SetEnvIf ^TS ^[a-z] HAVE_TS<br /> </example> @@ -252,10 +242,6 @@ peuvent se présenter sous les formes suivantes :</p> quelque part dans le site web <code>www.mon-domaine.example.com</code>.</p> - <p>La sixième ligne définit la variable d'environnement - <code>commentaire-netscape</code> avec la chaîne trouvée dans le - champ du certificat client SSL correspondant.</p> - <p>La dernière ligne définit la variable d'environnement <code>HAVE_TS</code> 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 <a href="mod/">l'indexe des + MPMs disponibles est fournie dans <a href="mod/">l'index des modules</a>.</p> </section> 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 @@ <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd"> <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?> -<!-- English Revision : 1174747 --> +<!-- English Revision : 1180985 --> <!-- French translation : Lucien GENTIS --> <!-- Reviewed by : Vincent Deffontaines --> @@ -42,88 +42,94 @@ correspondance</a></seealso> <seealso><a href="advanced.html">Techniques avancées</a></seealso> <seealso><a href="avoid.html">Quand ne pas utiliser mod_rewrite</a></seealso> -<section id="Internal"><title>Fonctionnement interne</title> - - <p>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.</p> -</section> - <section id="InternalAPI"><title>Phases de l'API</title> - <p>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 (<code>.htaccess</code>), mais - avant que le gestionnaire de contenu soit activé.</p> - - <p>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 :</p> - - <ol> - <li>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.</li> - - <li> - Paradoxalement, mod_rewrite permet la manipulation d'URLs dans - un contexte de répertoire, <em>c'est à dire</em> dans les - fichiers <code>.htaccess</code>, 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 <code>.htaccess</code> 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 - <code>RewriteBase</code> 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. - - <p>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.</p> - </li> - </ol> - - <p>Ne perdez pas de vue ces deux points!</p> + <p>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).</p> + + <p>mod_rewrite agit dans deux de ces phases (ou accroches - hooks - + comme on les nomme souvent) pour la réécriture des URLs.</p> + + <p>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 + <code>.htaccess</code>), mais avant l'appel du gestionnaire de + contenu.</p> + + <p>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 + <directive module="core" type="section">Virtualhost</directive>). + Tout ce processus s'exécute au cours de la phase de traduction URL + vers nom de fichier.</p> + + <p>Quelques étapes plus loin, une fois les répertoires de données + finaux trouvés, les directives de configuration de niveau répertoire + (fichiers <code>.htaccess</code> et sections <directive module="core" + type="section">Directory</directive>) sont appliquées. Ce processus + s'exécute au cours de la phase Fixup.</p> + + <p>Dans tous ces cas, mod_rewrite réécrit le + <code>REQUEST_URI</code> soit vers une nouvelle URL, soit vers un + nom de fichier.</p> + + <p>Dans un contexte de niveau répertoire (autrement dit dans les + fichiers <code>.htaccess</code> et les sections + <code>Directory</code>), 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 <directive module="mod_rewrite">RewriteBase</directive> + 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.</p> + + <p>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 :</p> + + <table border="1"> + + <tr> + <th>Position de la règle</th> + <th>Règle</th> + </tr> + + <tr> + <td>Section VirtualHost</td> + <td>RewriteRule ^/images/(.+)\.jpg /images/$1.gif</td> + </tr> + + <tr> + <td>Fichier .htaccess à la racine des documents</td> + <td>RewriteRule ^images/(.+)\.jpg images/$1.gif</td> + </tr> + + <tr> + <td>Fichier .htaccess dans le répertoire images</td> + <td>RewriteRule ^(.+)\.jpg $1.gif</td> + </tr> + + </table> + + <p>Pour une étude plus approfondie de la manière dont mod_rewrite + manipule les URLs dans les différents contextes, vous pouvez + consulter les <a href="../mod/mod_rewrite.html#logging">entrées du + journal</a> générées au cours du processus de réécriture.</p> + </section> <section id="InternalRuleset"><title>Traitement du jeu de règles</title> 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 @@ <?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?> <!-- French translation : Lucien GENTIS --> <!-- Reviewed by : Vincent Deffontaines --> -<!-- English Revision : 1174747 --> +<!-- English Revision : 1181242 --> <!-- Licensed to the Apache Software Foundation (ASF) under one or more @@ -309,6 +309,14 @@ nécessiter une mise à jour des fichiers de configuration de la ver s'il s'aperçoit que la quantité de données ajoutée par la compression est supérieure à la quantité de données à compresser. </li> + + <li>Les pages d'erreur multilingues de la version 2.2.x ne + fonctionneront qu'après avoir été corrigées pour + respecter la nouvelle syntaxe de l'élément <code>#if expr=</code> + du module <module>mod_include</module>, ou si la directive + <directive module="mod_include">SSILegacyExprParser</directive> a + été activée pour le répertoire contenant les pages d'erreur. + </li> </ul> </section> |