From: Lucien Gentis Date: Mon, 29 Jun 2026 15:52:42 +0000 (+0000) Subject: fr doc rebuild. X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=9a04b94295efba641715f5f9f76f7097866173f2;p=thirdparty%2Fapache%2Fhttpd.git fr doc rebuild. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1935714 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/howto/cgi.html.fr.utf8 b/docs/manual/howto/cgi.html.fr.utf8 index 9a501953d6..f1fd758aba 100644 --- a/docs/manual/howto/cgi.html.fr.utf8 +++ b/docs/manual/howto/cgi.html.fr.utf8 @@ -29,8 +29,6 @@  ja  |  ko 

-
Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.

Langues Disponibles:  en  | diff --git a/docs/manual/howto/cgi.xml.meta b/docs/manual/howto/cgi.xml.meta index b7cd1c9800..c7cff59430 100644 --- a/docs/manual/howto/cgi.xml.meta +++ b/docs/manual/howto/cgi.xml.meta @@ -9,7 +9,7 @@ en es - fr + fr ja ko diff --git a/docs/manual/howto/ssi.html.fr.utf8 b/docs/manual/howto/ssi.html.fr.utf8 index b91c714199..eb6f1f27f5 100644 --- a/docs/manual/howto/ssi.html.fr.utf8 +++ b/docs/manual/howto/ssi.html.fr.utf8 @@ -31,18 +31,19 @@  ja  |  ko 

-
Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.

Les SSI permettent d'ajouter du contenu dynamique à des documents -HTML préexistants.

+HTML préexistants sans nécessiter de cadriciel complet d’application. Ils +s’avèrent particulièrement utiles pour insérer des éléments courants — en-têtes, +pieds de page, navigation, horodatages — dans des pages qui, sans cela, seraient +statiques.

top

Qu'est-ce que SSI ?

-

SSI (Server Side Includes) est constitué de directives placées dans - des pages HTML, et évaluées par le serveur au moment où les pages - sont servies. Elles vous permettent d'ajouter du contenu généré - dynamiquement à une page HTML préexistante, sans avoir à servir la - page entière via un programme CGI, ou toute autre technologie de - contenu dynamique.

- -

Par exemple, vous pouvez insérer la directive suivante dans une - page HTML existante :

- -

- <!--#echo var="DATE_LOCAL" --> -

+

Les directives SSI sont des commentaires HTML avec une syntaxe spécifique + que le module mod_include reconnaît et évalue avant que la + page ne soit envoyée au client. Elle sont de la forme suivante :

-

Ainsi, lorsque la page sera servie, la directive sera évaluée et - remplacée par sa valeur :

+

++

+<!--#echo var="DATE_LOCAL" -->
++
+

++

+

Lorsque la page est servie, ce fragment est remplacé par sa valeur :

+

- Tuesday, 15-Jan-2013 19:28:54 EST + Thursday, 18-Jun-2026 14:22:07 EDT

-

Le choix entre l'utilisation des SSI et la génération entière de - la page par un programme quelconque, est en général dicté par la - proportion de contenu statique et de contenu devant être généré - chaque fois que la page est servie. SSI est idéal pour ajouter de - petites quantités d'information, comme l'heure courante dans - l'exemple précédent. Mais si la - plus grande partie de votre page est générée au moment où elle est - servie, vous devez vous tourner vers une autre solution.

+

Les directives étant intégrées dans des commentaires HTML, les + navigateurs les ignoreront si les SSI ne sont pas activées (bien qu’elles + demeurent visibles dans le code source de la page).

top

Configurer votre serveur pour permettre les SSI

-

Pour permettre l'utilisation des SSI sur votre serveur, vous - devez ajouter la directive suivante dans votre fichier - httpd.conf, ou dans un fichier .htaccess - :

-
Options +Includes
+

Pour activer le traitement des SSI, ajoutez la directive suivante à votre + fichier httpd.conf ou à un fichier .htaccess :

+
Options +Includes
+
-

Cette directive indique à Apache que vous désirez permettre la - recherche de directives SSI lors de l'interprétation des fichiers. - Notez cependant que la plupart des configurations contiennent de - nombreuses directives Options - qui peuvent s'écraser les unes les autres. Vous devrez probablement - appliquer ces directives Options au répertoire - spécifique pour lequel vous voulez activer les SSI, afin d'être sûr - qu'elles y seront bien activées.

+

Si cette option est définie, httpd va analyser les fichiers en y + recherchant des directives SSI. Comme la plupart des configurations + contiennent plusieurs directives Options qui peuvent s’outrepasser les unes les autres, + appliquez la directive d’activation au répertoire spécifique pour lequel + vous voulez activer les SSI.

-

Tout fichier ne fera cependant pas l'objet de recherche de - directives SSI. Vous devez indiquer à Apache quels fichiers seront - concernés. Vous pouvez y parvenir en indiquant une extension, comme - .shtml, à l'aide des directives suivantes :

-
AddType text/html .shtml
-AddOutputFilter INCLUDES .shtml
+

Vous devez aussi indiquer à httpd les fichiers qu’il doit analyser. Pour + ce faire, il existe deux approches courantes.

+

La première consiste à indiquer une extension de nom de fichier (en + général .shtml) pour les pages pour lesquelles les SSI sont + activées :

-

Un des désavantages de cette approche réside dans le fait que si - vous voulez ajouter des directives SSI à une page préexistante, vous - devrez changer le nom de cette page, et donc tout lien qui la - contient, de façon à ce qu'elle possède l'extension - .shtml, condition nécessaire pour que les directives - SSI qu'elle contient soient traitées.

+
AddType text/html .shtml
+AddOutputFilter INCLUDES .shtml
+
-

Une autre méthode consiste à utiliser la directive XBitHack :

-
XBitHack on
+

Cette approche a pour désavantage de nécessiter, pour ajouter des SSI à + une page existante, de renommer le fichier (et de mettre à jour tous les + liens vers ce dernier) pour utiliser l’extension .shtml.

+

La seconde approche consiste à utiliser la directive XBitHack :

-

La directive XBitHack - indique à Apache qu'il doit rechercher des directivves SSI dans les - fichiers si leur bit d'exécution est positionné. Il n'est ainsi plus - nécessaire de changer le nom du fichier pour ajouter des directives - SSI à une page préexistante ; vous devez simplement attribuer les - droits d'exécution au fichier à l'aide de chmod.

-

- chmod +x pagename.html -

+
XBitHack on
+
-

Un bref commentaire sur ce qu'il ne faut pas faire. Certaines - personnes peuvent vous conseiller de tout simplement indiquer à - Apache de rechercher des directives SSI dans tous les fichiers - .html, ce qui vous évite d'avoir à gérer les noms de - fichiers avec extension .shtml. Ils n'ont probablement - pas entendu parler de la directive XBitHack. En effet, vous devez - garder à l'esprit qu'en faisant ceci, Apache va devoir rechercher - des directives SSI dans chaque fichier qu'il sert, même s'il n'en - contient aucune. Ce n'est donc pas une bonne idée car les - performances peuvent en être sensiblement affectées.

- -

Bien entendu, sous Windows, il n'y a pas de bit d'exécution à - positionner, ce qui limite un peu vos choix.

- -

Dans sa configuration par défaut, Apache n'envoie pas la date de - dernière modification ou les en-têtes HTTP relatifs à la taille des - contenus dans les pages SSI, car ses valeurs sont difficiles à - calculer pour les contenus dynamiques. Ceci peut induire une - impression de diminution des performances côté client, en empêchant - la mise en cache de votre document. Il existe deux méthodes pour - résoudre ce problème :

+

La directive XBitHack indique + à httpd qu’il doit analyser tout fichier dont le bit d’exécution est + positionné. Ainsi, pour activer les SSI pour une page existante, il suffit + de rendre le fichier exécutable :

+ +
chmod +x pagename.html
+
+ +

+ Évitez de configurer httpd pour analyser tous les fichiers + .html pour y trouver des directives SSI. Cela force en effet le + serveur à parcourir tous les fichiers HTML qu’il sert, même ceux qui n’ont + pas de contenu SSI, ce qui ajoute une surcharge de travail inutile. +

+ +

Sous Windows, il n’y a pas de bit d’exécution ; l’approche avec la + directive XBitHack n’est donc + pas valable dans ce cas. Vous devrez alors utiliser l’approche par extension + de nom de fichier.

+ +

Par défaut, httpd n’envoie pas la date de dernière modification ou les + en-têtes content-length sur les pages SSI, car ces valeurs sont difficiles à + calculer pour un contenu dynamique. Cela peut empêcher la mise en cache et + induire un ressenti de performances plus lentes. Deux approches peuvent + aider :

    -
  1. Utilisez la configuration XBitHack Full. Elle - indique à Apache de déterminer la date de dernière modification en - ne regardant que la date du fichier à l'origine de la requête, - tout en ignorant la date de modification de tout fichier inclus.
    2. - -
  2. Utilisez les directives fournies par le module - mod_expires pour définir de manière explicite la - date d'expiration de vos fichiers, laissant par la-même - aux navigateurs et aux mandataires le soin de déterminer s'il est - opportun ou non de les mettre en cache.
    3. +
  3. Utilisez la directive XBitHack Full qui indique à httpd + qu’il doit déterminer la date de dernière modification à partir du fichier + initialement demandé, tout en ignorant les dates de dernière modification + des fichiers inclus.
    4. + +
  4. Utilisez le module mod_expires pour définir un moment + d’expiration explicite, indiquant ainsi aux navigateurs et aux mandataires + que le contenu peut être mis en cache.
    5. +
top

Directives SSI de base

-

Les directives SSI adoptent la syntaxe suivante :

-

- <!--#fonction attribut=valeur attribut=valeur ... --> -

- -

Le format d'une directive SSI étant similaire à celui d'un - commentaire HTML, si vous n'avez pas activé correctement SSI, le - navigateur l'ignorera, mais elle sera encore visible dans le source - HTML. Si SSI est correctement configuré, la directive sera remplacée - par ses résultats.

+

Les directives SSI utilisent la syntaxe suivante :

+
<!--#function attribute=value attribute=value ... -->
+
-

"fonction" peut prendre de nombreuses formes, et nous décrirons - plus précisément la plupart d'entre eux dans la prochaine version de - ce document. Pour le moment, voici quelques exemples de ce que vous - pouvez faire avec SSI.

+

Si les SSI sont correctement configurées, la directive sera remplacée par + sa sortie. Dans le cas contraire, elle demeurera en tant que commentaire + HTML — invisible à l’utilisateur final, mais présente dans le code source de + la page.

La date courante

-

- <!--#echo var="DATE_LOCAL" --> -

+
<!--#echo var="DATE_LOCAL" -->
+
-

La fonction echo permet d'afficher la valeur d'une - variable. Il existe un grand nombre de variables standards, y - compris l'ensemble des variables d'environnement disponibles pour - les programmes CGI. De plus, vous pouvez définir vos propres - variables à l'aide de la fonction set.

+

La fonction echo a pour sortie la valeur d’une variable. Les + variables standard incluent le jeu complet de variables d’environnement + disponibles pour les programmes CGI, ainsi que les variables que vous pouvez + définir avec set.

-

Si vous n'aimez pas le format sous lequel la date s'affiche, vous - pouvez utiliser la fonction config avec un attribut - timefmt, pour le modifier.

+

Pour personnaliser le format de la date, utilisez la fonction + config avec l’attribut timefmt :

-

- <!--#config timefmt="%A %B %d, %Y" -->
- Today is <!--#echo var="DATE_LOCAL" --> -

+
<!--#config timefmt="%A %B %d, %Y" -->

+Today is <!--#echo var="DATE_LOCAL" -->
+

Date de modification du fichier

-

- Dernière modification du document <!--#flastmod file="index.html" --> -

+
Dernière modification du document <!--#flastmod file="index.html" -->
+

Le format peut là aussi être modifié à l'aide de l'attribut timefmt.

@@ -233,13 +203,11 @@ AddOutputFilter INCLUDES .shtml

Inclusion des résultats d'un programme CGI

-

C'est le cas le plus courant d'utilisation des SSI - afficher les - résultats d'un programme CGI, comme l'universellement adoré - "compteur d'accès".

+

Les SSI permettent d’inclure directement la sortie d’un programme CGI + dans la page :

-

- <!--#include virtual="/cgi-bin/counter.pl" --> -

+
<!--#include virtual="/cgi-bin/counter.pl" -->
+
top
@@ -247,245 +215,180 @@ AddOutputFilter INCLUDES .shtml

Exemples additionnels

-

Vous trouverez dans ce qui suit quelques exemples spécifiques de - ce que vous pouvez faire de vos documents HTML avec SSI.

+

Vous trouverez dans les exemples pratiques suivants des cas d’utilisation + courants des SSI.

Quand ce document a-t-il été modifié ?

-

Nous avons mentionné plus haut que vous pouviez utiliser SSI pour - informer l'utilisateur de la date de dernière modification du - document. Cependant, la méthode pour y parvenir n'a pas été vraiment - abordée. Placé dans votre document HTML, le code suivant va insérer - un repère de temps dans votre page. Bien entendu, SSI devra avoir - été correctement activé, comme décrit plus haut.

-

- <!--#config timefmt="%A %B %d, %Y" -->
- Dernière modification du fichier <!--#flastmod file="ssi.shtml" --> -

+

Une des utilisations courantes des SSI est l’affichage d’un horodatage + « date de dernière modification » sur chaque page. Le code suivant utilise + la variable LAST_MODIFIED ; vous pouvez donc coller le même + extrait dans tout fichier sans modifier son nom :

-

Bien entendu, vous devez remplacer ssi.shtml par le - nom du fichier auquel vous faites référence. Ceci ne conviendra pas - si vous recherchez un morceau de code générique que vous pourrez - insérer dans tout fichier ; dans ce cas, il est préférable - d'utiliser la variable LAST_MODIFIED :

-

- <!--#config timefmt="%D" -->
- This file last modified <!--#echo var="LAST_MODIFIED" --> -

+
<!--#config timefmt="%D" -->

+Date de dernière modification de ce fichier <!--#echo var="LAST_MODIFIED" -->
+
-

Pour plus de détails sur le format timefmt, tapez - strftime dans votre moteur de recherche préferé. La - syntaxe est identique.

+

Pour des détails à propos des chaînes de formatage de + timefmt, voir la documentation de strftime dans le + manuel de référence de la bibliothèque C de votre système.

-

Si le site que vous gérez comporte plus que quelques pages, vous - allez vite vous apercevoir qu'effectuer des modifications sur toutes - ces pages peut devenir très contraignant, en particulier si vous - voulez qu'elles conservent un aspect homogène.

- -

Inclure un fichier pour un en-tête et/ou un pied de page peut - simplifier cette corvée de mises à jour. Il vous suffit de - confectionner un fichier de pied de page, et de l'inclure dans - chaque page à l'aide de l'élément SSI include. Pour - définir le fichier à inclure, la fonction include peut - utiliser soit l'attribut file, soit l'attribut - virtual. L'attribut file est un chemin de - fichier relatif au répertoire courant. C'est à dire qu'il - ne peut ni avoir pour valeur un chemin absolu (commençant par /), ni - comporter "../" dans son chemin. L'attribut virtual est - probablement plus commode, et peut spécifier une URL relative au - document servi. Elle peut commencer par un /, mais le fichier inclus - et le fichier servi doivent résider sur le même serveur.

-

- <!--#include virtual="/footer.html" --> -

+

Sur un site qui comporte plus que quelques pages, maintenir un + en-tête ou un pied de page cohérent sur toutes les pages peut s’avérer + fastidieux. Les SSI résolvent ce problème en permettant de stocker le + contenu partagé dans un seul fichier et d’inclure ce dernier n’importe + où :

+ +
<!--#include virtual="/footer.html" -->
+
+ +

La fonction include accepte deux attributs : + file qui spécifie un chemin relatif au répertoire actuel (il ne + peut pas spécifier un chemin absolu ou contenant ../), et + virtual qui spécifie un URL relatif au document servi (et qui + peut commencer par /, mais doit être sur le même serveur).

+ +

Les directives SSI au sein des fichiers inclus sont évaluées normalement + et les inclusions peuvent être imbriquées. Cela signifie que vous pouvez + placer un horodatage LAST_MODIFIED dans votre fichier de pied + de page, et qu’il sera évalué dans le contexte de chaque page qui l’inclut.

-

Je combinerai souvent ces deux derniers points, en ajoutant une - directive LAST_MODIFIED dans un fichier de pied de page - destiné à être inclus. Le fichier inclus peut contenir des - directives SSI, et les inclusions peuvent être imbriquées - à - savoir, le fichier inclus peut inclure un autre fichier, etc...

top
-

Que puis-je configurer d'autre ?

+

Autres options de configuration

-

En plus du format de date, vous pouvez utiliser l'élément - config pour configurer deux autres choses.

+

En plus de timefmt, la fonction config accepte + deux autres attributs.

-

En général, lorsque quelque chose se passe mal avec votre - directive SSI, vous recevez le message :

+

L’attribut errmsg modifie le message d’erreur affiché + lorsqu’une directive SSI échoue. Le message par défaut est :

- [an error occurred while processing this directive] +[an error occurred while processing this directive]

-

Pour modifier ce message, vous pouvez utiliser l'attribut - errmsg avec la fonction config :

-

- <!--#config errmsg="[Il semblerait que vous ne sachiez pas - utiliser les SSI]" --> -

+

Vous pouvez le remplacer par un contenu plus adapté à votre site :

+
<!--#config errmsg="[Content unavailable]" -->
+
-

Il est cependant probable que les utilisateurs finaux ne voient - jamais ce message, car vous aurez résolu tous les problèmes issus de - vos directives SSI avant que votre site ne soit mis en production. - (N'est-ce pas ?)

- -

Vous pouvez aussi modifier le format sous lequel les tailles de - fichiers sont affichées à l'aide de l'attribut sizefmt. - Vous pouvez spécifier bytes pour un affichage en - octets, ou abbrev pour un affichage plus concis en Ko - ou Mo, selon le cas.

-
top
+

L’attribut sizefmt contrôle la manière dont les tailles de + fichier sont spécifiées : bytes pour un décompte en octets ou + abbrev pour une forme abrégée en Ko ou Mo.

+
top

Exécution de commandes

-

Voici autre chose que vous pouvez faire avec la fonction - exec. Vous pouvez vraiment faire exécuter une commande - par SSI en utilisant le shell (/bin/sh, pour être plus - précis - ou le shell DOS, si vous êtes sous Win32). Par exemple, ce - qui suit vous permet d'afficher le contenu d'un répertoire.

-

- <pre>
- <!--#exec cmd="ls" -->
- </pre> -

- -

ou, sous Windows

-

- <pre>
- <!--#exec cmd="dir" -->
- </pre> -

+

La fonction exec permet d’exécuter une commande du shell et + d’inclure sa sortie dans la page. Sur les systèmes de style Unix, la + commande est exécutée via /bin/sh, et sous Windows via + l’interpréteur de commande.

-

Vous noterez probablement l'étrange formatage provoqué par cette - directive sous Windows, car la sortie de dir contient - la chaîne de caractères "<dir>", ce qui trompe le - navigateur.

- -

Notez que cette fonctionnalité est très dangereuse, car elle va - permettre d'exécuter tout code associé à l'élément - exec. Si vous êtes dans la situation où les - utilisateurs peuvent éditer le contenu de vos pages web, dans le cas - d'un "livre d'or" par exemple, assurez-vous de désactiver cette - fonctionnalité. Vous pouvez, tout en permettant les SSI, désactiver - la fonctionnalité exec à l'aide de l'argument - IncludesNOEXEC de la directive - Options.

-
top
+
<pre>
+<!--#exec cmd="ls" -->
+</pre>
+
+

+ La fonctionnalité exec constitue un risque de sécurité + significatif. En effet, elle exécute des commandes arbitraires avec les + privilèges du processus du serveur web. Si les utilisateurs peuvent éditer + du contenu sur votre site, assurez-vous que cette fonctionnalité soit + désactivée en spécifiant IncludesNOEXEC au lieu de + Includes dans la définition de la directive Options. +

+
top

Techniques SSI avancées

-

Outre l'affichage de contenu, les SSI d'Apache vous permettent de - définir des variables, et de les utiliser dans des comparaisons et - des conditions.

+

Au-delà de la simple inclusion de contenu, les SSI prennent en charge les + variables et les expressions conditionnelles, rendant possible la génération + de contenus différents en fonction du contexte de la requête.

Définition de variables

-

Avec l'élément set, vous pouvez définir des - variables pour un usage ultérieur. Comme nous en aurons besoin plus - loin, nous allons en parler tout de suite. La syntaxe se présente - comme suit :

-

- <!--#set var="name" value="Rich" --> -

+

La directive set permet de définir des variables à utiliser + plus tard dans la page :

-

Pour affecter une valeur à vos variables, en plus de la - définition littérale de l'exemple ci-dessus, vous pouvez utiliser - une autre variable, y compris les variables d'environnement, ou les variables - décrites plus haut (comme LAST_MODIFIED par exemple). - Pour indiquer qu'il s'agit d'une variable et non d'une chaîne, vous - devez utiliser le symbole dollar ($) devant le nom de la - variable.

+
<!--#set var="name" value="Rich" -->
+
-

<!--#set var="modified" value="$LAST_MODIFIED" --> -

+

Les variables peuvent référencer d’autres variables (y compris des variables d’environnement) en utilisant le signe dollar + ($) comme préfixe :

-

Pour insérer un caractère $ dans la valeur de votre variable, - vous devez l'échapper à l'aide d'un backslash.

-

- <!--#set var="cost" value="\$100" --> -

+
<!--#set var="modified" value="$LAST_MODIFIED" -->
+
-

Enfin, si vous voulez insérer une variable dans une chaîne, et - s'il y a une chance pour que le nom de la variable se confonde avec - le reste de la chaîne, vous pouvez l'entourer d'accolades pour - eviter toute confusion (Il est difficile de trouver un bon exemple - pour illustrer ceci, mais j'espère que vous comprendrez).

-

- <!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" --> -

+

Pour inclure un signe dollar littéral, protégez-le avec une + contre-oblique :

+ +
<!--#set var="cost" value="\$100" -->
+
+ +

Lorsqu'un nom de variable risque d'être ambigu au sein d'une chaîne plus + longue, utilisez des accolades pour le délimiter :

+ +
<!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" -->
+

Expressions conditionnelles

-

Maintenent que nous avons des variables, et que nous pouvons - définir et comparer leurs valeurs, nous sommes à même de les - utiliser dans des expressions conditionnelles. Ceci confère à SSI le - statut de petit langage de programmation. - mod_include fournit une structure if, - elif, else, endif pour la - construction d'expressions conditionnelles, ce qui vous permet de - générer plusieurs pages logiques à partir d'une seule vraie - page.

+

mod_include fournit les éléments if, + elif, else et endif permettant de + construire une logique conditionnelle. Cette fonctionnalité permet de + générer des sorties différentes à partir d’une seule page physique.

-

La structure de l'expression conditionnelle est :

-

- <!--#if expr="condition" -->
- <!--#elif expr="condition" -->
- <!--#else -->
- <!--#endif --> -

+

La structure est :

-

Une condition peut revêtir la forme de toute comparaison - logique - soit une comparaison de valeurs avec une autre, soit une - vérification de la "vérité" d'une valeur particulière (Une chaîne - donnée est vraie si elle n'est pas vide). Pour une liste exhaustive - des opérateurs de comparaison disponibles, voir la documentation du - module mod_include.

+
<!--#if expr="test_condition" -->

+<!--#elif expr="test_condition" -->

+<!--#else -->

+<!--#endif -->
+
-

Par exemple, spour insérer l'heure du jour dans votre page web, - vous pouvez ajouter ces lignes dans la page HTML :

+

Une test_condition peut comparer des valeurs ou vérifier si une + variable n’est pas vide. Voir la documentation de + mod_include pour la liste complète des opérateurs de + comparaison.

-

- Good - <!--#if expr="%{TIME_HOUR} <12" -->
- morning!
- <!--#else -->
- afternoon!
- <!--#endif -->
-

- -

Toute autre variable (que vous avez définie, ou une variable - d'environnement normale) peut être utilisée dans les expressions - conditionnelles. Voir le document Expressions - rationnelles dans le serveur HTTP Apache pour plus de détails à - propos du fonctionnement du moteur d'évaluation des expressions - rationnelles.

- -

Associée à la possibilité avec Apache de définir - des variables d'environnement à l'aide de directives - SetEnvIf, ainsi que d'autres directives en rapport, - cette fonctionnalité vous permet d'ajouter une grande variété - de contenus dynamiques côté serveur sans avoir à concevoir une - application web de A à Z.

+

Par exemple, pour afficher des salutations différentes en fonction de + l’heure du jour :

+ +
Good
+<!--#if expr="%{TIME_HOUR} <12" -->

+morning!

+<!--#else -->

+afternoon!

+<!--#endif -->

+
+
+ +

Toute variable — définie par l’utilisateur ou issue de l’environnement + — peut être utilisée dans les expressions conditionnelles. Voir Les expressions dans le Serveur HTTP Apache pour des + détails complets à propos du moteur d’évaluation des expressions.

+ +

Combinées avec la capacité de httpd à définir des variables + d’environnement en utilisant SetEnvIf et les directives apparentées, + les SSI conditionnelles peuvent traiter une grande variété de scénarios de + contenu dynamique sans nécessiter de cadriciel complet d’applications.

top

Conclusion

-

SSI ne remplace certainement pas CGI, ou d'autres technologies - utilisées pour la génération de pages web dynamiques. Mais c'est une - bonne méthode pour ajouter des petits contenus dynamiques à vos - pages, sans devoir fournir un gros effort supplémentaire.

+

Pour les sites principalement statiques mais nécessitant quelques touches + dynamiques, les SSI évitent la surcharge de travail induite par la + configuration d’une pile complète d’applications. Elles ne requièrent que + mod_include et quelques lignes de configuration pour + fonctionner.

Langues Disponibles:  en  | diff --git a/docs/manual/howto/ssi.xml.meta b/docs/manual/howto/ssi.xml.meta index 9b8292c558..71d5a50343 100644 --- a/docs/manual/howto/ssi.xml.meta +++ b/docs/manual/howto/ssi.xml.meta @@ -9,7 +9,7 @@ en es - fr + fr ja ko diff --git a/docs/manual/logs.html.fr.utf8 b/docs/manual/logs.html.fr.utf8 index 4ca53dff7d..c990a1c196 100644 --- a/docs/manual/logs.html.fr.utf8 +++ b/docs/manual/logs.html.fr.utf8 @@ -525,106 +525,105 @@ LogFormat "%!200,304,302{Referer}i" refererlog

Rotation des journaux

-

Même dans le cas d'un serveur modérément sollicité, la quantité - d'informations stockées dans les fichiers journaux est très importante. - Le fichier journal des accès grossit en général d'1 Mo ou plus toutes - les 10000 requêtes. Il est par conséquent nécessaire d'effectuer - périodiquement la rotation des journaux en déplaçant ou supprimant les - fichiers correspondants. On ne peut pas le faire pendant que le serveur - est en cours d'exécution, car Apache httpd va continuer à écrire dans l'ancien - fichier journal aussi longtemps qu'il le maintiendra ouvert. - C'est pourquoi le serveur doit être - redémarré après le déplacement ou la - suppression des fichiers journaux de façon à ce qu'il en ouvre - de nouveaux.

- -

Avec un redémarrage graceful, on peut faire en sorte que le - serveur ouvre de nouveaux fichiers journaux sans perdre de connexions - existantes ou en cours avec les clients. Cependant, pour que ceci soit - possible, le serveur doit continuer à écrire dans les anciens fichiers - journaux pendant qu'il termine le traitement des requêtes en cours. - Il est donc nécessaire d'attendre un certain temps après le rédémarrage - avant d'effectuer tout traitement sur les fichiers journaux. Voici un - scénario typique dans lequel on effectue une simple rotation des - journaux en compressant les anciens fichiers correspondants afin - de gagner de l'espace disque :

+

Même sur un serveur modérément sollicité, les fichiers journaux + grossissent rapidement — le journal des accès croît à peu près de 1 Mo ou + plus toutes les 10000 requêtes. Sans rotation, les journaux consomment de + plus en plus d’espace disque et deviennent difficiles à analyser. Il est + donc recommandé de configurer une rotation automatique des journaux dès le + départ.

+ +

Utilisation de rotatelogs (recommandé)

+ -

- mv access_log access_log.old
- mv error_log error_log.old
- apachectl graceful
- sleep 600
- gzip access_log.old error_log.old -

+

L’approche la plus simple consiste à utiliser le programme + rotatelogs intégré à httpd en utilisant la redirection des journaux. Ce programme permet une + rotation des journaux sans avoir à redémarrer le serveur et sans outil + externe. Pour une rotation des journaux toutes les 24 heures :

+ +
CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/httpd/access_log 86400" combined
+ErrorLog  "|/usr/local/apache/bin/rotatelogs /var/log/httpd/error_log 86400"
+
+ +

Pour une rotation lorsque la taille du journal atteint une certaine + valeur (par exemple 100 Mo) :

+ +
CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/httpd/access_log 100M" combined
+
+ +

Vous pouvez aussi utiliser un motif de nom de fichier avec horodatage + sous forme d’une chaîne au format strftime :

+ +
CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/httpd/access_log.%Y-%m-%d 86400" combined
+
+ +

Voir rotatelogs pour une description complète de ses + options, en particulier les temps de décalage, les limitations de nombre de + fichiers et la compression.

+ + +

Utilisation de logrotate ou de la gestion des journaux par le + système

+ + +

La plupart des distributions de Linux fournissent le programme + logrotate qui effectue une rotation, une compression et une + expiration des fichiers journaux selon une planification. Si votre + distribution comporte déjà une configuration de logrotate pour httpd + (examinez /etc/logrotate.d/), elle gère peut-être déjà la + rotation pour vous.

-

La section suivante présente une autre méthode de rotation des journaux - qui consiste à utiliser les - journaux redirigés.

+

Lorsqu’on utilise un outil de rotation externe comme + logrotate, il faut faire en sorte que httpd réouvre ses + fichiers journaux quand les anciens ont été mis de côté. Pour ce faire, + l’approche standard est un redémarrage graceful :

+ +
/usr/sbin/apachectl graceful
+
+ +

Votre script postrotate dans la configuration de logrotate + doit contenir cette dernière commande (ou la commande équivalente + systemctl reload). Comme httpd continue d’écrire dans + l’ancien fichier jusqu’à ce qu’il reçoive le signal, tout post-traitement + des fichiers ayant subi une rotation doit prévoir un bref délai.

+ +
top

Journaux redirigés

-

Nous avons vu que le démon httpd écrivait les informations de - journalisation des erreurs et des accès dans un fichier journal ; - il peut aussi - rediriger ces informations vers un autre processus par l'intermédiaire d'un - tube de communication (pipe). Cette fonctionnalité améliore - considérablement la souplesse de la journalisation, sans ajouter de code - au serveur principal. Pour rediriger les informations de journalisation - vers un tube de communication, remplacez simplement le nom de fichier - journal par - le caractère pipe "|", suivi du nom de l'exécutable qui va - recueillir les entrées de journal sur son entrée - standard. Le serveur va - lancer le processus de redirection des journaux au moment du démarrage du - serveur, et le relancera s'il cesse de fonctionner - pendant l'exécution du serveur. - (Nous dénommons cette technique "journalisation - redirigée fiable" grâce à cette dernière fonctionnalité.)

- -

Les processus de journalisation redirigée sont lancés par le processus - httpd parent, et héritent de l'UID de ce dernier. Cela signifie que les - programmes de journalisation dirigée s'exécutent généralement en tant que - root. Il est donc très important que ces programmes soient simples et - sécurisés.

- -

Un des grands avantages de la journalisation redirigée est la possibilité - d'effectuer la rotation des journaux sans avoir à redémarrer le serveur. Pour - accomplir cette tâche, le serveur HTTP Apache fournit un programme simple - appelé rotatelogs. Par exemple, pour une rotation des - journaux toutes les 24 heures, ajoutez ces lignes :

- - 
CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" common
- - -

Notez que l'ensemble de la commande qui sera appelée par le tube de - communication a été placée entre guillemets. Bien que cet exemple - concerne le journal des accès, la même technique peut être utilisée - pour le journal des erreurs.

- -

Comme la journalisation conditionnelle, la journalisation redirigée est - un outil très puissant, mais si elle existe, il est préférable d'utiliser - une solution plus simple comme le traitement à posteriori hors ligne.

- - -

Par défaut, le processus de redirection du journal est lancé sans - invoquer un shell. Pour invoquer un shell, utilisez "|$" - au lieu de "|" (en général avec /bin/sh -c) - :

- - 
# Invocation de "rotatelogs" en utilisant un shell
-CustomLog "|$/usr/local/apache/bin/rotatelogs   /var/log/access_log 86400" common
- - - -

Il s'agissait du comportement par défaut sous Apache 2.2. Selon - les spécificités du shell, ceci peut générer un processus shell - supplémentaire pour toute la durée du programme de redirection du - journal, et induire des problèmes de gestion de signaux au cours du - redémarrage. La notation "||" est aussi supportée pour - des raisons de compatibilité avec Apache 2.2 et est équivalente à - "|".

+

httpd peut écrire dans les fichiers journaux des erreurs et des accès à + travers un tube (pipe) vers un autre processus, plutôt que d’écrire + directement dans un fichier. Pour mettre en œuvre cette redirection, + remplacez le nom du fichier par le caractère pipe "|", suivi de + la commande qui recevra les entrées du journal sur son entrée standard :

+ +
CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/httpd/access_log 86400" combined
+
+ +

httpd démarre le processus de redirection des journaux au démarrage du + serveur et le redémarre automatiquement s’il se plante (ce comportement est + parfois nommé « journalisation redirigée fiable »). L’ensemble de la + commande à partir du caractère pipe doit être entourée de guillemets — cette + syntaxe fonctionne pour les deux directives CustomLog et ErrorLog.

+ +

Les processus de redirection des journaux sont lancés par le processus + httpd parent et héritent de son identifiant utilisateur. Cela signifie en + général qu’ils s’exécutent en tant que root ; faites donc en sorte que les + programmes de redirection des journaux restent simples et sécurisés.

+ +

Par défaut, le processus de redirection des journaux est lancé + directement, sans passer par un shell. Vous pouvez utiliser + "|$" à la place de "|" pour effectuer ce lancement + via un shell (en général /bin/sh -c) :

+ +
CustomLog "|$/usr/local/apache/bin/rotatelogs /var/log/httpd/access_log 86400" combined
+
+ +

La variante avec shell est parfois requise si votre commande redirigée + utilise des fonctionnalités du shell comme les caractères génériques ou le + développement de variable. Dans la plupart des cas, il est préférable + d’utiliser l’invocation directe (sans passer par un shell).

Note à propos de la plateforme Windows

Notez que sous Windows, la mémoire allouée au bureau (desktop diff --git a/docs/manual/logs.xml.ja b/docs/manual/logs.xml.ja index 125c7f88ee..ff77873d37 100644 --- a/docs/manual/logs.xml.ja +++ b/docs/manual/logs.xml.ja @@ -1,7 +1,7 @@ - + + + + + + + diff --git a/docs/manual/rewrite/flags.xml.ja b/docs/manual/rewrite/flags.xml.ja index 4617dc70c9..c3deebd74d 100644 --- a/docs/manual/rewrite/flags.xml.ja +++ b/docs/manual/rewrite/flags.xml.ja @@ -1,7 +1,7 @@ - + + + + + + + + + + + + + diff --git a/docs/manual/rewrite/tech.xml.ja b/docs/manual/rewrite/tech.xml.ja index d323373a9f..423313e75c 100644 --- a/docs/manual/rewrite/tech.xml.ja +++ b/docs/manual/rewrite/tech.xml.ja @@ -1,7 +1,7 @@ - + + + +