Updates. (ede23c31) · Commits · CYBER - Cyber Security / TS 103 523 MSP / TLMSP / TLMSP Apache Httpd

docs/manual/mod/core.xml.fr

+8 −3

Original line number	Diff line number	Diff line
		<?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>

docs/manual/mod/mod_rewrite.xml.fr

+12 −7

Original line number	Diff line number	Diff line
		<?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

docs/manual/mod/mod_setenvif.xml.fr

+1 −15

Original line number	Diff line number	Diff line
		<?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

docs/manual/mpm.xml.fr

+1 −1

Original line number	Diff line number	Diff line
		@@ -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>

docs/manual/rewrite/tech.xml.fr

+87 −81

Original line number	Diff line number	Diff line
		<?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>