En général, cela n'a que peu d'effet, à moins que vous n'utilisiez les
<a href="howto/ssi.html">Inclusions Côté Serveur (SSI)</a>;</p>
- <div class="example"><pre>
-<!-- L'inclusion suivante peut être mise en cache -->
-<!--#include virtual="/footer.html" -->
-
-<!-- L'inclusion suivante ne peut pas être mise en cache -->
-<!--#include file="/path/to/footer.html" --></pre></div>
+ <div class="example"><p><code>
+<!-- L'inclusion suivante peut être mise en cache --><br />
+<!--#include virtual="/footer.html" --><br />
+<br />
+<!-- L'inclusion suivante ne peut pas être mise en cache --><br />
+<!--#include file="/path/to/footer.html" --> <br />
+ </code></p></div>
<p>Si vous utilisez les SSI, et voulez bénéficier de la vitesse de
service depuis le cache, vous devez utiliser des inclusions de type
de fichier élaboré à cette occasion pour tous les
accès ultérieurs à ce fichier.</p>
- <div class="example"><pre>CacheFile /usr/local/apache2/htdocs/index.html</pre></div>
+ <div class="example"><p><code>
+ CacheFile /usr/local/apache2/htdocs/index.html
+ </code></p></div>
<p>Si vous avez l'intention de mettre en cache un grand nombre de
fichiers de cette manière, vous devez vous assurer que le nombre maximum
utilisera le contenu chargé en mémoire pour satisfaire ultérieurement
toutes les demandes d'accès à ce fichier.</p>
- <div class="example"><pre>MMapFile /usr/local/apache2/htdocs/index.html</pre></div>
+ <div class="example"><p><code>
+ MMapFile /usr/local/apache2/htdocs/index.html
+ </code></p></div>
<p>Comme dans le cas de la directive
<code class="directive"><a href="./mod/mod_file_cache.html#cachefile">CacheFile</a></code>, toute
<p>Typiquement, le module sera configuré comme suit :</p>
- <div class="example"><pre>
-CacheRoot /var/cache/apache/
-CacheEnable disk /
-CacheDirLevels 2
-CacheDirLength 1</pre></div>
+ <div class="example"><p><code>
+CacheRoot /var/cache/apache/<br />
+CacheEnable disk /<br />
+CacheDirLevels 2<br />
+CacheDirLength 1
+ </code></p></div>
<p>Il est important de savoir que, les fichiers mis en cache étant stockés
localement, la mise en cache par l'intermédiaire du système d'exploitation
distribués seront alors compilés en tant que modules DSO. Une fois
compilé en tant que module DSO nommé <code>mod_foo.so</code>, un
module peut être chargé en mémoire au
- démarrage ou redémarrage du serveur à l'aide de la commande
- <code class="directive"><a href="./mod/mod_so.html#loadmodule">LoadModule</a></code> du module
+ démarrage ou redémarrage du serveur à l'aide de
+
la directive <code class="directive"><a href="./mod/mod_so.html#loadmodule">LoadModule</a></code> du module
<code class="module"><a href="./mod/mod_so.html">mod_so</a></code>, placée
dans votre fichier <code>httpd.conf</code>.</p>
<p>La compilation en mode DSO peut être désactivée pour certains
<div class="section">
<h2><a name="background" id="background">Les dessous du fonctionnement des DSO</a></h2>
- <p>Les clônes modernes d'UNIX proposent un astucieux mécanisme
- communément appelé édition de liens et chargement dynamiques d'
+ <p>Les clônes modernes d'UNIX proposent un mécanisme
+ appelé édition de liens et chargement dynamiques d'
<em>Objets Dynamiques Partagés</em> (DSO), qui permet de construire un
morceau de programme dans un format spécial pour le rendre chargeable
à l'exécution dans l'espace d'adressage d'un programme exécutable.</p>
c'est dans cette optique que le mécanisme DSO a été conçu ; c'est cette
approche qui est ainsi
utilisée par pratiquement tous les types de bibliothèques que fournit le
- système d'exploitation. Par contre, les objets partagés sont relativement
- peu utilisés pour étendre les fonctionnalités d'un programme.</p>
+ système d'exploitation.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<ul>
<li>Le paquetage du serveur est plus flexible à l'exécution car le
- processus serveur effectif peut être assemblé à l'exécution via la
+ processus serveur peut être assemblé à l'exécution via la
directive <code class="directive"><a href="./mod/mod_so.html#loadmodule">LoadModule</a></code> du fichier de
configuration <code>httpd.conf</code> plutôt que par des options du script
<code class="program"><a href="./programs/configure.html">configure</a></code> à la compilation. Par exemple,
on peut ainsi exécuter différentes instances du serveur
- (standard et version SSL, version minimale et version étoffée
- [mod_perl, PHP3], <em>etc...</em>) à partir d'une seule installation
+ (standard et version SSL, version minimale et version dynamique
+ [mod_perl, mod_php], <em>etc...</em>) à partir d'une seule installation
d'Apache httpd.</li>
<li>Le paquetage du serveur peut être facilement étendu avec des modules
- tiers, même après l'installation. Ceci présente en tout cas un gros
+ tiers, même après l'installation. Ceci présente un gros
avantage pour les mainteneurs de paquetages destinés aux distributions,
car ils peuvent créer un paquetage Apache httpd de base, et des paquetages
additionnels contenant des extensions telles que PHP, mod_perl, mod_fastcgi,
<em>etc...</em></li>
- <li>Une facilité de prototypage des modules Apache httpd car la paire
+ <li>Une facilité de prototypage des modules Apache httpd, car la paire
DSO/<code class="program"><a href="./programs/apxs.html">apxs</a></code> vous permet d'une part de travailler en
dehors de l'arborescence des sources d'Apache httpd, et d'autre part de n'avoir
besoin que de la commande <code>apxs -i</code>
<p>Inconvénients des DSO :</p>
<ul>
- <li>Le mécanisme DSO n'est pas disponible sur toutes les plates-formes
- car tous les systèmes d'exploitation ne supportent pas le chargement
- dynamique de code dans l'espace d'adressage d'un programme.</li>
-
<li>Le serveur est environ 20 % plus lent au démarrage
à cause des résolutions de symboles supplémentaires que le chargeur
Unix doit effectuer.</li>
<div id="path">
<a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs/">Documentation</a> > <a href="./">Version 2.3</a></div><div id="page-content"><div id="preamble"><h1>Expressions in Apache HTTP Server</h1>
<div class="toplang">
-<p><span>Available Languages: </span><a href="./en/expr.html" title="English"> en </a></p>
+<p><span>Available Languages: </span><a href="./en/expr.html" title="English"> en </a> |
+<a href="./fr/expr.html" hreflang="fr" rel="alternate" title="Français"> fr </a></p>
</div>
<p>Historically, there are several syntax variants for expressions used to express
</div></div>
<div class="bottomlang">
-<p><span>Available Languages: </span><a href="./en/expr.html" title="English"> en </a></p>
+<p><span>Available Languages: </span><a href="./en/expr.html" title="English"> en </a> |
+<a href="./fr/expr.html" hreflang="fr" rel="alternate" title="Français"> fr </a></p>
</div><div id="footer">
<p class="apache">Copyright 2011 The Apache Software Foundation.<br />Licensed under the <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">Glossary</a> | <a href="./sitemap.html">Sitemap</a></p></div>
<dl><dd><code>Alias /icons/ /usr/local/apache/icons/</code></dd></dl>
<p>l'alias précédent ne s'appliquera pas à l'url
- <code>/icons</code>.</p>
+ <code>/icons</code> à cause de l'absence du slash final. Ainsi, si
+ le slash final est absent du <var>chemin de l'URL</var>, il doit
+ aussi l'être du <var>chemin du fichier</var>.</p>
<p>Notez qu'il pourra s'avérer nécessaire de définir des sections
<code class="directive"><a href="../mod/core.html#directory"><Directory></a></code>
0.</dd>
<dt><code>qs</code></dt>
- <dd>a floating-point number with a value in the range 0.0
- to 1.0, indicating the relative 'quality' of this variant
+ <dd>a floating-point number with a value in the range 0[.000]
+ to 1[.000], indicating the relative 'quality' of this variant
compared to the other available variants, independent of
the client's capabilities. For example, a jpeg file is
usually of higher source quality than an ascii file if it
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 420990:1029134 (outdated) -->
+<!-- English Revision: 420990:1066440 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
encoding. This allows the request to be efficiently streamed,
but requires that the backend server supports HTTP/1.1.</dd>
<dt>proxy-interim-response</dt>
- <dd>This variable takes values <code>RFC</code> or
+ <dd>This variable takes values <code>RFC</code> (the default) or
<code>Suppress</code>. Earlier httpd versions would suppress
HTTP interim (1xx) responses sent from the backend. This is
technically a violation of the HTTP protocol. In practice,
<p>La directive <code class="directive">RewriteBase</code> définit
explicitement le chemin URL de base (et non le chemin du
répertoire dans le système de fichiers !) pour les réécritures dans un contexte
- de répertoire. Lorsque vous utilisez une directive <code class="directive"><a href="#rewriterule">RewriteRule</a></code> dans un fichier
+ de répertoire dont le résultat est la substitution d'un
+ chemin relatif. Lorsque vous utilisez une directive <code class="directive"><a href="#rewriterule">RewriteRule</a></code> dans un fichier
<code>.htaccess</code>, <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> enlève le
préfixe de répertoire local avant d'effectuer le traitement, puis
réécrit ce qui reste de l'URL. Lorsque la réécriture est terminée,
- <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> rajoute automatiquement le préfixe de
- répertoire local au chemin.</p>
+ <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> ajoute automatiquement le préfixe de
+ répertoire local (ou la valeur de la directive
+ <code class="directive">RewriteBase</code> si cette dernière est définie)
+ à la chaîne de substitution avant de la remettre à disposition du
+ serveur, comme s'il s'agissait de l'URL d'origine.</p>
<p>Cette directive est <em>requise</em> pour les réécritures
dans un contexte de répertoire défini via la directive
- <code class="directive"><a href="../mod/mod_alias.html#alias">Alias</a></code>.</p>
+ <code class="directive"><a href="../mod/mod_alias.html#alias">Alias</a></code> lorsque la
+ substitution utilise un chemin relatif.</p>
<p>Si votre chemin URL n'existe pas réellement dans le système de
fichiers, ou ne trouve pas directement sous le répertoire défini
REQUEST_FILENAME<br />
IS_SUBREQ<br />
HTTPS<br />
+ REQUEST_SCHEME<br />
</td>
</tr>
</table>
HTTP de mêmes noms, au variables C du serveur HTTP Apache, ou
aux champs <code>struct tm</code> du système Unix. La
plupart d'entre elles sont documentées ailleurs dans le
- manuel ou dans la spécification CGI. Parmi les variables
+ manuel ou dans la spécification CGI.</p>
+
+ <p>SERVER_NAME et SERVER_PORT dépendent respectivement
+ des valeurs des directives <code class="directive"><a href="../mod/core.html#usecanonicalname">UseCanonicalName</a></code> et <code class="directive"><a href="../mod/core.html#usecanonicalphysicalport">UseCanonicalPhysicalPort</a></code>.</p>
+
+ <p>Parmi les variables
spécifiques à mod_rewrite, ou trouve les suivantes :</p>
<div class="note">
<dl>
(Cette variable peut être utilisée sans problème, que
<code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> soit chargé ou non.</dd>
+ <dt><code>REQUEST_SCHEME</code></dt>
+
+ <dd>Contient le protocole de la requête (en général
+ "http" ou "https"). La valeur peut être modifiée par
+ la directive <code class="directive"><a href="../mod/core.html#servername">ServerName</a></code>.</dd>
+
</dl>
</div>
</li>
</ul>
+ <p>Si la <em>chaîne de test</em> contient la valeur spéciale
+ <code>expr</code>, <em>expression de comparaison</em> sera traité
+ en tant qu'expression rationnelle de type <a href="../expr.html">ap_expr</a>.</p>
+
<p>Autres points à connaître ::</p>
<ol>
<li>
</div>
</li>
+ <li>
+ <p>Si la <em>chaîne de test</em> contient la valeur spéciale
+ <code>expr</code>, la <em>chaîne de comparaison</em> sera
+ traitée en tant qu'expression rationnelle de type <a href="../expr.html">ap_expr</a>.</p>
+
+ <p>
+ Dans l'exemple ci-dessous, on utilise <code>-strmatch</code>
+ pour comparer le <code>REFERER</code> avec le nom d'hôte du
+ site afin de bloquer le hotlinking (référencement direct)
+ non désiré.
+ </p>
+
+ <div class="example"><p><code>
+ RewriteCond expr "! %{HTTP_REFERER} -strmatch '*://%{HTTP_HOST}/*'"<br />
+ RewriteRule ^/images - [F]
+ </code></p></div>
+ </li>
+
<li>Vous pouvez aussi définir certains drapeaux pour
l'<em>expression de comparaison</em> en ajoutant ces
<strong><code>[</code><em>drapeaux</em><code>]</code></strong>
<p><a id="patterns" name="patterns"><em>Modèle</em></a> est une
<a id="regexp" name="regexp">expression rationnelle</a>
compatible perl. Dans la première règle de réécriture,
- l'expression est comparée au (%-encoded)
+ l'expression est comparée au (%-decoded)
<a href="./directive-dict.html#Syntax">chemin de l'URL</a> de la
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>
<div class="note"><h3>Qu'est-ce qui est comparé ?</h3>
- <p>Le <em>Modèle</em> est d'abord comparé à la partie
- de l'URL après le nom d'hôte et le port, et avant la chaîne de
- requête.</p>
-
- <p>Dans un contexte de répertoire, <em>Modèle</em> est comparé à
- ce qui reste de l'URL après suppression du préfixe qui a conduit
- Apache httpd à la règle courante (voir la directive <code class="directive"><a href="#rewritebase">RewriteBase</a></code>). Le préfixe supprimé
- se termine toujours par un slash, ce qui signifie que la
- correspondance se fera toujours avec une chaîne qui ne commence
- pas par un slash. Un <em>Modèle</em> contenant <code>^/</code> ne
- correspondra jamais dans un contexte de répertoire.</p>
+ <p>Dans un contexte de serveur virtuel <code class="directive"><a href="../mod/core.html#virtualhost">VirtualHost</a></code>, le <em>modèle</em> est tout
+ d'abord comparé à la portion de l'URL située entre le nom d'hôte
+ éventuellement accompagné du port, et la chaîne de paramètres (par
+ exemple "/app1/index.html").</p>
+
+ <p>Dans les contextes de répertoire <code class="directive"><a href="../mod/core.html#directory">Directory</a></code> et htaccess, le
+ <em>modèle</em> est tout d'abord comparé au chemin du <em>système
+ de fichiers</em>, après suppression du préfixe ou chemin de base
+ ayant conduit à la règle <code class="directive">RewriteRule</code> (par
+ exemple "app1/index.html" ou
+ "index.html" selon l'endroit où les directives sont définies).</p>
<p>Si vous souhaitez faire une comparaison sur le nom
d'hôte, le port, ou la chaîne de requête, utilisez une
directive <code class="directive"><a href="#rewritecond">RewriteCond</a></code>
comportant respectivement les variables
<code>%{HTTP_HOST}</code>, <code>%{SERVER_PORT}</code>, ou
- <code>%{QUERY_STRING}</code>. Si vous désirez effectuer une
- correspondance avec l'ensemble du chemin de l'URL dans un contexte
- de répertoire (htaccess), utilisez la variable
- <code>%{REQUEST_URI}</code>.</p>
+ <code>%{QUERY_STRING}</code>.</p>
+</div>
+
+<div class="note"><h3>Réécritures dans un contexte de répertoire</h3>
+<ul>
+<li>L'utilisation du moteur de réécriture dans les
+fichiers <a href="../howto/htaccess.html">.htaccess</a> et les sections
+<code class="directive"><a href="../mod/core.html#directory"><Directory></a></code> est un peu plus
+complexe.</li>
+
+<li>Pour activer le moteur de réécriture dans ces contextes, vous devez
+définir "<code>RewriteEngine On</code>" <strong>et</strong>
+"<code>Options FollowSymLinks</code>". Si l'administrateur a désactivé
+la possibilité de modifier l'option <code>FollowSymLinks</code> au
+niveau du répertoire d'un utilisateur, vous ne pouvez pas utiliser le
+moteur de réécriture. Cette restriction a été instaurée à des fins de
+sécurité.</li>
+
+<li>Lorsqu'on utilise le moteur de réécriture dans un fichier
+<code>.htaccess</code>, le chemin de base du répertoire courant (qui est
+toujours le même pour ce même répertoire) est automatiquement
+<em>supprimé</em> au cours de la comparaison avec le modèle de la règle
+de réécriture, et automatiquement <em>ajouté</em> lorsqu'une
+substitution relative (ne débutant pas par un slash ou un nom de
+protocole) arrive à la fin d'un jeu de règles. Voir la directive
+<code class="directive"><a href="#rewritebase">RewriteBase</a></code> pour plus de
+détails à propos de l'ajout du préfixe après les substitutions
+relatives.</li>
+
+<li>Si vous souhaitez effectuer une comparaison en prenant en compte
+l'intégralité du
+chemin de l'URL dans un contexte de répertoire (htaccess), vous devez
+utiliser la variable <code>%{REQUEST_URI}</code> dans la directive
+<code class="directive">RewriteCond</code>.</li>
+
+<li>Le prefixe supprimé se termine toujours par un slash, ce qui
+signifie que la comparaison s'effectue avec une chaîne qui ne comporte
+<em>jamais</em> de slash de début. Ainsi, un <em>modèle</em> contenant
+<code>^/</code> ne correspondra jamais dans un contexte de répertoire.</li>
+
+<li>Bien que les règles de réécriture soient permises du point de vue de
+la syntaxe dans les sections <code class="directive"><a href="../mod/core.html#location"><Location></a></code> et <code class="directive"><a href="../mod/core.html#files"><Files></a></code>, elles n'y sont pas prises en compte, et
+n'y sont à priori d'aucune utilité.</li>
+</ul>
</div>
<p>Pour quelques conseils à propos des <a class="glossarylink" href="../glossary.html#regex" title="voir glossaire">expressions rationnelles</a>, voir le
</td>
</tr>
<tr>
- <td>discardpathinfo|DPI</td>
+ <td>discardpath|DPI</td>
<td>Supprime la partie PATH_INFO de l'URI réécrit. <em><a href="../rewrite/flags.html#flag_dpi">détails
...</a></em></td>
</tr>
<tr>
- <td>env|E=<em>VAR</em>[:<em>VAL</em>]</td>
+ <td>env|E=[!]<em>VAR</em>[:<em>VAL</em>]</td>
<td>Définit la variable d'environnement <em>VAR</em> (à la valeur
- <em>VAL</em> si elle est fournie). <em><a href="../rewrite/flags.html#flag_e">détails ...</a></em></td>
+ <em>VAL</em> si elle est fournie). La variante !<em>VAR</em>
+ annule la définition de la variable <em>VAR</em>.<em><a href="../rewrite/flags.html#flag_e">détails ...</a></em></td>
</tr>
<tr>
<td>forbidden|F</td>
<p> Ce développement n'est pas effectué si le drapeau <em>PT</em> est
utilisé dans la directive <code class="directive"><a href="#rewriterule">RewriteRule</a></code></p>
-</div>
-
-<div class="note"><h3>Réécritures dans le contexte de répertoire</h3>
-
-<p>Le moteur de réécriture peut être utilisé dans les fichiers <a href="../howto/htaccess.html">.htaccess</a>. Pour activer le moteur de
-réécriture pour ces fichiers, vous devez préciser "<code>RewriteEngine
-On</code>" <strong>et</strong> "<code>Options FollowSymLinks</code>"
-doit être activé. Si votre administrateur a interdit la surcharge de
-<code>FollowSymLinks</code> pour un répertoire utilisateur, vous ne
-pouvez pas utiliser le moteur de réécriture. Cette restriction est
-nécessaire pour des raisons de sécurité.</p>
-
-<p>Lorsqu'on utilise le moteur de réécriture dans les fichiers
-<code>.htaccess</code>, le préfixe du répertoire (qui est
-toujours le même pour un répertoire donné) est automatiquement
-<em>supprimé</em> pour la comparaison du modèle et automatiquement
-<em>ajouté</em> une fois la substitution effectuée. Cette fonctionnalité
-est nécessaire pour de nombreux cas de réécriture ; sans elle, vous
-seriez obligé de tenir compte du répertoire parent pour la comparaison,
-ce qui n'est pas toujours
-possible. Il y a une exception : si une chaîne de substitution commence
-par <code>http://</code>, le préfixe du répertoire ne sera
-<strong>pas</strong> ajouté, et une redirection externe (ou le passage
-par un mandataire, si le drapeau <strong>P</strong> est utilisé) sera
-initiée. Voir la directive <code class="directive"><a href="#rewritebase">RewriteBase</a></code> pour plus de détails.</p>
-
-<p>Le moteur de réécriture peut aussi être utilisé dans les sections
-<code class="directive"><a href="../mod/core.html#directory"><Directory></a></code> avec les
-mêmes règles de comparaison des préfixes que celles qui s'appliquent
-pour les fichiers <code>.htaccess</code>. Cependant, il est en général
-plus simple, pour éviter la complication des substitutions de préfixes,
-de définir les règles de réécriture dans le contexte du serveur
-principal ou des hôtes virtuels, plutôt que dans une section
-<code class="directive"><a href="../mod/core.html#directory"><Directory></a></code>.</p>
-
-<p>Bien que du point de vue syntaxique, il soit permis de définir des
-règles de réécriture dans les sections <code class="directive"><a href="../mod/core.html#location"><Location></a></code> et <code class="directive"><a href="../mod/core.html#files"><Files></a></code>, ce n'est à priori
-d'aucune utilité et n'est pas supporté.</p>
-
</div>
<p>Voici toutes les combinaisons de substitution et leurs
<p>La syntaxe complète pour ce drapeau est :</p>
<div class="example"><p><code>
-[E=VAR:VAL]
+[E=!VAR]
</code></p></div>
<p><code>VAL</code> peut comporter des références arrières
<p>vous pouvez définir la variable d'environnement nommée
<code>VAR</code> avec une valeur vide.</p>
+<p>La forme</p>
+
+<div class="example"><p><code>
+[E=!VAR]
+</code></p></div>
+
+<p>permet d'annuler la définition de la variable <code>VAR</code>.</p>
+
<p>Les variables d'environnement s'emploient dans différents contextes,
comme les programmes CGI, d'autres directives RewriteRule, ou des
directives CustomLog.</p>
<p><span>Langues Disponibles: </span><a href="./en/upgrading.html" hreflang="en" rel="alternate" title="English"> en </a> |
<a href="./fr/upgrading.html" title="Français"> fr </a></p>
</div>
-<div class="outofdate">Cette traduction peut être périmée. Vérifiez la version
- anglaise pour les changements récents.</div>
<p>Afin d'assister les utilisateurs lors de leurs opérations de mise à
jour, nous maintenons un document
<li><code class="module"><a href="./mod/mod_auto_index.html">mod_auto_index</a></code>: extrait maintenant les titres
et affiche la description pour les fichiers .xhtml qui étaient
jusqu'alors ignorés.</li>
+
+ <li><code class="module"><a href="./mod/mod_ssl.html">mod_ssl</a></code> : le format par défaut des variables
+ <code>*_DN</code> a changé. Il est cependant encore possible
+ d'utiliser l'ancien format via la nouvelle option
+ <code>LegacyDNStringFormat</code> de la directive <code class="directive"><a href="./mod/mod_ssl.html#ssloptions">SSLOptions</a></code>.</li>
+
<li><code class="program"><a href="./programs/htpasswd.html">htpasswd</a></code> utilise maintenant par défaut les
condensés MD5 sur toutes les plates-formes.</li>
</ul>
<variants>
<variant>en</variant>
- <variant outdated="yes">fr</variant>
+ <variant>fr</variant>
</variants>
</metafile>
<a href="../ko/vhosts/ip-based.html" hreflang="ko" rel="alternate" title="Korean"> ko </a> |
<a href="../tr/vhosts/ip-based.html" hreflang="tr" rel="alternate" title="Türkçe"> tr </a></p>
</div>
-<div class="outofdate">Cette traduction peut être périmée. Vérifiez la version
- anglaise pour les changements récents.</div>
</div>
<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#requirements">Système requis</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#howto">Comment configurer Apache</a></li>
IP" et la commande "ifconfig" pour les activer), et/ou utiliser
plusieurs numéros de port.</p>
- <p>Dans la plupart des cas, les <a href="name-based.html">serveurs
- virtuels à base de nom</a> sont plus appropriés, car ils permettent
- de partager une seule paire adresse/port entre de nombreux serveurs
- virtuels. Voir le document <a href="name-based.html#namevip">Serveurs virtuels à base de noms ou
- serveurs virtuels à base d'adresse IP</a> pour vous aider à prendre
- une décision.
- </p>
-
+ <p>Selon la terminologie du serveur HTTP Apache, l'utilisation d'une
+ seule adresse IP avec plusieurs ports TCP s'apparente aussi à de
+ l'hébergement virtuel basé sur IP.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="howto" id="howto">Comment configurer Apache</a></h2>
que le processus résident doit gérer. Par exemple :</p>
<div class="example"><p><code>
- Listen www.example.com:80
+ Listen 192.0.2.100:80
</code></p></div>
<p>Il est recommandé d'utiliser une adresse IP plutôt qu'un nom
<variants>
<variant>en</variant>
- <variant outdated="yes">fr</variant>
+ <variant>fr</variant>
<variant outdated="yes">ja</variant>
<variant outdated="yes">ko</variant>
<variant outdated="yes">tr</variant>
IP address and then configure the Apache HTTP Server to recognize
the different hostnames. Name-based virtual hosting also eases
the demand for scarce IP addresses. Therefore you should use
- name-based virtual hosting unless there is a specific reason to
- choose IP-based virtual hosting. Some reasons why you might consider
- using IP-based virtual hosting:</p>
-
- <ul>
- <li>Name-based virtual hosting often <a href="../ssl/ssl_faq.html#vhosts">
- cannot be used with SSL secure servers</a>
- because of the nature of the SSL protocol.</li>
-
- <li>Some operating systems and network equipment implement bandwidth
- management techniques that cannot differentiate between hosts unless
- they are on separate IP addresses.</li>
- </ul>
+ name-based virtual hosting unless you are using equipment
+ that explicitly demands IP-based hosting. Historical reasons for
+ IP-based virtual hosting based on client support are no longer
+ applicable to a general-purpose web server.</p>
<p> Name-based virtual hosting builds off of the IP-based virtual host
selection algorithm, meaning that searches for the proper server name
occur only between virtual hosts that have the best IP-based address.</p>
-
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="alg" id="alg">How the server selects the proper name-based virtual host</a></h2>
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.de.xsl"?>
-<!-- English Revision: 420990:1053666 (outdated) -->
+<!-- English Revision: 420990:1066434 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?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: 1053231:1053666 (outdated) -->
+<!-- English Revision: 1053231:1066434 (outdated) -->
<!-- French translation by alain B, review by Vincent Deffontaines
updated by Lucien GENTIS -->
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 420990:1053666 (outdated) -->
+<!-- English Revision: 420990:1066434 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version='1.0' encoding='EUC-KR' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
-<!-- English Revision: 420990:1053666 (outdated) -->
+<!-- English Revision: 420990:1066434 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.tr.xsl"?>
-<!-- English Revision: 659902:1053666 (outdated) -->
+<!-- English Revision: 659902:1066434 (outdated) -->
<!-- =====================================================
Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>
Reviewed by: Orhan Berent <berent belgeler.org>
projects / apache / commitdiff