mirror of
https://github.com/apache/httpd.git
synced 2025-11-03 17:53:20 +03:00
ae6b0541d5
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1780462 13f79535-47bb-0310-9956-ffa450edef68
1200 lines
50 KiB
Plaintext
1200 lines
50 KiB
Plaintext
<?xml version="1.0" encoding="UTF-8" ?>
|
|
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
|
|
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
|
|
<!-- English Revision: 1741842 -->
|
|
<!-- 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_include.xml.meta">
|
|
|
|
<name>mod_include</name>
|
|
<description>Documents html interprétés par le serveur (Server Side
|
|
Includes ou SSI)</description>
|
|
<status>Base</status>
|
|
<sourcefile>mod_include.c</sourcefile>
|
|
<identifier>include_module</identifier>
|
|
|
|
<summary>
|
|
<p>Ce module fournit un filtre qui va traiter les fichiers avant
|
|
de les envoyer au client. Le traitement est contrôlé via des
|
|
commentaires SGML spécialement formatés, aussi nommés
|
|
<dfn>éléments</dfn>. Ces éléments permettent l'insertion
|
|
conditionnelle de texte, l'inclusion d'autres fichiers ou
|
|
programmes, ainsi que la définition et l'affichage de variables
|
|
d'environnement.</p>
|
|
</summary>
|
|
<seealso><directive module="core">Options</directive></seealso>
|
|
<seealso><directive module="core">AcceptPathInfo</directive></seealso>
|
|
<seealso><a href="../filter.html">Les filtres</a></seealso>
|
|
<seealso><a href="../howto/ssi.html">Tutoriel SSI</a></seealso>
|
|
|
|
<section id="enabling">
|
|
<title>Activation des SSI</title>
|
|
|
|
<p>Les SSI sont implémentés par le <a
|
|
href="../filter.html">filtre</a> <code>INCLUDES</code>. Si des
|
|
documents contenant des directives SSI possèdent une extension
|
|
.shtml, les directives suivantes indiqueront à Apache de les
|
|
interpréter et d'assigner le type MIME
|
|
<code>text/html</code> au document obtenu :</p>
|
|
|
|
<highlight language="config">
|
|
AddType text/html .shtml
|
|
AddOutputFilter INCLUDES .shtml
|
|
</highlight>
|
|
|
|
<p>L'option suivante doit être définie pour les répertoires qui
|
|
contiennent les fichiers shtml (en général dans une section
|
|
<directive module="core" type="section">Directory</directive>, mais
|
|
cette option peut également être définie dans un fichier
|
|
<code>.htaccess</code> si <code><directive
|
|
module="core">AllowOverride</directive> Options</code> a été défini pour le
|
|
répertoire considéré) :</p>
|
|
|
|
<highlight language="config">
|
|
Options +Includes
|
|
</highlight>
|
|
|
|
<p>Pour des raisons de compatibilité ascendante, le <a
|
|
href="../handler.html">gestionnaire</a> <code>server-parsed</code>
|
|
peut aussi activer le filtre INCLUDES. Ainsi, Apache va activer le
|
|
filtre INCLUDES pour tout document de type MIME
|
|
<code>text/x-server-parsed-html</code> ou
|
|
<code>text/x-server-parsed-html3</code> (et le document obtenu aura
|
|
pour type MIME <code>text/html</code>).</p>
|
|
|
|
<p>Pour plus d'informations, voyez notre <a
|
|
href="../howto/ssi.html">Tutoriel SSI</a>.</p>
|
|
</section> <!-- /enabling -->
|
|
|
|
<section id="pathinfo">
|
|
<title>PATH_INFO et SSI</title>
|
|
|
|
<p>Les fichiers traités dans le cadre des SSI n'acceptent plus par
|
|
défaut les requêtes avec <code>PATH_INFO</code> (les informations
|
|
relatives au chemin en fin de requête). La directive <directive
|
|
module="core">AcceptPathInfo</directive> permet de configurer le
|
|
serveur de façon à ce qu'il accepte ce genre de requête.</p>
|
|
</section> <!-- /pathinfo -->
|
|
|
|
<section id="elements"><title>Eléments disponibles</title>
|
|
<p>Le document est interprété comme un document HTML, avec des
|
|
commandes spéciales incluses sous forme de commentaires SGML. La
|
|
syntaxe d'une commande est la suivante : </p>
|
|
|
|
<example>
|
|
<!--#<var>élément</var> <var>attribut</var>=<var>valeur</var>
|
|
<var>attribut</var>=<var>valeur</var> ... -->
|
|
</example>
|
|
|
|
<p>Les valeurs sont souvent entourées de guillemets, mais on peut
|
|
aussi utiliser des apostrophes (<code>'</code>) ou des apostrophes
|
|
inverses (<code>`</code>). De nombreuses commandes n'acceptent
|
|
qu'une seule paire attribut-valeur. Notez que le terminateur de
|
|
commentaire (<code>--></code>) doit être précédé d'un espace afin
|
|
d'être sûr qu'il ne soit pas considéré comme un élément de commande
|
|
SSI. Notez aussi que le délimiteur de début <code><!--#</code>
|
|
est <em>un</em> élément de commande et ne doit donc pas contenir
|
|
d'espace.</p>
|
|
|
|
<p>La table suivante contient la liste des éléments autorisés :</p>
|
|
|
|
<table border="1">
|
|
<tr><th>Elément</th><th>Description</th></tr>
|
|
<tr><td><code><a href="#element.comment">comment</a></code></td>
|
|
<td>commentaire SSI</td></tr>
|
|
<tr><td><code><a href="#element.config">config</a></code></td>
|
|
<td>configure les formats de sortie</td></tr>
|
|
<tr><td><code><a href="#element.echo">echo</a></code></td>
|
|
<td>affiche le contenu de variables</td></tr>
|
|
<tr><td><code><a href="#element.exec">exec</a></code></td>
|
|
<td>exécute des programmes externes</td></tr>
|
|
<tr><td><code><a href="#element.fsize">fsize</a></code></td>
|
|
<td>affiche la taille d'un fichier</td></tr>
|
|
<tr><td><code><a href="#element.flastmod">flastmod</a></code></td>
|
|
<td>affiche la date de dernière modification d'un fichier</td></tr>
|
|
<tr><td><code><a href="#element.include">include</a></code></td>
|
|
<td>inclut un fichier</td></tr>
|
|
<tr><td><code><a href="#element.printenv">printenv</a></code></td>
|
|
<td>affiche toutes les variables disponibles</td></tr>
|
|
<tr><td><code><a href="#element.set">set</a></code></td>
|
|
<td>définit la valeur d'une variable</td></tr>
|
|
</table>
|
|
|
|
<p>Les éléments SSI peuvent être définis par d'autres modules que
|
|
<module>mod_include</module>. À ce titre, l'élément <code><a
|
|
href="#element.exec">exec</a></code> est fourni par
|
|
<module>mod_cgi</module>, et ne sera disponible que si ce module est
|
|
chargé.</p>
|
|
|
|
<section id="element.comment"><title>L'élément comment</title>
|
|
<p>Cette commande n'affiche aucune information. Elle n'a pour but que
|
|
l'ajout de commentaires dans un fichier et ces commentaires ne sont pas
|
|
affichés.</p>
|
|
|
|
<p>Cette syntaxe est disponible à partir de la version 2.5 du serveur
|
|
HTTP Apache.</p>
|
|
|
|
<example>
|
|
<!--#comment Blah Blah Blah -->
|
|
</example>
|
|
</section> <!-- /comment -->
|
|
|
|
<section id="element.config"><title>L'élément config</title>
|
|
<p>Cette commande contrôle divers aspects de l'interprétation. Les
|
|
attributs valides sont :</p>
|
|
|
|
<dl>
|
|
<dt><code>echomsg</code> (<em>Versions 2.1 et supérieures
|
|
d'Apache</em>)</dt>
|
|
<dd><p>La valeur est un message qui sera envoyé au client si
|
|
l'élément <code><a href="#element.echo">echo</a></code> tente
|
|
d'afficher le contenu d'une variable non définie. Cet attribut
|
|
l'emporte sur toute directive <directive
|
|
module="mod_include">SSIUndefinedEcho</directive>.</p>
|
|
|
|
<example>
|
|
<!--#config echomsg="[Valeur non définie]" -->
|
|
</example>
|
|
|
|
</dd>
|
|
|
|
<dt><code>errmsg</code></dt>
|
|
<dd><p>La valeur est un message qui sera envoyé au client si une
|
|
erreur survient lors de l'interprétation du document. Cet attribut
|
|
l'emporte sur toute directive <directive
|
|
module="mod_include">SSIErrorMsg</directive>.</p>
|
|
|
|
<example>
|
|
<!--#config errmsg="[Zut, quelque chose s'est mal passé.]" -->
|
|
</example>
|
|
|
|
</dd>
|
|
|
|
<dt><code>sizefmt</code></dt>
|
|
<dd><p>La valeur définit l'unité employée lors de l'affichage de la
|
|
taille d'un fichier. Les valeurs possibles sont <code>bytes</code>
|
|
pour une taille en octets, ou <code>abbrev</code> pour une taille
|
|
en Ko ou Mo selon son importance ; par exemple, une taille de 1024
|
|
octets sera affichée sous la forme "1K".</p>
|
|
|
|
<example>
|
|
<!--#config sizefmt="abbrev" -->
|
|
</example>
|
|
|
|
</dd>
|
|
|
|
<dt><code>timefmt</code></dt>
|
|
<dd><p>La valeur est une chaîne que pourra utiliser la fonction de la
|
|
bibliothèque standard <code>strftime(3)</code> lors de l'affichage
|
|
des dates.</p>
|
|
|
|
<example>
|
|
<!--#config timefmt=""%R, %B %d, %Y"" -->
|
|
</example>
|
|
|
|
</dd>
|
|
|
|
</dl>
|
|
</section> <!-- /config -->
|
|
|
|
<section id="element.echo"><title>L'élément echo</title>
|
|
<p>Cette commande affiche le contenu d'une des <a
|
|
href="#includevars">variables include</a> définies ci-dessous. Si
|
|
la variable n'est pas définie, le résultat est déterminé par la
|
|
valeur de la directive <directive module="mod_include"
|
|
>SSIUndefinedEcho</directive>. Le format d'affichage des dates est
|
|
défini par l'attribut <code>timefmt</code> de la commande
|
|
config.</p>
|
|
|
|
<p>Attributs:</p>
|
|
|
|
<dl>
|
|
<dt><code>var</code></dt>
|
|
<dd>La valeur est le nom de la variable à afficher.</dd>
|
|
|
|
<dt><code>decoding</code></dt>
|
|
<dd><p>Spécifie si Apache doit effectuer un décodage dans la
|
|
variable avant son traitement ultérieur. La valeur par défaut est
|
|
<code>none</code>, et dans ce cas, aucun décodage n'est effectué.
|
|
Si la valeur est <code>url</code>, un décodage de type URL sera
|
|
effectué (il s'agit du codage de type %-encoding utilisé dans les
|
|
URLs des liens, etc...). Si la valeur est <code>urlencoded</code>,
|
|
c'est un décodage des éléments de type
|
|
application/x-www-form-urlencode (que l'on trouve dans les chaînes
|
|
de paramètres) qui sera effectué. Si la valeur est
|
|
<code>base64</code>, un
|
|
decodage de type base64 sera effectué, et si elle est
|
|
<code>entity</code>, c'est un décodage des entités HTML qui sera
|
|
effectué. Ce décodage est effectué avant tout codage ultérieur de
|
|
la variable. Il est possible d'effectuer plusieurs décodages en
|
|
spécifiant plusieurs valeurs séparées par des virgules. Les
|
|
spécifications de décodages restent valables jusqu'au prochain
|
|
attribut de décodage, ou la fin de l'élément.</p>
|
|
|
|
<p>Pour être pris en compte, l'attribut de <code>décodage</code>
|
|
doit <em>précéder</em> l'attribut <code>var</code> correspondant.</p>
|
|
</dd>
|
|
|
|
<dt><code>encoding</code></dt>
|
|
<dd><p>Spécifie la manière dont Apache va coder les caractères
|
|
spéciaux que la variable contient avant leur affichage. S'il est
|
|
défini à <code>none</code>, aucun codage ne sera effectué. S'il
|
|
est défini à <code>url</code>, un codage de type URL sera effectué
|
|
(aussi connu sous le nom de codage avec caractères % , il convient
|
|
pour les URLS des liens, etc...). S'il est défini à
|
|
<code>urlencoded</code>, c'est un codage compatible
|
|
application/x-www-form-urlencoded qui sera effectué (à utiliser
|
|
dans les chaînes de paramètres). S'il est défini à
|
|
<code>base64</code>, c'est un encodage de type base64 qui sera
|
|
effectué. Au début d'un élément
|
|
<code>echo</code>, la valeur par défaut est définie à
|
|
<code>entity</code>, ce qui correspond à un codage de type entité
|
|
(codage qui convient pour un élément HTML de type bloc, comme le
|
|
paragraphe d'un texte). Cette valeur par défaut peut être modifiée
|
|
en ajoutant un attribut <code>encoding</code>, qui fera effet
|
|
jusqu'à la définition d'un nouvel attribut <code>encoding</code>
|
|
ou la fin de l'élément echo.</p>
|
|
|
|
<p>Pour produire son effet, l'attribut <code>encoding</code> doit
|
|
précéder l'attribut <code>var</code> concerné.</p>
|
|
|
|
<note type="warning">
|
|
Afin de prévenir les attaques de type cross-site scripting, il
|
|
est recommandé de <em>toujours</em> encoder les données fournies
|
|
par les utilisateurs.
|
|
</note>
|
|
|
|
<example><title>Example</title>
|
|
<!--#echo encoding="entity" var="QUERY_STRING" -->
|
|
</example>
|
|
</dd>
|
|
</dl>
|
|
</section> <!-- /echo -->
|
|
|
|
<section id="element.exec"><title>L'élément exec</title>
|
|
<p>La commande <code>exec</code> exécute la commande shell ou le
|
|
script spécifié. Elle nécessite le chargement du module
|
|
<module>mod_cgi</module>. Si <directive
|
|
module="core">Options</directive> <code>IncludesNOEXEC</code> est
|
|
définie, cette commande est désactivée. Les attributs disponibles
|
|
sont :</p>
|
|
|
|
<dl>
|
|
<dt><code>cgi</code></dt>
|
|
<dd><p>La valeur spécifie un chemin URL vers le script CGI (encodé
|
|
avec caractères %). Si le chemin ne commence pas par un slash (/),
|
|
il est considéré comme relatif au document courant. Le document
|
|
référencé par ce chemin est invoqué en tant que script CGI, même
|
|
s'il n'est pas censé être reconnu comme tel par le serveur. Les
|
|
scripts CGI doivent cependant être activés dans le répertoire qui
|
|
contient les scripts (via la directive <directive
|
|
module="mod_alias">ScriptAlias</directive> ou l'<directive
|
|
module="core">Options</directive> <code>ExecCGI</code>).</p>
|
|
|
|
<p>Le <code>PATH_INFO</code> et la chaîne d'arguments
|
|
(<code>QUERY_STRING</code>) de la requête originale du client sont
|
|
fournis au script CGI ; ils <em>ne peuvent pas</em> être spécifiés
|
|
dans le chemin de l'URL. Le script disposera des variables include
|
|
en plus de l'environnement standard <a
|
|
href="mod_cgi.html">CGI</a>.</p>
|
|
|
|
<example><title>Exemple</title>
|
|
<!--#exec cgi="/cgi-bin/exemple.cgi" -->
|
|
</example>
|
|
|
|
<p>Si, à la place d'un flux de sortie, le script renvoie un
|
|
en-tête <code>Location:</code>, ce dernier sera traduit en ancrage
|
|
HTML.</p>
|
|
|
|
<p>L'élément <code><a href="#includevirtual">include
|
|
virtual</a></code> doit être préféré à <code>exec cgi</code>. En
|
|
particulier, si vous devez transmettre des arguments
|
|
supplémentaires à un programme CGI en utilisant la chaîne
|
|
d'arguments de la requête, c'est impossible avec <code>exec
|
|
cgi</code>, mais vous pouvez y parvenir avec <code>include
|
|
virtual</code> comme suit :</p>
|
|
|
|
<example>
|
|
<!--#include virtual="/cgi-bin/exemple.cgi?argument=valeur" -->
|
|
</example>
|
|
</dd>
|
|
|
|
<dt><code>cmd</code></dt>
|
|
<dd><p>Le serveur va exécuter la commande fournie en utilisant
|
|
<code>/bin/sh</code>. La commande dispose des <a
|
|
href="#includevars">variables include</a>, en plus du jeu habituel
|
|
de variables CGI.</p>
|
|
|
|
<p>Il est toujours préférable d'utiliser <code><a
|
|
href="#includevirtual">#include virtual</a></code> à la place de
|
|
<code>#exec cgi</code> ou <code>#exec cmd</code>. <code>#include
|
|
virtual</code> utilise le mécanisme standard des sous-requêtes
|
|
d'Apache pour inclure des fichiers ou des scripts. Il a fait
|
|
l'objet de tests plus approfondis et sa maintenance est mieux
|
|
suivie.</p>
|
|
|
|
<p>De plus, sur certaines plate-formes, comme Win32, et sous unix,
|
|
si l'on utilise <a href="../suexec.html">suexec</a>, il est
|
|
impossible de transmettre des arguments à une commande dans une
|
|
directive <code>exec</code>, à moins d'insérer des espaces dans la
|
|
commande. Ainsi, alors que ce qui suit fonctionnera sous unix avec
|
|
une configuration sans suexec, l'effet produit ne sera pas celui
|
|
désiré sous Win32, ou dans le cas de l'utilisation de suexec
|
|
:</p>
|
|
|
|
<example>
|
|
<!--#exec cmd="perl /chemin/vers/script_perl arg1 arg2" -->
|
|
</example>
|
|
</dd>
|
|
</dl>
|
|
</section> <!-- /exec -->
|
|
|
|
<section id="element.fsize"><title>L'élément fsize</title>
|
|
<p>Cette commande permet d'afficher la taille du fichier spécifié
|
|
en fonction des spécifications de format de <code>sizefmt</code>.
|
|
Attributs :</p>
|
|
|
|
<dl>
|
|
<dt><code>file</code></dt>
|
|
<dd>La valeur est le chemin du fichier, relatif au répertoire
|
|
contenant le document en cours d'interprétation.
|
|
|
|
<example>
|
|
Ce fichier a une taille de <!--#fsize file="mod_include.html"
|
|
--> octets.
|
|
</example>
|
|
|
|
La valeur de <code>file</code> ne peut pas faire référence à un
|
|
fichier situé à un niveau supérieur de l'arborescence du répertoire
|
|
courant ou en dehors de la racine des documents ; il ne peut donc
|
|
ni commencer par un slash, ni contenir la séquence de caractères
|
|
<code>../</code>. Si c'est le cas, le message d'erreur <code>The
|
|
given path was above the root path</code> sera renvoyé.
|
|
</dd>
|
|
|
|
<dt><code>virtual</code></dt>
|
|
<dd>La valeur est un chemin URL (codé avec caractères %). S'il ne
|
|
commence pas par un slash (/), il est considéré comme relatif au
|
|
document courant. Notez que cette commande n'affiche <em>pas</em>
|
|
la taille de la sortie d'un programme CGI, mais la taille du
|
|
programme CGI lui-même.</dd>
|
|
</dl>
|
|
|
|
<example>
|
|
Ce fichier a une taille de <!--#fsize
|
|
virtual="/docs/mod/mod_include.html" --> octets.
|
|
</example>
|
|
|
|
<p>Notez que dans la plupart des cas, ces deux attributs sont
|
|
identiques. Cependant, l'attribut <code>file</code> ne respecte
|
|
pas les aliases URL-space.</p>
|
|
</section> <!-- /fsize -->
|
|
|
|
<section id="element.flastmod"><title>L'élément flastmod</title>
|
|
<p>Cette commande permet d'afficher la date de dernière
|
|
modification du fichier spécifié, en fonction des spécifications
|
|
de format de <code>timefmt</code>. Les attributs sont les mêmes
|
|
que ceux de la commande <code><a
|
|
href="#element.fsize">fsize</a></code>.</p>
|
|
</section> <!-- /flastmod -->
|
|
|
|
<section id="element.include"><title>L'élément include</title>
|
|
<p>Cette commande permet d'insérer le texte d'un autre document ou
|
|
fichier dans le fichier en cours d'interprétation. Tout fichier
|
|
inclus est soumis au contrôle d'accès habituel. Si <a
|
|
href="core.html#options">Options</a> <code>IncludesNOEXEC</code>
|
|
est défini pour le répertoire contenant le fichier
|
|
interprété, seuls les documents possèdant un
|
|
<glossary>type MIME</glossary> de type texte
|
|
(<code>text/plain</code>, <code>text/html</code>, etc...) seront
|
|
inclus. Les scripts CGI, quant à eux, sont invoqués de manière
|
|
habituelle en utilisant l'URL complète fournie avec la commande, y
|
|
compris toute chaîne d'arguments éventuelle.</p>
|
|
|
|
<p>Un attribut définit le chemin du document à inclure, et peut
|
|
apparaître plusieurs fois dans l'élément à inclure ; en retour, pour
|
|
chaque attribut fourni à la commande include, une inclusion est
|
|
effectuée. Les attributs disponibles sont :</p>
|
|
|
|
<dl>
|
|
<dt><code>file</code></dt>
|
|
<dd>La valeur est un chemin relatif au répertoire contenant le
|
|
fichier en cours d'interprétation. Elle ne peut ni contenir
|
|
<code>../</code>, ni être un chemin absolu. Ainsi, vous ne pouvez
|
|
pas inclure de fichiers situés en dehors de l'arborescence du
|
|
site web ou dans un niveau supérieur à celui du fichier courant
|
|
dans cette arborescence. Il est toujours préférable d'utiliser
|
|
l'attribut <code>virtual</code>.</dd>
|
|
|
|
<dt><code><a id="includevirtual" name="includevirtual"
|
|
>virtual</a></code></dt>
|
|
<dd><p>La valeur est un chemin URL (codé avec caractères %). L'URL
|
|
ne peut contenir qu'un chemin et une chaîne d'arguments
|
|
éventuelle, à l'exclusion de tout protocole ou nom d'hôte. S'il ne
|
|
commence pas par un slash (/), il est considéré comme relatif au
|
|
document courant.</p>
|
|
|
|
<p>Une URL est construite à partir de l'attribut, et la sortie que
|
|
renverrait le serveur si l'URL était accédée par le client est
|
|
incluse dans la sortie interprétée. Les inclusions de fichiers
|
|
peuvent ainsi être imbriquées.</p>
|
|
|
|
<p>Si l'URL spécifiée correspond à un programme CGI, le programme
|
|
sera exécuté, et son flux de sortie inséré à la place de la
|
|
directive dans le fichier interprété. Vous pouvez insérer une
|
|
chaîne d'arguments dans une URL correspond à un programme CGI
|
|
:</p>
|
|
|
|
<example>
|
|
<!--#include virtual="/cgi-bin/exemple.cgi?argument=valeur" -->
|
|
</example>
|
|
|
|
<p><code>include virtual</code> doit être préféré à <code>exec
|
|
cgi</code> pour inclure le flux de sortie d'un programme CGI dans
|
|
un document HTML.</p>
|
|
|
|
<p>Si la directive <directive
|
|
module="mod_request">KeptBodySize</directive> est correctement
|
|
définie et valide pour le fichier inclus, les tentatives de
|
|
requêtes POST vers le document HTML qui inclut des fichiers seront
|
|
transmises aux sous-requêtes en tant que requêtes POST
|
|
elles-mêmes. Sans cette directive, toutes les sous-requêtes sont
|
|
traitées en tant que requêtes GET.</p>
|
|
|
|
</dd>
|
|
|
|
<dt><code>onerror</code></dt>
|
|
<dd><p>La valeur est un chemin-URL (codé-%) qui est affiché si une
|
|
tentative précédente d'inclure un fichier ou un attribut virtuel a
|
|
échoué. Pour produire son effet, cet attribut doit être spécifié
|
|
après le fichier ou les attributs virtuels concernés. Si la
|
|
tentative d'inclure le chemin onerror échoue, ou si onerror n'est
|
|
pas spécifié, c'est le message d'erreur par défaut qui sera
|
|
inclus.</p>
|
|
|
|
<example>
|
|
# Exemple simple<br />
|
|
<!--#include virtual="/not-exist.html" onerror="/error.html" -->
|
|
</example>
|
|
|
|
<example>
|
|
# Chemins onerror dédiés<br />
|
|
<!--#include virtual="/path-a.html" onerror="/error-a.html" virtual="/path-b.html" onerror="/error-b.html" -->
|
|
</example>
|
|
|
|
</dd>
|
|
</dl>
|
|
</section> <!-- /include -->
|
|
|
|
<section id="element.printenv"><title>L'élément printenv</title>
|
|
<p>Cette commande affiche la liste en mode texte de toutes les variables et de
|
|
leurs valeurs. Les caractères spéciaux sont encodés <code>entity</code> avant
|
|
d'être affichés (se reporter à l'élément <code><a
|
|
href="#element.echo">echo</a></code> pour plus de détails). Cette
|
|
commande ne comporte pas d'attributs.</p>
|
|
|
|
<example><title>Exemple</title>
|
|
<pre>
|
|
<!--#printenv -->
|
|
</pre>
|
|
</example>
|
|
</section> <!-- /printenv -->
|
|
|
|
<section id="element.set"><title>L'élément set</title>
|
|
<p>Cette commande permet de définir la valeur d'une variable. Les
|
|
attributs sont :</p>
|
|
|
|
<dl>
|
|
<dt><code>var</code></dt>
|
|
<dd>Le nom de la variable à définir.</dd>
|
|
|
|
<dt><code>value</code></dt>
|
|
<dd>La valeur à affecter à la variable.</dd>
|
|
<dt><code>decoding</code></dt>
|
|
<dd><p>Spécifie si Apache doit effectuer un décodage dans la
|
|
variable avant son traitement ultérieur. La valeur par défaut est
|
|
<code>none</code>, et dans ce cas, aucun décodage n'est effectué.
|
|
Si la valeur est <code>url</code>, <code>urlencoded</code>,
|
|
<code>base64</code> ou
|
|
<code>entity</code>, c'est un décodage de type URL,
|
|
application/x-www-form-urlencoded, base64 ou
|
|
entité HTML qui sera respectivement effectué. Il est possible
|
|
d'effectuer plusieurs décodages en
|
|
spécifiant plusieurs valeurs séparées par des virgules. Les
|
|
spécifications de décodages restent valables jusqu'au prochain
|
|
attribut de décodage, ou la fin de l'élément. Pour être pris en
|
|
compte, l'attribut de <code>décodage</code>
|
|
doit <em>précéder</em> l'attribut <code>var</code> correspondant.</p>
|
|
</dd>
|
|
|
|
<dt><code>encoding</code></dt>
|
|
<dd><p>Spécifie la manière dont Apache va encoder les caractères
|
|
spéciaux que la variable contient avant leur affichage. S'il est
|
|
défini à <code>none</code>, aucun encodage ne sera effectué. Si la
|
|
valeur est <code>url</code>, <code>urlencoding</code>,
|
|
<code>base64</code> ou
|
|
<code>entity</code>, c'est un encodage de type URL,
|
|
application/x-www-form-urlencoded, base64 ou
|
|
entité HTML qui sera respectivement effectué. Il est possible de
|
|
spécifier plusieurs types d'encodage en les séparant par des
|
|
virgules. La spécification du type d'encodage fera effet
|
|
jusqu'à la définition d'un nouvel attribut encoding
|
|
ou la fin de l'élément. Pour produire son effet, l'attribut <code>encoding</code> doit
|
|
précéder l'attribut <code>var</code> concerné. Les encodages sont
|
|
effectués après les opérations de décodage.</p>
|
|
</dd>
|
|
|
|
</dl>
|
|
|
|
<example><title>Exemple</title>
|
|
<!--#set var="category" value="help" -->
|
|
</example>
|
|
</section> <!-- /set -->
|
|
</section> <!-- /basic elements -->
|
|
|
|
<section id="includevars">
|
|
<title>Variables include</title>
|
|
|
|
<p>À l'instar des variables de l'environnement CGI standard, ces
|
|
variables sont mises à la disposition de la commande
|
|
<code>echo</code>, des opérateurs conditionnels <code>if</code> et
|
|
<code>elif</code>, et de tout programme invoqué par le document.</p>
|
|
|
|
<dl>
|
|
<dt><code>DATE_GMT</code></dt>
|
|
<dd>La date GMT (Greenwich Mean Time) courante.</dd>
|
|
|
|
<dt><code>DATE_LOCAL</code></dt>
|
|
<dd>La date locale courante.</dd>
|
|
|
|
<dt><code>DOCUMENT_ARGS</code></dt>
|
|
<dd>Cette variable contient la chaîne de paramètres de la requête du
|
|
document SSI actif, ou la chaîne vide si aucune chaîne de paramètres de
|
|
requête n'est incluse. Pour les sous-requêtes invoquées par la directive
|
|
SSI <code>include</code>, <code>QUERY_STRING</code> contiendra la chaîne
|
|
de paramètres de la sous-requête et <code>DOCUMENT_ARGS</code> la chaîne
|
|
de paramètres du document SSI (disponible à partir de la version 2.4.19 du
|
|
serveur HTTP Apache).</dd>
|
|
|
|
<dt><code>DOCUMENT_NAME</code></dt>
|
|
<dd>Le nom de base du fichier demandé par l'utilisateur (sans son
|
|
chemin).</dd>
|
|
|
|
<dt><code>DOCUMENT_URI</code></dt>
|
|
<dd>Le chemin URL (caractères % décodés) du document demandé par
|
|
l'utilisateur. Notez que dans le cas d'inclusions de fichiers
|
|
imbriquées, il ne s'agit <em>pas</em> de l'URL du document
|
|
courant. Notez également que si l'URL est modifiée en interne (par
|
|
exemple via une directive <directive
|
|
module="mod_alias">alias</directive> ou <directive
|
|
module="mod_dir">directoryindex</directive>), c'est l'URL modifiée
|
|
que contiendra la variable.</dd>
|
|
|
|
<dt><code>LAST_MODIFIED</code></dt>
|
|
<dd>La date de dernière modification du document demandé par
|
|
l'utilisateur.</dd>
|
|
|
|
<dt><code>QUERY_STRING_UNESCAPED</code></dt>
|
|
<dd>Si une chaîne d'arguments est présente dans la requête pour le
|
|
document SSI actif, elle sera affectée à
|
|
cette variable, les caractères %-décodés, et éventuellement
|
|
<em>échappés</em> pour qu'ils ne soient pas interprétés par le
|
|
shell (les caractères spéciaux comme <code>&</code>,etc...
|
|
sont précédés d'anti-slashes). Cette variable n'est pas définie si aucune
|
|
chaîne d'arguments n'est présente. Utilisez <code>DOCUMENT_ARGS</code> si
|
|
l'échappement des caractères du shell n'est pas souhaité.</dd>
|
|
</dl>
|
|
</section>
|
|
|
|
<section id="substitution"><title>Substitution de variable</title>
|
|
|
|
<p>Une substitution de variable à l'intérieur d'une chaîne entre
|
|
guillemets s'effectue dans la plupart des situations où cette
|
|
dernière peut raisonablement constituer un argument d'une directive
|
|
SSI. Sont concernées les directives <code>config</code>,
|
|
<code>exec</code>, <code>flastmod</code>, <code>fsize</code>,
|
|
<code>include</code>, <code>echo</code>, et <code>set</code>. Si la
|
|
directive <directive
|
|
module="mod_include">SSILegacyExprParser</directive> est définie à
|
|
<code>on</code>, la substitution s'effectue aussi dans les arguments
|
|
des opérateurs conditionnels. Vous pouvez insérer
|
|
un signe dollar en tant que caractère littéral dans une chaîne en
|
|
utilisant un anti-slash :</p>
|
|
|
|
<example>
|
|
<!--#set var="cur" value="\$test" -->
|
|
</example>
|
|
|
|
<p>Si une référence de variable doit être substituée au beau milieu
|
|
d'une séquence de caractères qui pourrait être elle-même considérée
|
|
comme un identifiant valide, l'ambiguïté peut être levée en
|
|
entourant la référence d'accolades, à la manière du shell :</p>
|
|
|
|
<example>
|
|
<!--#set var="Zed" value="${REMOTE_HOST}_${REQUEST_METHOD}" -->
|
|
</example>
|
|
|
|
<p>Dans cet exemple, la variable <code>Zed</code> se verra affecter
|
|
la valeur "<code>X_Y</code>" si <code>REMOTE_HOST</code> et
|
|
<code>REQUEST_METHOD</code> contiennent respectivement
|
|
"<code>X</code>" et "<code>Y</code>".</p>
|
|
|
|
</section>
|
|
|
|
<section id="flowctrl">
|
|
<title>Eléments de contrôle d'inclusion conditionnelle</title>
|
|
|
|
<p>Les éléments de base du contrôle d'inclusion conditionnelle sont
|
|
:</p>
|
|
|
|
<example>
|
|
<!--#if expr="<var>test_condition</var>" --><br />
|
|
<!--#elif expr="<var>test_condition</var>" --><br />
|
|
<!--#else --><br />
|
|
<!--#endif -->
|
|
</example>
|
|
|
|
<p>L'élément <code>if</code> fonctionne de la même manière que
|
|
la directive if d'un langage de programmation. La condition est
|
|
évaluée et si le résultat est vrai, le texte qui suit jusqu'au
|
|
prochain élément <code>elif</code>, <code>else</code> ou
|
|
<code>endif</code> sera inclus dans le flux de sortie.</p>
|
|
|
|
<p>Les éléments <code>elif</code> ou <code>else</code> permettent
|
|
d'insérer du texte dans le flux de sortie si
|
|
<var>test_condition</var> s'est révélé faux. Ces éléments sont
|
|
optionnels.</p>
|
|
|
|
<p>L'élément <code>endif</code> termine le bloc de traitement
|
|
conditionnel <code>if</code> et est obligatoire.</p>
|
|
|
|
<p><var>test_condition</var> est une expression booléenne qui
|
|
emprunte la syntaxe <a href="../expr.html">ap_expr</a>. La directive
|
|
<directive module="mod_include">SSILegacyExprParser</directive>
|
|
permet de modifier cette syntaxe pour la rendre compatible avec
|
|
Apache HTTPD 2.2.x.</p>
|
|
|
|
<p>Le jeu de variables SSI avec l'élément <code>var</code> sont
|
|
exportées vers l'environnement de la requête et sont accessibles via
|
|
la fonction <code>reqenv</code>. Pour faire simple, le nom de
|
|
fonction <code>v</code> est aussi disponible dans le module
|
|
<module>mod_include</module>.</p>
|
|
|
|
<p>Dans l'exemple suivant, "depuis le réseau local" sera affiché si
|
|
l'adresse IP du client appartient au sous-réseau 10.0.0.0/8.</p>
|
|
|
|
<example>
|
|
<!--#if expr='-R "10.0.0.0/8"' --><br />
|
|
<indent>
|
|
depuis le réseau local<br />
|
|
</indent>
|
|
<!--#else --><br />
|
|
<indent>
|
|
depuis ailleurs<br />
|
|
</indent>
|
|
<!--#endif -->
|
|
</example>
|
|
|
|
<p>Dans l'exemple suivant, "foo vaut bar" sera affiché si la variable
|
|
<code>foo</code> contient la valeur "bar".</p>
|
|
|
|
<example>
|
|
<!--#if expr='v("foo") = "bar"' --><br />
|
|
<indent>
|
|
foo vaut bar<br />
|
|
</indent>
|
|
<!--#endif -->
|
|
</example>
|
|
|
|
<note><title>Documentation de référence</title>
|
|
<p>Voir aussi <a href="../expr.html">Les expressions dans le serveur
|
|
HTTP Apache</a> pour une référence complète et des exemples. Les
|
|
fonctions <em>restricted</em> ne sont pas disponibles dans
|
|
<module>mod_include</module>.</p>
|
|
</note>
|
|
</section>
|
|
|
|
<section id="legacyexpr">
|
|
<title>Syntaxe des expressions héritée</title>
|
|
|
|
<p>Cette section décrit la syntaxe de l'élément <code>#if
|
|
expr</code> dans le cas où la directive <directive
|
|
module="mod_include">SSILegacyExprParser</directive> est définie à
|
|
<code>on</code>.</p>
|
|
|
|
<dl>
|
|
<dt><code><var>chaîne</var></code></dt>
|
|
<dd>vrai si <var>chaîne</var> n'est pas vide</dd>
|
|
|
|
<dt><code><var>-A string</var></code></dt>
|
|
<dd><p>vrai si l'URL que contient la chaîne est accessible du
|
|
point de vue de la configuration, faux sinon. Il
|
|
s'avère utile lorsqu'un lien vers une URL doit être caché aux
|
|
utilisateurs qui ne sont pas autorisés à voir cette URL. Notez que
|
|
le test porte sur l'autorisation d'accès à l'URL, et non sur son
|
|
existence.</p>
|
|
|
|
<example><title>Exemple</title>
|
|
<!--#if expr="-A /prive" --><br />
|
|
<indent>
|
|
Cliquez <a href="/prive">ici</a> pour accéder aux
|
|
informations privées.<br />
|
|
</indent>
|
|
<!--#endif -->
|
|
</example>
|
|
</dd>
|
|
|
|
<dt><code><var>chaîne1</var> = <var>chaîne2</var><br />
|
|
<var>chaîne1</var> == <var>chaîne2</var><br />
|
|
<var>chaîne1</var> != <var>chaîne2</var></code></dt>
|
|
|
|
<dd><p>Compare <var>chaîne1</var> à <var>chaîne2</var>. Si
|
|
<var>chaîne2</var> est de la forme
|
|
<code>/<var>chaîne2</var>/</code>, elle est traitée comme une
|
|
expression rationnelle. Les expressions rationnelles sont
|
|
implémentées par le moteur <a href="http://www.pcre.org">PCRE</a>
|
|
et possèdent la même syntaxe que celles de <a
|
|
href="http://www.perl.com">perl 5</a>. Notez que <code>==</code>
|
|
n'est qu'un alias pour <code>=</code> et se comporte exactement de
|
|
la même manière que ce dernier.</p>
|
|
|
|
<p>Si vous faites une comparaison directe (<code>=</code> ou
|
|
<code>==</code>), vous pouvez extraire des parties de l'expression
|
|
rationnelle. Les parties extraites sont stockées dans les
|
|
variables spéciales <code>$1</code> .. <code>$9</code>. L'ensemble
|
|
de la chaîne correspondant à l'expression rationnelle est stocké
|
|
dans la variable spéciale <code>$0</code>.</p>
|
|
|
|
<example><title>Exemple</title>
|
|
<!--#if expr="$QUERY_STRING = /^sid=([a-zA-Z0-9]+)/" --><br />
|
|
<indent>
|
|
<!--#set var="session" value="$1" --><br />
|
|
</indent>
|
|
<!--#endif -->
|
|
</example>
|
|
</dd>
|
|
|
|
<dt><code><var>chaîne1</var> < <var>chaîne2</var><br />
|
|
<var>chaîne1</var> <= <var>chaîne2</var><br />
|
|
<var>chaîne1</var> > <var>chaîne2</var><br />
|
|
<var>chaîne1</var> >= <var>chaîne2</var></code></dt>
|
|
|
|
<dd>Compare <var>chaîne1</var> à <var>chaîne2</var>. Notez que les
|
|
chaînes sont comparées de manière <em>littérale</em> (en utilisant
|
|
<code>strcmp(3)</code>). Ainsi, la chaîne "100" est inférieure à
|
|
"20".</dd>
|
|
|
|
<dt><code>( <var>test_condition</var> )</code></dt>
|
|
<dd>vrai si <var>test_condition</var> est vrai</dd>
|
|
|
|
<dt><code>! <var>test_condition</var></code></dt>
|
|
<dd>vrai si <var>test_condition</var> est faux</dd>
|
|
|
|
<dt><code><var>test_condition1</var> &&
|
|
<var>test_condition2</var></code></dt>
|
|
<dd>vrai si <var>test_condition1</var> et
|
|
<var>test_condition2</var> sont tous les deux vrais</dd>
|
|
|
|
<dt><code><var>test_condition1</var> ||
|
|
<var>test_condition2</var></code></dt>
|
|
<dd>vrai si au moins un des tests <var>test_condition1</var> ou
|
|
<var>test_condition2</var> est vrai</dd>
|
|
</dl>
|
|
|
|
<p>"<code>=</code>" et "<code>!=</code>" ont une priorité supérieure
|
|
à "<code>&&</code>" et "<code>||</code>". "<code>!</code>" a
|
|
la priorité la plus haute. Ainsi, les deux directives suivantes sont
|
|
équivalentes :</p>
|
|
|
|
<example>
|
|
<!--#if expr="$a = test1 && $b = test2" --><br />
|
|
<!--#if expr="($a = test1) && ($b = test2)" -->
|
|
</example>
|
|
|
|
<p>Les opérateurs booléens <code>&&</code> et
|
|
<code>||</code> ont la même priorité. Ainsi, si vous voulez
|
|
augmenter la priorité d'un de ces opérateurs, vous devez utiliser
|
|
des parenthèses.</p>
|
|
|
|
<p>Tout ce qui n'est pas reconnu comme variable ou opérateur est
|
|
traité comme une chaîne. Les chaînes peuvent aussi être entourées
|
|
d'apostrophes : <code>'chaîne'</code>. Les chaînes sans apostrophe
|
|
ne peuvent pas contenir d'espaces (espaces ou tabulations) car
|
|
ceux-ci servent à séparer certains éléments comme les variables. Si
|
|
plusieurs chaînes se trouvent dans une ligne, elles sont concaténées
|
|
en utilisant des espaces. Ainsi,</p>
|
|
|
|
<example>
|
|
<p><code><var>chaîne1</var> <var
|
|
>chaîne2</var></code> devient <code><var>chaîne1</var> <var
|
|
>chaîne2</var></code><br />
|
|
<br />
|
|
et<br />
|
|
<br />
|
|
<code>'<var>chaîne1</var> <var
|
|
>chaîne2</var>'</code> devient <code><var
|
|
>chaîne1</var> <var>chaîne2</var></code>.</p>
|
|
</example>
|
|
|
|
<note><title>Optimisation des expressions booléennes</title>
|
|
<p>Si les expressions atteignent une complexité suffisante pour
|
|
ralentir les traitements de manière significative, vous pouvez
|
|
essayer de les optimiser en fonction des règles d'évaluation :</p>
|
|
<ul>
|
|
<li>Les expressions sont évaluées de la gauche vers la droite</li>
|
|
<li>Les opérateurs booléens binaires (<code>&&</code> et
|
|
<code>||</code>) font l'objet d'une évaluation abrégée chaque fois
|
|
que cela est possible. En d'autres termes, et selon la règle
|
|
ci-dessus, <module>mod_include</module> évalue tout d'abord la
|
|
partie gauche de l'expression. Si le résultat de l'évaluation de
|
|
cette partie gauche suffit à déterminer le résultat final,
|
|
l'évaluation s'arrête ici. Dans le cas contraire, la partie droite
|
|
est évaluée, et le résultat final tient compte des résultats des
|
|
évaluations des parties gauche et droite.</li>
|
|
<li>L'évaluation abrégée est désactivée tant qu'il reste des
|
|
expressions régulières à traiter. Ces dernières doivent être
|
|
évaluées afin de définir les variables correspondant aux
|
|
références arrières (<code>$1</code> .. <code>$9</code>).</li>
|
|
</ul>
|
|
<p>Si vous voulez déterminer la manière dont une expression est
|
|
traitée, vous pouvez recompiler <module>mod_include</module> en
|
|
utilisant l'option de compilation <code>-DDEBUG_INCLUDE</code>.
|
|
Ceci a pour effet d'insérer, pour chaque expression interprétée,
|
|
des informations étiquetées, l'arbre d'interprétation et la
|
|
manière dont elle est évaluée au sein du flux de sortie envoyé au
|
|
client.</p>
|
|
</note>
|
|
|
|
<note><title>Slashes d'échappement dans les expressions
|
|
rationnelles</title>
|
|
<p>Tous les caractères slashes qui ne sont pas des séparateurs dans
|
|
votre expression rationnelle doivent être échappés, et ceci sans
|
|
tenir compte de leur signification du point de vue du moteur
|
|
d'expressions rationnelles.</p>
|
|
</note>
|
|
|
|
<note><title>Documentation de référence</title>
|
|
<p>Voir le document <a href="../expr.html">Les expressions dans le
|
|
serveur HTTP Apache</a>, pour une référence complète et des exemples.</p>
|
|
</note>
|
|
|
|
|
|
</section>
|
|
|
|
<directivesynopsis>
|
|
<name>SSIEndTag</name>
|
|
<description>Chaîne qui termine l'élément include</description>
|
|
<syntax>SSIEndTag <var>tag</var></syntax>
|
|
<default>SSIEndTag "-->"</default>
|
|
<contextlist><context>server config</context><context>virtual host</context>
|
|
</contextlist>
|
|
|
|
<usage>
|
|
<p>Cette directive permet de modifier la chaîne que
|
|
<module>mod_include</module> interprète comme la fin d'un élément
|
|
include.</p>
|
|
|
|
<highlight language="config">
|
|
SSIEndTag "%>"
|
|
</highlight>
|
|
|
|
</usage>
|
|
<seealso><directive module="mod_include">SSIStartTag</directive></seealso>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>SSIUndefinedEcho</name>
|
|
<description>Chaîne à afficher lorsqu'on tente d'extraire le contenu
|
|
d'une variable non définie</description>
|
|
<syntax>SSIUndefinedEcho <var>chaîne</var></syntax>
|
|
<default>SSIUndefinedEcho "(none)"</default>
|
|
<contextlist><context>server config</context><context>virtual host</context>
|
|
<context>directory</context><context>.htaccess</context></contextlist>
|
|
<override>All</override>
|
|
|
|
<usage>
|
|
<p>Cette directive permet de modifier la chaîne affichée par
|
|
<module>mod_include</module> lorsqu'on tente d'extraire le contenu
|
|
d'une variable non définie.</p>
|
|
|
|
<highlight language="config">
|
|
SSIUndefinedEcho "<!-- nondef -->"
|
|
</highlight>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>SSIErrorMsg</name>
|
|
<description>Message d'erreur affiché lorsqu'une erreur SSI
|
|
survient</description>
|
|
<syntax>SSIErrorMsg <var>message</var></syntax>
|
|
<default>SSIErrorMsg "[an error occurred while processing this
|
|
directive]"</default>
|
|
<contextlist><context>server config</context><context>virtual host</context>
|
|
<context>directory</context><context>.htaccess</context></contextlist>
|
|
<override>All</override>
|
|
|
|
<usage>
|
|
<p>La directive <directive>SSIErrorMsg</directive> permet de
|
|
modifier le message d'erreur affiché lorsqu'une erreur SSI survient.
|
|
Pour les serveurs en production, il est recommandé de modifier le
|
|
message d'erreur par défaut en <code>"<!-- Error
|
|
-->"</code>, de façon à ce que le message ne soit pas
|
|
présenté à l'utilisateur.</p>
|
|
|
|
<p>Cette directive a le même effet que l'élément
|
|
<code><!--#config errmsg=<var>message</var> --></code>.</p>
|
|
|
|
<highlight language="config">
|
|
SSIErrorMsg "<!-- Error -->"
|
|
</highlight>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>SSIStartTag</name>
|
|
<description>Chaîne qui marque le début d'un élément
|
|
include</description>
|
|
<syntax>SSIStartTag <var>tag</var></syntax>
|
|
<default>SSIStartTag "<!--#"</default>
|
|
<contextlist><context>server config</context><context>virtual host</context>
|
|
</contextlist>
|
|
|
|
<usage>
|
|
<p>Cette directive permet de modifier la chaîne que
|
|
<module>mod_include</module> interprète comme le début d'un élément
|
|
include.</p>
|
|
|
|
<p>Cette option peut vous être utile si vous avez deux serveurs qui
|
|
interprètent un fichier avec des commandes différentes (et
|
|
éventuellement à des moments différents).</p>
|
|
|
|
<highlight language="config">
|
|
SSIStartTag "<%"
|
|
SSIEndTag "%>"
|
|
</highlight>
|
|
|
|
<p>Avec l'exemple ci-dessus, qui définit aussi une directive
|
|
<directive module="mod_include">SSIEndTag</directive>, vous pourrez
|
|
inscrire des directives SSI comme dans l'exemple suivant :</p>
|
|
|
|
<example><title>Directives SSI avec marques de début et de fin
|
|
personnalisées</title>
|
|
<%printenv %>
|
|
</example>
|
|
</usage>
|
|
<seealso><directive module="mod_include">SSIEndTag</directive></seealso>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>SSITimeFormat</name>
|
|
<description>Configuration du format d'affichage des dates</description>
|
|
<syntax>SSITimeFormat <var>chaîne de formatage</var></syntax>
|
|
<default>SSITimeFormat "%A, %d-%b-%Y %H:%M:%S %Z"</default>
|
|
<contextlist>
|
|
<context>server config</context><context>virtual host</context>
|
|
<context>directory</context><context>.htaccess</context></contextlist>
|
|
<override>All</override>
|
|
|
|
<usage>
|
|
<p>Cette directive permet de modifier le format d'affichage des
|
|
variables d'environnement <code>DATE</code>. La <var>chaîne de
|
|
formatage</var> est identique à celle de la fonction
|
|
<code>strftime(3)</code> de la bibliothèque C standard.</p>
|
|
|
|
<p>Cette directive a le même effet que l'élément
|
|
<code><!--#config timefmt=<var>chaîne de formatage</var>
|
|
--></code>.</p>
|
|
|
|
<highlight language="config">
|
|
SSITimeFormat "%R, %B %d, %Y"
|
|
</highlight>
|
|
|
|
<p>Avec l'exemple ci-dessus, les dates seront affichées dans le
|
|
style "22:26, June 14, 2002".</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>SSIETag</name>
|
|
<description>Définit si des en-têtes ETags sont générés par le serveur.</description>
|
|
<syntax>SSIETag on|off</syntax>
|
|
<default>SSIETag off</default>
|
|
<contextlist><context>directory</context><context>.htaccess</context></contextlist>
|
|
|
|
<usage>
|
|
<p>Dans le cas général, un fichier filtré par
|
|
<module>mod_include</module> peut contenir des éléments soit
|
|
générés dynamiquement, soit éventuellement modifiés indépendemment
|
|
du fichier original. En conséquence, il est demandé par défaut au
|
|
serveur de ne pas générer d'en-tête <code>ETag</code> à la réponse
|
|
en ajoutant <code>no-etag</code> aux informations de requête.</p>
|
|
|
|
<p>Ce comportement peut être modifié via la directive
|
|
<directive>SSIETag</directive> qui permet au serveur de générer un
|
|
en-tête <code>ETag</code>. On peut aussi l'utiliser pour la mise
|
|
en cache de la sortie. Notez qu'un serveur d'arrière-plan ou un
|
|
générateur de contenu dynamique peut lui-même générer un en-tête
|
|
<code>ETag</code>, en ignorant l'information <code>no-etag</code>,
|
|
cet en-tête <code>ETag</code> étant transmis par
|
|
<module>mod_include</module> sans tenir compte de la définition de
|
|
la présente directive. La directive <directive>SSIETag</directive>
|
|
peut prendre une des valeurs suivantes :</p>
|
|
|
|
<dl>
|
|
|
|
<dt><code>off</code></dt>
|
|
<dd><code>no-etag</code> sera ajouté aux informations de
|
|
requête, et il sera demandé au serveur de ne pas générer
|
|
d'en-tête <code>ETag</code>. Lorsqu'un serveur ignore la valeur
|
|
de <code>no-etag</code> et génère tout de même un en-tête
|
|
<code>ETag</code>, ce dernier sera respecté.</dd>
|
|
|
|
<dt><code>on</code></dt>
|
|
<dd>Les en-têtes <code>ETag</code> existants seront respectés,
|
|
et ceux générés par le serveur seront ajoutés à la réponse.</dd>
|
|
|
|
</dl>
|
|
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>SSILastModified</name>
|
|
<description>Définit si des en-têtes <code>Last-Modified</code> sont
|
|
générés par le serveur.</description>
|
|
<syntax>SSILastModified on|off</syntax>
|
|
<default>SSILastModified off</default>
|
|
<contextlist><context>directory</context><context>.htaccess</context></contextlist>
|
|
|
|
<usage>
|
|
<p>Dans le cas général, un fichier filtré par
|
|
<module>mod_include</module> peut contenir des éléments soit
|
|
générés dynamiquement, soit éventuellement modifiés indépendemment
|
|
du fichier original. En conséquence, l'en-tête
|
|
<code>Last-Modified</code> est supprimé par défaut de la réponse.</p>
|
|
|
|
<p>La directive <directive>SSILastModified</directive> permet de
|
|
modifier ce comportement en faisant en sorte que l'en-tête
|
|
<code>Last-Modified</code> soit respecté s'il est déjà présent, ou
|
|
défini dans le cas contraire. On peut aussi l'utiliser pour la mise
|
|
en cache de la sortie. La directive
|
|
<directive>SSILastModified</directive> peut prendre une des
|
|
valeurs suivantes :</p>
|
|
|
|
<dl>
|
|
|
|
<dt><code>off</code></dt>
|
|
<dd>L'en-tête <code>Last-Modified</code> sera supprimé des
|
|
réponses, à moins que la directive <directive
|
|
module="mod_include">XBitHack</directive> ne soit définie à
|
|
<code>full</code> comme décrit plus loin.</dd>
|
|
|
|
<dt><code>on</code></dt>
|
|
<dd>L'en-tête <code>Last-Modified</code> sera respecté s'il est
|
|
déjà présent, et ajouté à la réponse si cette dernière est un
|
|
fichier et si l'en-tête est manquant. La directive <directive
|
|
module="mod_include">SSILastModified</directive> l'emporte sur
|
|
la directive <directive
|
|
module="mod_include">XBitHack</directive>.</dd>
|
|
|
|
</dl>
|
|
|
|
</usage>
|
|
</directivesynopsis>
|
|
<directivesynopsis>
|
|
<name>SSILegacyExprParser</name>
|
|
<description>Active le mode de compatibilité pour les expressions
|
|
conditionnelles.</description>
|
|
<syntax>SSILegacyExprParser on|off</syntax>
|
|
<default>SSILegacyExprParser off</default>
|
|
<contextlist><context>directory</context><context>.htaccess</context></contextlist>
|
|
<compatibility>Disponible à partir de la version 2.3.13.</compatibility>
|
|
|
|
<usage>
|
|
<p>Depuis la version 2.3.13, <module>mod_include</module> a adopté
|
|
la nouvelle syntaxe <a href="../expr.html">ap_expr</a> pour ses
|
|
expressions conditionnelles dans les éléments de contrôle de flux
|
|
<code>#if</code>. Cette directive permet de réactiver l'<a
|
|
href="#legacyexpr">ancienne syntaxe</a> qui est compatible avec les
|
|
versions 2.2.x et antérieures d'Apache HTTPD.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>XBitHack</name>
|
|
<description>Interprète les directives SSI dans les fichiers dont le bit
|
|
d'exécution est positionné</description>
|
|
<syntax>XBitHack on|off|full</syntax>
|
|
<default>XBitHack off</default>
|
|
<contextlist><context>server config</context><context>virtual host</context>
|
|
<context>directory</context><context>.htaccess</context></contextlist>
|
|
<override>Options</override>
|
|
|
|
<usage>
|
|
<p>La directive <directive>XBitHack</directive> permet de contrôler
|
|
l'interprétation des documents html standards. Elle n'affecte que
|
|
les fichiers dont le <glossary>type MIME</glossary> est
|
|
<code>text/html</code>. <directive>XBitHack</directive> peut prendre
|
|
les valeurs suivantes :</p>
|
|
|
|
<dl>
|
|
<dt><code>off</code></dt>
|
|
<dd>Aucun traitement particulier pour les fichiers
|
|
exécutables.</dd>
|
|
|
|
<dt><code>on</code></dt>
|
|
<dd>Tout fichier <code>text/html</code> dont le bit d'exécution
|
|
est positionné pour le propriétaire sera traité en tant que
|
|
document html interprété par le serveur.</dd>
|
|
|
|
<dt><code>full</code></dt>
|
|
<dd>Identique à <code>on</code>, avec test du bit d'exécution pour
|
|
le groupe. Si ce dernier est positionné, la date de <code>dernière
|
|
modification</code> du fichier renvoyé est définie à la date de
|
|
dernière modification du fichier. Dans le cas contraire, aucune
|
|
date de dernière modification n'est renvoyée. Le positionnement de
|
|
ce bit permet aux clients et aux mandataires de gérer la mise en
|
|
cache du résultat de la requête.
|
|
|
|
<note><title>Note</title>
|
|
<p>Il est recommandé de n'utiliser l'option full que dans le cas
|
|
où vous êtes certain que le bit d'exécution du groupe est non
|
|
positionné pour les scripts SSI qui pourraient effectuer l'<code
|
|
>#include</code> d'un programme CGI ou bien produire des sorties
|
|
différentes à chaque accès (ou seraient susceptibles d'être
|
|
modifiées au cours des requêtes ultérieures).</p>
|
|
|
|
<p>Lorsqu'elle est définie à <code>on</code>, la directive
|
|
<directive module="mod_include">SSILastModified</directive>
|
|
l'emporte sur la directive <directive
|
|
module="mod_include">XBitHack</directive>.</p>
|
|
</note>
|
|
|
|
</dd>
|
|
</dl>
|
|
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
</modulesynopsis>
|