You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by gr...@apache.org on 2009/11/01 21:13:29 UTC
svn commit: r831756 [4/4] - /httpd/httpd/trunk/docs/manual/mod/
Added: httpd/httpd/trunk/docs/manual/mod/mod_headers.xml.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_headers.xml.fr?rev=831756&view=auto
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_headers.xml.fr (added)
+++ httpd/httpd/trunk/docs/manual/mod/mod_headers.xml.fr Sun Nov 1 20:13:27 2009
@@ -0,0 +1,491 @@
+<?xml version="1.0"?>
+<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
+<!-- English Revision : 826164 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<modulesynopsis metafile="mod_headers.xml.meta">
+
+<name>mod_headers</name>
+<description>Personnalisation des en-têtes de requêtes et de réponses
+HTTP</description>
+<status>Extension</status>
+<sourcefile>mod_headers.c</sourcefile>
+<identifier>headers_module</identifier>
+
+<summary>
+ <p>Ce module fournit des directives permettant de contrôler et
+ modifier les en-têtes de requêtes et de réponses HTTP. Les en-têtes
+ peuvent être fusionnés, remplacés ou supprimés.</p>
+</summary>
+
+<section id="order"><title>Chronologie du traitement</title>
+
+ <p>Les directives fournies par <module>mod_headers</module> peuvent
+ s'insérer presque partout dans la configuration du serveur, et on
+ peut limiter leur portée en les plaçant dans des <a
+ href="../sections.html">sections de configuration</a>.</p>
+
+ <p>La chronologie du traitement est importante et est affectée par
+ l'ordre d'apparition des directives dans le fichier de configuration
+ et par leur placement dans les <a
+ href="../sections.html#mergin">sections de configuration</a>. Ainsi,
+ ces deux directives ont un effet différent si leur ordre est inversé
+ :</p>
+
+ <example>
+ RequestHeader append MirrorID "mirror 12"<br />
+ RequestHeader unset MirrorID
+ </example>
+
+ <p>Dans cet ordre, l'en-tête <code>MirrorID</code> n'est pas défini.
+ Si l'ordre des directives était inversé, l'en-tête
+ <code>MirrorID</code> serait défini à "mirror 12".</p>
+</section>
+
+<section id="early"><title>Traitement précoce et traitement
+tardif</title>
+ <p><module>mod_headers</module> peut agir soir précocement, soit
+ tardivement au niveau de la requête. Le mode normal est le mode
+ tardif, lorsque les en-têtes de requête sont définis, immédiatement
+ avant l'exécution du générateur de contenu, et pour les en-têtes de
+ réponse, juste au moment où la réponse est envoyée sur le réseau.
+ Utilisez toujours le mode tardif sur un serveur en production.</p>
+
+ <p>Le mode précoce a été conçu à des fins d'aide aux tests et au
+ débogage pour les développeurs. Les directives définies en utilisant
+ le mot-clé <code>early</code> sont censées agir au tout début du
+ traitement de la requête. Cela signifie que l'on peut les utiliser
+ pour simuler différentes requêtes et définir des situations de test,
+ tout en gardant à l'esprit que les en-têtes peuvent être modifiés à
+ tout moment par d'autres modules avant que le réponse ne soit
+ générée.</p>
+
+ <p>Comme les directives précoces sont traitées avant que le
+ chemin de la requête ne soit parcouru, les en-têtes
+ précoces ne peuvent être définis que dans un contexte de serveur
+ principal ou de serveur virtuel. Les directives précoces ne peuvent
+ pas dépendre d'un chemin de requête, si bien qu'elles échoueront
+ dans des contextes tels que <code><Directory></code> ou
+ <code><Location></code>.</p>
+</section>
+
+<section id="examples"><title>Exemples</title>
+
+ <ol>
+ <li>
+ Copie tous les en-têtes de requête qui commencent par "TS" vers
+ les en-têtes de la réponse :
+
+ <example>
+ Header echo ^TS
+ </example>
+ </li>
+
+ <li>
+ Ajoute à la réponse un en-tête, <code>mon-en-tête</code>, qui
+ contient un horodatage permettant de déterminer le moment où la
+ requête a été reçue, et le temps qui s'est écoulé jusqu'à ce que
+ la requête ait commencé à être servie. Cet en-tête peut être
+ utilisé par le client pour estimer la charge du serveur ou
+ isoler les goulets d'étranglement entre le client et le
+ serveur.
+
+ <example>
+ Header set mon-en-tête "%D %t"
+ </example>
+
+ <p>le résultat est l'ajout à la réponse d'un en-tête du type :</p>
+
+ <example>
+ mon-en-tête: D=3775428 t=991424704447256
+ </example>
+ </li>
+
+ <li>
+ Dit Bonjour à Joe
+
+ <example>
+ Header set mon-en-tête "Bonjour Joe. Il a fallu %D microsecondes \<br />
+ à Apache pour servir cette requête."
+ </example>
+
+ <p>le résultat est l'ajout à la réponse d'un en-tête du type :</p>
+
+ <example>
+ mon-en-tête: Bonjour Joe. Il a fallu D=3775428 microsecondes à Apache
+ pour servir cette requête.
+ </example>
+ </li>
+
+ <li>
+ Ajoute l'en-tête <code>mon-en-tête</code> à la réponse si et
+ seulement si l'en-tête <code>mon-en-tête-requête</code> est
+ présent dans la requête. Ceci peut s'avérer utile pour générer
+ des en-têtes de réponse "à la tête du client". Notez que cet
+ exemple nécessite les services du module
+ <module>mod_setenvif</module>.
+
+ <example>
+ SetEnvIf mon-en-tête-requête mavaleur HAVE_MyRequestHeader<br />
+ Header set mon-en-tête "%D %t montexte" env=HAVE_MyRequestHeader
+ </example>
+
+ <p>Si l'en-tête <code>mon-en-tête-requête: mavaleur</code> est
+ présent dans la requête HTTP, la réponse contiendra un en-tête
+ du type :</p>
+
+ <example>
+ mon-en-tête: D=3775428 t=991424704447256 montexte
+ </example>
+ </li>
+
+ <li>
+ Permet à DAV de fonctionner avec Apache sur SSL (voir la <a
+ href="http://svn.haxx.se/users/archive-2006-03/0549.shtml">description
+ du problème</a>) en remplaçant <var>https:</var> par
+ <var>http:</var> dans l'en-tête <var>Destination</var> :
+
+ <example>
+ RequestHeader edit Destination ^https: http: early
+ </example>
+ </li>
+
+ <li>
+ Définit la valeur d'un même en-tête sous de multiples conditions
+ non exclusives, mais ne duplique pas une valeur déjà définie
+ dans l'en-tête qui en résulte. Si toutes les conditions
+ suivantes sont satisfaites pour une requête (en d'autres termes,
+ si les trois variables d'environnement <code>CGI</code>,
+ <code>NO_CACHE</code> et <code>NO_STORE</code> existent pour la
+ requête) :
+
+ <example>
+ Header merge Cache-Control no-cache env=CGI<br />
+ Header merge Cache-Control no-cache env=NO_CACHE<br />
+ Header merge Cache-Control no-store env=NO_STORE
+ </example>
+
+ <p>alors, la réponse contiendra l'en-tête suivant :</p>
+
+ <example>
+ Cache-Control: no-cache, no-store
+ </example>
+
+ <p>Si <code>append</code> avait été utilisé à la place de
+ <code>merge</code>, la réponse aurait contenu l'en-tête suivant
+ :</p>
+
+ <example>
+ Cache-Control: no-cache, no-cache, no-store
+ </example>
+ </li>
+ <li>
+ Définit un cookie de test si et seulement si le client n'envoie
+ pas de cookie
+ <example>
+ Header set Set-Cookie testcookie !$req{Cookie}
+ </example>
+ </li>
+ </ol>
+</section>
+
+<directivesynopsis>
+<name>RequestHeader</name>
+<description>Configure les en-têtes d'une requête HTTP</description>
+<syntax>RequestHeader add|append|edit|merge|set|unset <var>en-tête</var>
+[<var>valeur</var>] [<var>remplacement</var>] [early|env=[!]<var>variable</var>]</syntax>
+<contextlist><context>server config</context><context>virtual host</context>
+<context>directory</context><context>.htaccess</context></contextlist>
+<override>FileInfo</override>
+
+<usage>
+ <p>Cette directive permet de remplacer, fusionner, modifier ou
+ supprimer des en-têtes de requête HTTP. L'en-tête est modifié juste
+ avant que le gestionnaire de contenu ne s'exécute, ce qui permet la
+ modification des en-têtes entrants. L'action effectuée est
+ déterminée par le premier argument. Ce dernier accepte les valeurs
+ suivantes :</p>
+
+ <dl>
+
+ <dt><code>add</code></dt>
+ <dd>L'en-tête est ajouté au jeu d'en-têtes préexistant, même s'il
+ existe déjà. Ceci peut conduire à la présence de deux (ou plusieurs)
+ en-têtes possèdant le même nom et donc induire des conséquences
+ imprévues ; en général, il est préférable d'utiliser
+ <code>set</code>, <code>append</code> ou <code>merge</code>.</dd>
+
+ <dt><code>append</code></dt>
+ <dd>La valeur d'en-tête est ajoutée à tout en-tête existant de même
+ nom. Lorsqu'une nouvelle valeur est ainsi ajoutée, elle est séparée
+ de celles qui sont déjà présentes par une virgule. Il s'agit de la
+ méthode HTTP standard permettant d'affecter plusieurs valeurs à un
+ en-tête.</dd>
+
+ <dt><code>edit</code></dt>
+ <dd>Si l'en-tête existe, sa valeur est modifiée en fonction d'une
+ <glossary ref="regex">expression rationnelle</glossary> de type
+ recherche/remplacement. L'argument <var>valeur</var> est une
+ <glossary ref="regex">expression rationnelle</glossary>, et
+ l'argument <var>remplacement</var> une chaîne de caractères de
+ remplacement qui peut contenir des références arrières.</dd>
+
+ <dt><code>merge</code></dt>
+ <dd>La valeur d'en-tête est ajoutée à tout en-tête de même nom, sauf
+ si elle apparaît déjà dans la liste des valeurs préexistantes de
+ l'en-tête séparées par des virgules. Lorsqu'une nouvelle valeur est
+ ainsi ajoutée, elle est séparée de celles qui sont déjà présentes
+ par une virgule. Il s'agit de la méthode HTTP standard permettant
+ d'affecter plusieurs valeurs à un en-tête. Les valeurs sont
+ comparées en tenant compte de la casse, et après le traitement de
+ tous les spécificateurs de format. Une valeur entourée de guillemets
+ est considérée comme différente de la même valeur mais sans
+ guillemets.</dd>
+
+ <dt><code>set</code></dt>
+ <dd>L'en-tête est défini, remplaçant tout en-tête préexistant avec
+ le même nom.</dd>
+
+ <dt><code>unset</code></dt>
+ <dd>L'en-tête est supprimé s'il existe. Si plusieurs en-têtes
+ possèdent le même nom, ils seront tous supprimés. L'argument
+ <var>value</var> ne doit pas apparaître.</dd>
+ </dl>
+
+ <p>Cet argument est suivi d'un nom d'en-tête qui peut se terminer
+ par un caractère ':', mais ce n'est pas obligatoire. La casse est
+ ignorée. Avec <code>set</code>, <code>append</code>,
+ <code>merge</code> et <code>add</code>, une <var>valeur</var> est
+ fournie en troisième argument. Si une <var>valeur</var> contient des
+ espaces, elle doit être entourée de guillemets. Avec
+ <code>unset</code>, aucune <var>valeur</var> ne doit apparaître.
+ <var>valeur</var> peut être une chaîne de caractères, une chaîne
+ contenant des spécificateurs de format, ou une combinaison des deux.
+ Les spécificateurs de format supportés sont les mêmes que ceux de la
+ directive <directive module="mod_headers">Header</directive>, à
+ laquelle vous pouvez vous reporter pour plus de détails. Avec
+ <code>edit</code>, les deux arguments <var>valeur</var> et
+ <var>remplacement</var> sont obligatoires, et correspondent
+ respectivement à une <glossary ref="regex">expression
+ rationnelle</glossary> et à une chaîne de remplacement.</p>
+
+ <p>La directive <directive>RequestHeader</directive> peut être
+ suivie d'un argument supplémentaire, qui pourra prendre les valeurs
+ suivantes :</p>
+ <dl>
+ <dt><code>early</code></dt>
+ <dd>Spécifie <a href="#early">traitement préalable</a>.</dd>
+ <dt><code>env=[!]variable</code></dt>
+ <dd>La directive est appliquée si et seulement si la <a
+ href="../env.html">variable d'environnement</a>
+ <code>variable</code> existe. Un <code>!</code> devant
+ <code>variable</code> inverse le test, et la directive ne
+ s'appliquera alors que si <code>variable</code> n'est pas définie.</dd>
+ <dt><code>expr</code></dt>
+ <dd>Une chaîne qui correspond à toute valeur ci-dessus est
+ interprétée comme une expression. Les détails à propos de la syntaxe
+ des expressions et leur évaluation sont pour l'instant mieux
+ documentés dans la page de <module>mod_filter</module>.</dd>
+ </dl>
+
+ <p>Excepté le cas du mode <a href="#early">précoce</a>, la directive
+ <directive>RequestHeader</directive> est traitée juste avant la
+ prise en compte de la requête par son gestionnaire, au cours de la
+ phase de vérification. Ceci permet la modification des en-têtes
+ générés par le navigateur, ou par les filtres en entrée
+ d'Apache.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>Header</name>
+<description>Configure les en-têtes d'une réponse HTTP</description>
+<syntax>Header [<var>condition</var>] add|append|echo|edit|merge|set|unset
+<var>en-tête</var> [<var>valeur</var>] [early|env=[!]<var>variable</var>]</syntax>
+<contextlist><context>server config</context><context>virtual host</context>
+<context>directory</context><context>.htaccess</context></contextlist>
+<override>FileInfo</override>
+
+<usage>
+ <p>Cette directive permet de remplacer, fusionner, ou
+ supprimer des en-têtes de réponse HTTP. L'en-tête est modifié juste
+ après que le gestionnaire de contenu et les filtres en sortie ne
+ s'exécutent, ce qui permet la modification des en-têtes
+ sortants.</p>
+
+ <p>Par défaut, cette directive n'affecte que les réponses positives
+ (réponses dont le code de statut est dans la gamme
+ <code>2<var>xx</var></code>). Le paramètre optionnel
+ <var>condition</var> peut prendre pour valeur soit
+ <code>onsuccess</code> (valeur par défaut), soit <code>always</code>
+ (tous les codes de statut, y compris les réponses positives).
+ Définir cette valeur à <code>always</code> permet d'affecter des
+ en-têtes définis par certains modules internes, y compris dans le
+ cas d'une réponse positive, et s'avère même nécessaire pour affecter
+ des en-têtes de réponses dont le code de statut n'est pas dans la
+ gamme <code>2<var>xx</var></code> comme les redirections ou les
+ erreurs client.</p>
+
+ <p>L'action que cette directive provoque est déterminée par le
+ second argument. Il peut prendre une des valeurs suivantes :</p>
+
+ <dl>
+ <dt><code>add</code></dt>
+ <dd>L'en-tête est ajouté au jeu d'en-têtes préexistant, même s'il
+ existe déjà. Ceci peut conduire à la présence de deux (ou plusieurs)
+ en-têtes possèdant le même nom et donc induire des conséquences
+ imprévues ; en général, il est préférable d'utiliser
+ <code>set</code>, <code>append</code> ou <code>merge</code>.</dd>
+
+ <dt><code>append</code></dt>
+ <dd>La valeur d'en-tête est ajoutée à tout en-tête existant de même
+ nom. Lorsqu'une nouvelle valeur est ainsi ajoutée, elle est séparée
+ de celles qui sont déjà présentes par une virgule. Il s'agit de la
+ méthode HTTP standard permettant d'affecter plusieurs valeurs à un
+ en-tête.</dd>
+
+ <dt><code>echo</code></dt>
+ <dd>Les en-têtes de la requête possédant le nom spécifié sont
+ recopiés vers les en-têtes de la réponse. <var>en-tête</var> peut
+ être une <glossary ref="regex">expression rationnelle</glossary>, et
+ <var>valeur</var> ne doit pas être présent.</dd>
+
+ <dt><code>edit</code></dt>
+ <dd>Si l'en-tête existe, sa valeur est modifiée en fonction d'une
+ <glossary ref="regex">expression rationnelle</glossary> de type
+ recherche/remplacement. L'argument <var>valeur</var> est une
+ <glossary ref="regex">expression rationnelle</glossary>, et
+ l'argument <var>remplacement</var> une chaîne de caractères de
+ remplacement qui peut contenir des références arrières.</dd>
+
+ <dt><code>merge</code></dt>
+ <dd>La valeur d'en-tête est ajoutée à tout en-tête de même nom, sauf
+ si elle apparaît déjà dans la liste des valeurs préexistantes de
+ l'en-tête séparées par des virgules. Lorsqu'une nouvelle valeur est
+ ainsi ajoutée, elle est séparée de celles qui sont déjà présentes
+ par une virgule. Il s'agit de la méthode HTTP standard permettant
+ d'affecter plusieurs valeurs à un en-tête. Les valeurs sont
+ comparées en tenant compte de la casse, et après le traitement de
+ tous les spécificateurs de format. Une valeur entourée de guillemets
+ est considérée comme différente de la même valeur mais sans
+ guillemets.</dd>
+
+ <dt><code>set</code></dt>
+ <dd>L'en-tête est défini, remplaçant tout en-tête préexistant avec
+ le même nom. L'argument <var>valeur</var> peut être une chaîne de
+ formatage.</dd>
+
+ <dt><code>unset</code></dt>
+ <dd>L'en-tête est supprimé s'il existe. Si plusieurs en-têtes
+ possèdent le même nom, ils seront tous supprimés. L'argument
+ <var>value</var> ne doit pas apparaître.</dd>
+ </dl>
+
+ <p>Cet argument est suivi d'un nom d'<var>en-tête</var> qui peut se
+ terminer par un caractère ':', mais ce n'est pas obligatoire. La
+ casse est ignorée avec <code>set</code>, <code>append</code>,
+ <code>merge</code>, <code>add</code>, <code>unset</code> et
+ <code>edit</code>. Le nom d'<var>en-tête</var> est sensible à la
+ casse pour <code>echo</code> et peut être une <glossary
+ ref="regex">expression rationnelle</glossary>.</p>
+
+ <p>Avec <code>set</code>, <code>append</code>, <code>merge</code> et
+ <code>add</code>, une <var>valeur</var> est spécifiée comme
+ troisième argument. Si <var>valeur</var> contient des espaces, elle
+ doit être entourée de guillemets. <var>valeur</var> peut être une
+ chaîne de caractères, une chaîne contenant des spécificateurs de
+ format, ou une combinaison des deux. <var>valeur</var> supporte les
+ spécificateurs de format suivants :</p>
+
+ <table border="1" style="zebra">
+ <columnspec><column width=".25"/><column width=".75"/></columnspec>
+ <tr><th>Format</th><th>Description</th></tr>
+ <tr><td><code>%%</code></td>
+ <td>Le caractère pourcentage</td></tr>
+
+ <tr><td><code>%t</code></td>
+ <td>Le moment de réception de la requête en temps
+ universel coordonné depuis le temps epoch (Jan. 1, 1970) et
+ exprimé en microsecondes. La valeur est précédée de
+ <code>t=</code>.</td></tr>
+
+ <tr><td><code>%D</code></td>
+ <td>Le temps écoulé entre la réception de la requête et l'envoi
+ des en-têtes sur le réseau. Il s'agit de la durée de traitement
+ de la requête. La valeur est précédée de <code>D=</code>. La
+ valeur est exprimée en microsecondes.</td></tr>
+
+ <tr><td><code>%{NOM_VARIABLE}e</code></td>
+ <td>Le contenu de la <a href="../env.html">variable
+ d'environnement</a> <code>NOM_VARIABLE</code>.</td></tr>
+
+ <tr><td><code>%{NOM_VARIABLE}s</code></td>
+ <td>Le contenu de la <a href="../env.html">variable
+ d'environnement SSL</a> <code>NOM_VARIABLE</code>, si
+ <module>mod_ssl</module> est activé.</td></tr>
+
+ </table>
+
+ <note><title>Note</title>
+ <p>Le spécificateur de format <code>%s</code> est disponible
+ depuis la version 2.1 d'Apache ; il peut être utilisé à la place
+ de <code>%e</code> pour éviter de devoir spécifier
+ <code>SSLOptions +StdEnvVars</code>. Cependant, si
+ <code>SSLOptions +StdEnvVars</code> doit tout de même être
+ spécifié pour une raison quelconque, <code>%e</code> sera plus
+ efficace que <code>%s</code>.</p>
+ </note>
+
+ <p><code>edit</code>nécessite les deux arguments
+ <var>valeur</var>, qui est une <glossary ref="regex">expression
+ rationnelle</glossary>, et une chaîne additionnelle
+ <var>remplacement</var>.</p>
+
+ <p>La directive <directive>Header</directive> peut être suivie d'un
+ argument additionnel qui peut prendre les valeurs suivantes :</p>
+
+ <dl>
+ <dt><code>early</code></dt>
+ <dd>Spécifie <a href="#early">traitement préalable</a>.</dd>
+ <dt><code>env=[!]variable</code></dt>
+ <dd>La directive est appliquée si et seulement si la <a
+ href="../env.html">variable d'environnement</a>
+ <code>variable</code> existe. Un <code>!</code> devant
+ <code>variable</code> inverse le test, et la directive ne
+ s'appliquera alors que si <code>variable</code> n'est pas définie.</dd>
+ <dt><code>expr</code></dt>
+ <dd>Une chaîne qui correspond à toute valeur ci-dessus est
+ interprétée comme une expression. Les détails à propos de la syntaxe
+ des expressions et leur évaluation sont pour l'instant mieux
+ documentés dans la page de <module>mod_filter</module>.</dd>
+ </dl>
+
+ <p>Excepté le cas du mode <a href="#early">précoce</a>, les
+ directives <directive>Header</directive> sont traitées juste avant
+ l'envoi de la réponse sur le réseau. Cela signifie qu'il est
+ possible de définir et/ou modifier la plupart des en-têtes, à
+ l'exception de ceux qui sont ajoutés par le filtre d'en-tête.</p>
+</usage>
+</directivesynopsis>
+
+</modulesynopsis>
+
Modified: httpd/httpd/trunk/docs/manual/mod/mod_headers.xml.meta
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_headers.xml.meta?rev=831756&r1=831755&r2=831756&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_headers.xml.meta (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_headers.xml.meta Sun Nov 1 20:13:27 2009
@@ -8,6 +8,7 @@
<variants>
<variant>en</variant>
+ <variant>fr</variant>
<variant outdated="yes">ja</variant>
<variant outdated="yes">ko</variant>
</variants>
Modified: httpd/httpd/trunk/docs/manual/mod/mod_unique_id.html
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_unique_id.html?rev=831756&r1=831755&r2=831756&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_unique_id.html (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_unique_id.html Sun Nov 1 20:13:27 2009
@@ -4,6 +4,10 @@
Content-Language: en
Content-type: text/html; charset=ISO-8859-1
+URI: mod_unique_id.html.fr
+Content-Language: fr
+Content-type: text/html; charset=ISO-8859-1
+
URI: mod_unique_id.html.ja.utf8
Content-Language: ja
Content-type: text/html; charset=UTF-8
Modified: httpd/httpd/trunk/docs/manual/mod/mod_unique_id.html.en
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_unique_id.html.en?rev=831756&r1=831755&r2=831756&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_unique_id.html.en (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_unique_id.html.en Sun Nov 1 20:13:27 2009
@@ -22,6 +22,7 @@
<div id="preamble"><h1>Apache Module mod_unique_id</h1>
<div class="toplang">
<p><span>Available Languages: </span><a href="../en/mod/mod_unique_id.html" title="English"> en </a> |
+<a href="../fr/mod/mod_unique_id.html" hreflang="fr" rel="alternate" title="Français"> fr </a> |
<a href="../ja/mod/mod_unique_id.html" hreflang="ja" rel="alternate" title="Japanese"> ja </a> |
<a href="../ko/mod/mod_unique_id.html" hreflang="ko" rel="alternate" title="Korean"> ko </a></p>
</div>
@@ -208,6 +209,7 @@
</div>
<div class="bottomlang">
<p><span>Available Languages: </span><a href="../en/mod/mod_unique_id.html" title="English"> en </a> |
+<a href="../fr/mod/mod_unique_id.html" hreflang="fr" rel="alternate" title="Français"> fr </a> |
<a href="../ja/mod/mod_unique_id.html" hreflang="ja" rel="alternate" title="Japanese"> ja </a> |
<a href="../ko/mod/mod_unique_id.html" hreflang="ko" rel="alternate" title="Korean"> ko </a></p>
</div><div id="footer">
Added: httpd/httpd/trunk/docs/manual/mod/mod_unique_id.html.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_unique_id.html.fr?rev=831756&view=auto
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_unique_id.html.fr (added)
+++ httpd/httpd/trunk/docs/manual/mod/mod_unique_id.html.fr Sun Nov 1 20:13:27 2009
@@ -0,0 +1,240 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="fr" xml:lang="fr"><head><!--
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ This file is generated from xml source: DO NOT EDIT
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ -->
+<title>mod_unique_id - Serveur Apache HTTP</title>
+<link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
+<link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
+<link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" />
+<link href="../images/favicon.ico" rel="shortcut icon" /></head>
+<body>
+<div id="page-header">
+<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a></p>
+<p class="apache">Serveur Apache HTTP Version 2.3</p>
+<img alt="" src="../images/feather.gif" /></div>
+<div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div>
+<div id="path">
+<a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">Serveur HTTP</a> > <a href="http://httpd.apache.org/docs/">Documentation</a> > <a href="../">Version 2.3</a> > <a href="./">Modules</a></div>
+<div id="page-content">
+<div id="preamble"><h1>Module Apache mod_unique_id</h1>
+<div class="toplang">
+<p><span>Langues Disponibles: </span><a href="../en/mod/mod_unique_id.html" hreflang="en" rel="alternate" title="English"> en </a> |
+<a href="../fr/mod/mod_unique_id.html" title="Français"> fr </a> |
+<a href="../ja/mod/mod_unique_id.html" hreflang="ja" rel="alternate" title="Japanese"> ja </a> |
+<a href="../ko/mod/mod_unique_id.html" hreflang="ko" rel="alternate" title="Korean"> ko </a></p>
+</div>
+<table class="module"><tr><th><a href="module-dict.html#Description">Description:</a></th><td>Fournit une variable d'environnement contenant un
+identifiant unique pour chaque requête</td></tr>
+<tr><th><a href="module-dict.html#Status">Statut:</a></th><td>Extension</td></tr>
+<tr><th><a href="module-dict.html#ModuleIdentifier">Identificateur de Module:</a></th><td>unique_id_module</td></tr>
+<tr><th><a href="module-dict.html#SourceFile">Fichier Source:</a></th><td>mod_unique_id.c</td></tr></table>
+<h3>Sommaire</h3>
+
+
+ <p>Ce module fournit un identifiant dont l'unicité est garantie
+ parmi "toutes" les requêtes sous des conditions très précises.
+ L'identifiant unique le sera aussi parmi plusieurs machines
+ appartenant à un cluster correctement configuré. L'identifiant est
+ affecté à la variable d'environnement <code>UNIQUE_ID</code> pour
+ chaque requête. Les identifiants uniques sont utiles pour diverses
+ raisons dont la nature se situe au delà de la portée de ce
+ document.</p>
+</div>
+<div id="quickview"><h3 class="directives">Directives</h3>
+<p>Ce module ne fournit aucune directive.</p>
+<h3>Sujets</h3>
+<ul id="topics">
+<li><img alt="" src="../images/down.gif" /> <a href="#theory">Théorie</a></li>
+</ul></div>
+<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="theory" id="theory">Théorie</a></h2>
+
+
+ <p>Tout d'abord un bref rappel de la manière dont le serveur Apache
+ fonctionne sous Unix (cette fonctionnalité n'étant actuellement pas
+ supportée sous Windows NT). Sous Unix, Apache crée plusieurs
+ processus enfants, ces derniers traitant les requêtes une par une.
+ Chaque processus enfant peut traiter plusieurs requêtes pendant sa
+ durée de vie. Dans le cadre de cette discussion, nous supposerons
+ que les différents processus enfants ne s'échangent pas de données
+ entre eux. Nous nous référerons aux processus enfants sous le nom de
+ <dfn>processus httpd</dfn>.</p>
+
+ <p>Votre site web est réparti entre une ou plusieurs machines dont
+ vous êtes l'administrateur, et que nous nommerons cluster de
+ serveurs. Chaque serveur peut exécuter plusieurs instances d'Apache.
+ L'ensemble de ces dernières sera considéré comme "l'Univers", et
+ sous certaines hypothèses, nous montrerons qu'il est possible dans
+ cet univers, de générer des identifiants uniques pour chaque
+ requête, sans pour autant nécessiter une communication importante
+ entre les différents serveurs du cluster.</p>
+
+ <p>Les machines de votre cluster doivent satisfaire ces conditions
+ (même si le cluster ne comporte qu'une machine, vous devez
+ synchroniser son horloge avec NTP) :</p>
+
+ <ul>
+ <li>Les temps des machines sont synchronisés via NTP ou tout autre
+ protocole de synchronisation du temps en réseau.</li>
+
+ <li>Les nom d'hôtes des machines sont tous différents, de façon à
+ ce que le module puisse recevoir une adresse IP différente pour
+ chaque machine du cluster en effectuant une recherche sur le nom
+ d'hôte.</li>
+ </ul>
+
+ <p>Au vu des caractéristiques actuelles du système d'exploitation,
+ nous supposerons que les pids (identifiants processus) sont codés
+ sur 32 bits. Si le système d'exploitation utilise plus de 32 bits
+ pour un pid, la correction est triviale mais doit être effectuée
+ dans le code.</p>
+
+ <p>Ces hypothèses posées, à un instant donné, nous pouvons
+ distinguer tout processus httpd sur toute machine du cluster de tous
+ les autres processus httpd. Pour ce faire, il suffit d'utiliser
+ l'adresse IP de la machine et le pid du processus httpd. Ainsi, afin
+ de générer des identifiants uniques pour chaque requête, il suffit
+ d'effectuer une distinction en fonction du temps.</p>
+
+ <p>Pour déterminer le temps, nous utiliserons un repère de temps
+ Unix (les secondes écoulées depuis le 1er janvier 1970 UTC), et un
+ compteur 16 bits. La précision du repère de temps n'étant que d'une
+ seconde, le compteur va représenter 65536 valeurs par seconde. Le
+ quadruplet <em>(adresse IP, pid, repère de temps, compteur)</em> est
+ en mesure de distinguer 65536 requêtes par seconde par processus
+ httpd. Il peut cependant arriver que le même pid soit réutilisé au
+ cours du temps, et le compteur est là pour pallier cet
+ inconvénient.</p>
+
+ <p>Lorsqu'un processus enfant httpd est créé, le compteur est
+ initialisé avec (nombre de microsecondes actuel divisé par 10)
+ modulo 65536 (cette formule a été choisie pour éliminer certains
+ problème de variance avec les bits de poids faibles du compteur de
+ microsecondes sur certains systèmes). Lorsqu'un identifiant unique
+ est généré, le repère de temps utilisé est le moment où la requête
+ arrive sur le serveur web. Le compteur est incrémenté à chaque
+ création d'identifiant (et peut repasser à 0 lorsqu'il a atteint sa
+ valeur maximale).</p>
+
+ <p>Le noyau génère un pid pour chaque processus lors de sa création,
+ et le compteur de pid est réinitialisé à une certaine valeur
+ lorsqu'il a atteint sa valeur maximale (les pid sont codés sur 16
+ bits sous de nombreux Unixes, mais les systèmes les plus récents les
+ ont étendus à 32 bits). La même valeur de pid pourra donc être
+ réutilisée au cours du temps. Cependant, tant qu'elle n'est pas
+ réutilisée dans la même seconde, elle ne remet pas en cause
+ l'unicité de notre quadruplet. Nous supposerons donc que le système
+ ne créera pas plus de 65536 processus en une seconde (ce nombre peut
+ être de 32768 sous certains Unixes, mais même dans ce cas, on est en
+ général loin de cette situation).</p>
+
+ <p>Il est possible que le temps se répète pour une raison
+ quelconque.
+ Supposons par exemple que l'horloge système soit retardée et repasse
+ par un temps passé (ou bien, comme elle avançait, elle a été remise
+ à l'heure, et elle repasse par un temps futur). Dans ce cas, il peut
+ être facilement démontré que le couple pid/repère de temps peut être
+ réutilisé. Le choix de la formule d'initialisation du compteur a
+ été effectué dans l'intention de pallier ce problème. Notez qu'un
+ nombre vraiment aléatoire serait souhaitable pour initialiser le
+ compteur, mais il n'existe pas de tel nombre directement lisible sur
+ la plupart des systèmes (c'est à dire que vous ne pouvez pas
+ utiliser rand() car vous devez déclencher le générateur avec une
+ valeur unique, et vous ne pouvez pas utiliser le temps à cet effet
+ car celui-ci , au moins à la seconde près, s'est répété). Il ne
+ s'agit donc pas d'une défense parfaite.</p>
+
+ <p>Même si elle n'est pas parfaite, quel est le degré d'efficacité
+ de cette défense ? Supposons
+ qu'une de vos machines serve au plus 500 requêtes par seconde (ce
+ qui constitue une limite supérieure très raisonnable au moment où ce
+ document est écrit, car les systèmes ne se contentent en général pas
+ de débiter des fichiers statiques). Pour y parvenir, un certain nombre
+ de processus enfants sera nécessaire, qui dépendra du nombre de
+ clients simultanés présents. Mais soyons pessimiste et supposons
+ qu'un seul processus enfant soit capable de servir 500 requêtes par
+ secondes.
+ Il existe 1000 valeurs de démarrage possibles du compteur pour
+ lesquelles deux séquences de 500 requêtes puissent se recouvrir. Il
+ y a donc 1,5% de chance que le processus enfant répète une valeur de
+ compteur si le temps se répète (avec une résolution d'une seconde),
+ et l'unicité sera alors remise en cause. C'est cependant un exemple
+ très pessimiste, et avec les valeurs du monde réel, il y a bien
+ moins de chances que cela ne se produise. Si vous estimez que ceci a
+ tout de même quelque chances de se produire sur votre système, vous
+ pouvez migrer vers un compteur à 32 bits (en modifiant le code).</p>
+
+ <p>On pourrait supposer que ceci a plus de chance de se produire
+ lors du passage à l'heure d'hiver où l'horloge est "retardée". Cela
+ ne constitue cependant pas un problème car les temps pris en compte
+ ici sont des temps UTC, qui vont "toujours" de l'avant. Notez que
+ les Unixes à base de processeur x86 peuvent nécessiter une
+ configuration particulière pour que ceci soit vrai -- il doivent
+ être configurés pour assumer que l'horloge système est en UTC et
+ compenser de manière appropriée. Mais même dans ce cas, si vous
+ utilisez NTP, votre temps UTC sera correct peu après le
+ redémarrage.</p>
+
+ <p>La variable d'environnement <code>UNIQUE_ID</code> est construite
+ par codage du quadruplet de 112 bits (adresse IP sur 32 bits, pid
+ sur 32 bits, repère de temps sur 32 bits et compteur 16 bits) en
+ utilisant l'alphabet <code>[A-Za-z0-9@-]</code> d'une manière
+ similaire à celle du codage MIME base64, et sa valeur se présente
+ sous la forme d'une chaîne de 19 caractères. L'alphabet MIME base64
+ est en fait <code>[A-Za-z0-9+/]</code> ; cependant, les caractères
+ <code>+</code> et <code>/</code> nécessitent un codage particulier
+ dans les URLs, ce qui rend leur utilisation peu commode. Toutes les
+ valeurs sont codées dans l'ordre des octets d'une adresse réseau de
+ façon à ce
+ que le codage soit comparable entre des architectures où l'ordre des
+ octets est différent. L'ordre réel de codage est : repère de temps,
+ adresse IP, pid, compteur. Cet ordre de codage possède un but
+ précis, mais il faut souligner que les applications n'ont aucun
+ intérêt à entrer dans les détails de ce codage. Les applications
+ doivent se contenter de traiter la variable <code>UNIQUE_ID</code>
+ comme un symbole opaque, qui peut être comparé avec d'autres
+ <code>UNIQUE_ID</code>s en ne testant que leur égalité.</p>
+
+ <p>L'ordre a été choisi de façon à ce qu'il soit possible de
+ modifier le codage dans le futur sans avoir à se préoccuper de
+ conflits éventuels avec une base de données de
+ <code>UNIQUE_ID</code>s existante. Les nouveaux codages doivent
+ conserver le repère de temps comme premier élément, et pour le
+ reste, utiliser les même alphabet et longueur en bits. Comme les
+ repères de temps constituent essentiellement un séquence croissante,
+ il suffit que toutes les machines du cluster arrêtent de servir et
+ de requérir dans la même <em>seconde repère</em>, et n'utilisent
+ alors plus l'ancien format de codage. Ensuite, elles peuvent
+ reprendre le traitement des requêtes en utilisant les nouveaux
+ codages.</p>
+
+ <p>Nous pensons que ceci apporte une solution relativement portable
+ au problème. Elle peut être étendue aux systèmes multithreadés comme
+ Windows NT, et peut évoluer en fonction des besoins futurs. Les
+ identifiants générés possèdent une durée de vie pratiquement infinie
+ car les identifiants futurs pourront être allongés selon les
+ besoins. Pratiquement aucune communication n'est requise entre les
+ machines du cluster (seule la synchronisation NTP est requise, ce
+ qui représente une charge très faible), et aucune communication
+ entre les processus httpd n'est nécessaire (la communication est
+ implicite et incluse dans le pid assigné par le noyau). Dans des
+ situations très spécifiques, l'identifiant peut être raccourci, mais
+ dans ce cas, d'avantage d'informations doivent être admises (par
+ exemple, les 32 bits de l'adresse IP sont excessifs pour la plupart
+ des sites, mais il n'existe pas de valeur de remplacement portable
+ plus courte).</p>
+</div>
+</div>
+<div class="bottomlang">
+<p><span>Langues Disponibles: </span><a href="../en/mod/mod_unique_id.html" hreflang="en" rel="alternate" title="English"> en </a> |
+<a href="../fr/mod/mod_unique_id.html" title="Français"> fr </a> |
+<a href="../ja/mod/mod_unique_id.html" hreflang="ja" rel="alternate" title="Japanese"> ja </a> |
+<a href="../ko/mod/mod_unique_id.html" hreflang="ko" rel="alternate" title="Korean"> ko </a></p>
+</div><div id="footer">
+<p class="apache">Copyright 2009 The Apache Software Foundation.<br />Autorisé sous <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
+<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a></p></div>
+</body></html>
\ No newline at end of file
Added: httpd/httpd/trunk/docs/manual/mod/mod_unique_id.xml.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_unique_id.xml.fr?rev=831756&view=auto
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_unique_id.xml.fr (added)
+++ httpd/httpd/trunk/docs/manual/mod/mod_unique_id.xml.fr Sun Nov 1 20:13:27 2009
@@ -0,0 +1,225 @@
+<?xml version="1.0"?>
+<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
+<!-- English Revision : 420990 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<modulesynopsis metafile="mod_unique_id.xml.meta">
+
+<name>mod_unique_id</name>
+<description>Fournit une variable d'environnement contenant un
+identifiant unique pour chaque requête</description>
+<status>Extension</status>
+<sourcefile>mod_unique_id.c</sourcefile>
+<identifier>unique_id_module</identifier>
+
+<summary>
+
+ <p>Ce module fournit un identifiant dont l'unicité est garantie
+ parmi "toutes" les requêtes sous des conditions très précises.
+ L'identifiant unique le sera aussi parmi plusieurs machines
+ appartenant à un cluster correctement configuré. L'identifiant est
+ affecté à la variable d'environnement <code>UNIQUE_ID</code> pour
+ chaque requête. Les identifiants uniques sont utiles pour diverses
+ raisons dont la nature se situe au delà de la portée de ce
+ document.</p>
+</summary>
+
+<section id="theory">
+ <title>Théorie</title>
+
+ <p>Tout d'abord un bref rappel de la manière dont le serveur Apache
+ fonctionne sous Unix (cette fonctionnalité n'étant actuellement pas
+ supportée sous Windows NT). Sous Unix, Apache crée plusieurs
+ processus enfants, ces derniers traitant les requêtes une par une.
+ Chaque processus enfant peut traiter plusieurs requêtes pendant sa
+ durée de vie. Dans le cadre de cette discussion, nous supposerons
+ que les différents processus enfants ne s'échangent pas de données
+ entre eux. Nous nous référerons aux processus enfants sous le nom de
+ <dfn>processus httpd</dfn>.</p>
+
+ <p>Votre site web est réparti entre une ou plusieurs machines dont
+ vous êtes l'administrateur, et que nous nommerons cluster de
+ serveurs. Chaque serveur peut exécuter plusieurs instances d'Apache.
+ L'ensemble de ces dernières sera considéré comme "l'Univers", et
+ sous certaines hypothèses, nous montrerons qu'il est possible dans
+ cet univers, de générer des identifiants uniques pour chaque
+ requête, sans pour autant nécessiter une communication importante
+ entre les différents serveurs du cluster.</p>
+
+ <p>Les machines de votre cluster doivent satisfaire ces conditions
+ (même si le cluster ne comporte qu'une machine, vous devez
+ synchroniser son horloge avec NTP) :</p>
+
+ <ul>
+ <li>Les temps des machines sont synchronisés via NTP ou tout autre
+ protocole de synchronisation du temps en réseau.</li>
+
+ <li>Les nom d'hôtes des machines sont tous différents, de façon à
+ ce que le module puisse recevoir une adresse IP différente pour
+ chaque machine du cluster en effectuant une recherche sur le nom
+ d'hôte.</li>
+ </ul>
+
+ <p>Au vu des caractéristiques actuelles du système d'exploitation,
+ nous supposerons que les pids (identifiants processus) sont codés
+ sur 32 bits. Si le système d'exploitation utilise plus de 32 bits
+ pour un pid, la correction est triviale mais doit être effectuée
+ dans le code.</p>
+
+ <p>Ces hypothèses posées, à un instant donné, nous pouvons
+ distinguer tout processus httpd sur toute machine du cluster de tous
+ les autres processus httpd. Pour ce faire, il suffit d'utiliser
+ l'adresse IP de la machine et le pid du processus httpd. Ainsi, afin
+ de générer des identifiants uniques pour chaque requête, il suffit
+ d'effectuer une distinction en fonction du temps.</p>
+
+ <p>Pour déterminer le temps, nous utiliserons un repère de temps
+ Unix (les secondes écoulées depuis le 1er janvier 1970 UTC), et un
+ compteur 16 bits. La précision du repère de temps n'étant que d'une
+ seconde, le compteur va représenter 65536 valeurs par seconde. Le
+ quadruplet <em>(adresse IP, pid, repère de temps, compteur)</em> est
+ en mesure de distinguer 65536 requêtes par seconde par processus
+ httpd. Il peut cependant arriver que le même pid soit réutilisé au
+ cours du temps, et le compteur est là pour pallier cet
+ inconvénient.</p>
+
+ <p>Lorsqu'un processus enfant httpd est créé, le compteur est
+ initialisé avec (nombre de microsecondes actuel divisé par 10)
+ modulo 65536 (cette formule a été choisie pour éliminer certains
+ problème de variance avec les bits de poids faibles du compteur de
+ microsecondes sur certains systèmes). Lorsqu'un identifiant unique
+ est généré, le repère de temps utilisé est le moment où la requête
+ arrive sur le serveur web. Le compteur est incrémenté à chaque
+ création d'identifiant (et peut repasser à 0 lorsqu'il a atteint sa
+ valeur maximale).</p>
+
+ <p>Le noyau génère un pid pour chaque processus lors de sa création,
+ et le compteur de pid est réinitialisé à une certaine valeur
+ lorsqu'il a atteint sa valeur maximale (les pid sont codés sur 16
+ bits sous de nombreux Unixes, mais les systèmes les plus récents les
+ ont étendus à 32 bits). La même valeur de pid pourra donc être
+ réutilisée au cours du temps. Cependant, tant qu'elle n'est pas
+ réutilisée dans la même seconde, elle ne remet pas en cause
+ l'unicité de notre quadruplet. Nous supposerons donc que le système
+ ne créera pas plus de 65536 processus en une seconde (ce nombre peut
+ être de 32768 sous certains Unixes, mais même dans ce cas, on est en
+ général loin de cette situation).</p>
+
+ <p>Il est possible que le temps se répète pour une raison
+ quelconque.
+ Supposons par exemple que l'horloge système soit retardée et repasse
+ par un temps passé (ou bien, comme elle avançait, elle a été remise
+ à l'heure, et elle repasse par un temps futur). Dans ce cas, il peut
+ être facilement démontré que le couple pid/repère de temps peut être
+ réutilisé. Le choix de la formule d'initialisation du compteur a
+ été effectué dans l'intention de pallier ce problème. Notez qu'un
+ nombre vraiment aléatoire serait souhaitable pour initialiser le
+ compteur, mais il n'existe pas de tel nombre directement lisible sur
+ la plupart des systèmes (c'est à dire que vous ne pouvez pas
+ utiliser rand() car vous devez déclencher le générateur avec une
+ valeur unique, et vous ne pouvez pas utiliser le temps à cet effet
+ car celui-ci , au moins à la seconde près, s'est répété). Il ne
+ s'agit donc pas d'une défense parfaite.</p>
+
+ <p>Même si elle n'est pas parfaite, quel est le degré d'efficacité
+ de cette défense ? Supposons
+ qu'une de vos machines serve au plus 500 requêtes par seconde (ce
+ qui constitue une limite supérieure très raisonnable au moment où ce
+ document est écrit, car les systèmes ne se contentent en général pas
+ de débiter des fichiers statiques). Pour y parvenir, un certain nombre
+ de processus enfants sera nécessaire, qui dépendra du nombre de
+ clients simultanés présents. Mais soyons pessimiste et supposons
+ qu'un seul processus enfant soit capable de servir 500 requêtes par
+ secondes.
+ Il existe 1000 valeurs de démarrage possibles du compteur pour
+ lesquelles deux séquences de 500 requêtes puissent se recouvrir. Il
+ y a donc 1,5% de chance que le processus enfant répète une valeur de
+ compteur si le temps se répète (avec une résolution d'une seconde),
+ et l'unicité sera alors remise en cause. C'est cependant un exemple
+ très pessimiste, et avec les valeurs du monde réel, il y a bien
+ moins de chances que cela ne se produise. Si vous estimez que ceci a
+ tout de même quelque chances de se produire sur votre système, vous
+ pouvez migrer vers un compteur à 32 bits (en modifiant le code).</p>
+
+ <p>On pourrait supposer que ceci a plus de chance de se produire
+ lors du passage à l'heure d'hiver où l'horloge est "retardée". Cela
+ ne constitue cependant pas un problème car les temps pris en compte
+ ici sont des temps UTC, qui vont "toujours" de l'avant. Notez que
+ les Unixes à base de processeur x86 peuvent nécessiter une
+ configuration particulière pour que ceci soit vrai -- il doivent
+ être configurés pour assumer que l'horloge système est en UTC et
+ compenser de manière appropriée. Mais même dans ce cas, si vous
+ utilisez NTP, votre temps UTC sera correct peu après le
+ redémarrage.</p>
+
+ <p>La variable d'environnement <code>UNIQUE_ID</code> est construite
+ par codage du quadruplet de 112 bits (adresse IP sur 32 bits, pid
+ sur 32 bits, repère de temps sur 32 bits et compteur 16 bits) en
+ utilisant l'alphabet <code>[A-Za-z0-9@-]</code> d'une manière
+ similaire à celle du codage MIME base64, et sa valeur se présente
+ sous la forme d'une chaîne de 19 caractères. L'alphabet MIME base64
+ est en fait <code>[A-Za-z0-9+/]</code> ; cependant, les caractères
+ <code>+</code> et <code>/</code> nécessitent un codage particulier
+ dans les URLs, ce qui rend leur utilisation peu commode. Toutes les
+ valeurs sont codées dans l'ordre des octets d'une adresse réseau de
+ façon à ce
+ que le codage soit comparable entre des architectures où l'ordre des
+ octets est différent. L'ordre réel de codage est : repère de temps,
+ adresse IP, pid, compteur. Cet ordre de codage possède un but
+ précis, mais il faut souligner que les applications n'ont aucun
+ intérêt à entrer dans les détails de ce codage. Les applications
+ doivent se contenter de traiter la variable <code>UNIQUE_ID</code>
+ comme un symbole opaque, qui peut être comparé avec d'autres
+ <code>UNIQUE_ID</code>s en ne testant que leur égalité.</p>
+
+ <p>L'ordre a été choisi de façon à ce qu'il soit possible de
+ modifier le codage dans le futur sans avoir à se préoccuper de
+ conflits éventuels avec une base de données de
+ <code>UNIQUE_ID</code>s existante. Les nouveaux codages doivent
+ conserver le repère de temps comme premier élément, et pour le
+ reste, utiliser les même alphabet et longueur en bits. Comme les
+ repères de temps constituent essentiellement un séquence croissante,
+ il suffit que toutes les machines du cluster arrêtent de servir et
+ de requérir dans la même <em>seconde repère</em>, et n'utilisent
+ alors plus l'ancien format de codage. Ensuite, elles peuvent
+ reprendre le traitement des requêtes en utilisant les nouveaux
+ codages.</p>
+
+ <p>Nous pensons que ceci apporte une solution relativement portable
+ au problème. Elle peut être étendue aux systèmes multithreadés comme
+ Windows NT, et peut évoluer en fonction des besoins futurs. Les
+ identifiants générés possèdent une durée de vie pratiquement infinie
+ car les identifiants futurs pourront être allongés selon les
+ besoins. Pratiquement aucune communication n'est requise entre les
+ machines du cluster (seule la synchronisation NTP est requise, ce
+ qui représente une charge très faible), et aucune communication
+ entre les processus httpd n'est nécessaire (la communication est
+ implicite et incluse dans le pid assigné par le noyau). Dans des
+ situations très spécifiques, l'identifiant peut être raccourci, mais
+ dans ce cas, d'avantage d'informations doivent être admises (par
+ exemple, les 32 bits de l'adresse IP sont excessifs pour la plupart
+ des sites, mais il n'existe pas de valeur de remplacement portable
+ plus courte).</p>
+</section>
+
+
+</modulesynopsis>
Modified: httpd/httpd/trunk/docs/manual/mod/mod_unique_id.xml.meta
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_unique_id.xml.meta?rev=831756&r1=831755&r2=831756&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_unique_id.xml.meta (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_unique_id.xml.meta Sun Nov 1 20:13:27 2009
@@ -8,6 +8,7 @@
<variants>
<variant>en</variant>
+ <variant>fr</variant>
<variant>ja</variant>
<variant outdated="yes">ko</variant>
</variants>