Project:Omega.org

Par Kevin Hemenway, le 11/04/2003

Traduit par Olivier, le 26/04/2003

Note de l’éditeur : Dans son article précédent réécrit pour Jaguar, Kevin Hemenway vous a montré comment délivrer des pages web depuis Mac OS X.
Dans ce tutoriel, il explore le monde des accès CGI.
Pour profiter complètement de ce que Kevin vous propose ici, vous aurez besoin d’une bonne connaissance de l’application Terminal.

Si vous n’êtes pas familier avec cette application, je vous recommande de lire notre article compagnon sur le Terminal, “Apprentissage du Terminal avec Jaguar”.  Une fois que vous êtes à l’aise avec la ligne de commande, vous pouvez revenir sur cet article et aller plus loin avec Apache.

En Apprendre un Peu Plus à Propos d’Apache

Après le travail que nous avons effectué dans l’article précédent, nous avons obtenu une URL plus esthétique, mais notre site est toujours peu intéressant.
Nous avons besoin de fonctionnalités qui peuvent impressionner le patron, pour les activer, nous avons besoin d’utiliser le Terminal de Mac OS X.
Nous allons estimer que vous savez comment éditer et sauvegarder des fichiers depuis la ligne de commande, soit depuis le shell (par vi ou emacs) ou un éditeur graphique comme BBEdit.
Nous préférons BBEdit et l’utilitaire shell (que vous pouvez installer en allant dans Préférences->Utilitaires->Installer Utilitaire “bbedit”).

Avant que nous ne mettions en place les fonctionnalités, nous avons besoin de savoir où se trouvent le fichier de configuration d’Apache.
Pour le savoir nous interrogerons le serveur Apache lui-même, alors ouvrez un Terminal et entrez la ligne de commande suivante :

httpd -V

Ceci affichera à l’écran des informations spécifiques concernant l’installation d’Apache (cette commande fonctionnera avec n’importe quelle installation Apache–pour Mac, Linux ou Windows).
Sur une machine OS X 10.2.4, nous pouvons voir que nous utilisons Apache 1.3.27 :

Server version: Apache/1.3.27 (Darwin)
Server built:   10/16/02 21:48:47

Ainsi que où se trouvent les fichiers de configuration serveur et de log erreur :

-D SERVER_CONFIG_FILE="/etc/httpd/httpd.conf"
-D DEFAULT_ERRORLOG="/var/log/httpd/error_log"

En plus du fichier de log erreur par défaut (qui est extrêmement utile pour débogguer), Apache écrit également dans /var/log/httpd/access_log, qui conserve une trace de toutes les requêtes reçues par votre serveur web.
Remarque : Dans des versions précédentes de la version d’Apache livrée par Apple, un paramètre DEFAULT_XFERLOG serait également apparu lors de l’exécution de la commande httpd -V, et il pointerait vers le fichier access_log que nous venons juste de mentionner.
Cette fonctionnalité a depuis été transposée dans une instruction CustomLog dans le fichier de configuration d’Apache.
Si vous n’avez aucune idée de ce dont je parle, ce n’est pas grave–cela n’est utile que pour les experts.

Apprentissage des Accès CGI

Il est maintenant temps de se familiariser avec une des fonctions les plus utilisées sur un web serveur : CGI.
Sans vouloir devenir ésotérique, CGI vous permet d’installer des milliers de scripts différents qui peuvent être accédé depuis n’importe quel navigateur.
Les scripts CGI sont souvent écrits en Perl (également installé par défaut dans OS X), et vous permettent d’accéder aux des bases de données, utiliser des formulaires, faire du chat et bien d’autres.

Apache est livré avec deux scripts simples qui peuvent vérifier si CGI est correctement configuré.
Avant que nous les testions, voyons ce que nous pouvons apprendre depuis le fichier de configuration Apache.
Pour démarrer, ouvrez votre fichier de configuration dans votre éditeur de texte favori (dans notre exemple il s’agit de BBEdit) :

bbedit /etc/httpd/httpd.conf

Attention : le fichier de configuration d’Apache est assez gros, mais également assez bien commenté.
Prenez bien en compte la note d’introduction qui dit : “NE vous contentez PAS de lire les instructions…sans les comprendre. Elles ne sont ici que comme astuces ou notes. Si vous êtes incertain, consulter la documentation en ligne. Vous avez été prévenu.”
La documentation en ligne est disponible sur le site web d’Apache.

La façon la plus rapide de trouver et apprendre depuis le fichier de configuration d’Apache est de rechercher les fonctionnalités que vous souhaitez activer.
Dans notre cas, recherchons “CGI”.
La première ligne que nous trouvons est :

LoadModule cgi_module libexec/httpd/mod_cgi.so

Suivi rapidement de :

AddModule mod_cgi.c

Vous verrez un certain nombre de ces lignes dans le fichier de configuration d’Apache.
Si vous avez déjà travaillé avec des programmes à base de plugin, vous les reconnaitrez rapidement–ces lignes chargent les différentes fonctionnalités au niveau du serveur Apache.
Apache les appelle ” modules”, et vous verrez de nombreux noms de modules prefixés par mod_, tels que mod_perl et mod_php.
Les lignes qui sont commentées (c’est-à-dire celles qui commencent par le caractère #) sont inactives.

Comme nos lignes CGI sont déjà actives (elles ne débutent pas par #), nous continuons notre recherche :

ScriptAlias /cgi-bin/ "/Library/WebServer/CGI-Executables/"

<Directory "/Library/WebServer/CGI-Executables">
    AllowOverride None
    Options None
    Order allow,deny
    Allow from all
</Directory>

La directive ScriptAlias nous permet d’associer une URL à un point sur votre disque dur.
Dans ce cas, la ligne ScriptAlias associe http://127.0.0.1/cgi-bin/ à /Library/WebServer/CGI-Executables/ sur le disque dur.
Si vous listez ce dossier, vous verrez deux scripts CGI que j’ai mentionnés plus haut : printenv et test-cgi.
Le bloc <Directory> est peu important pour le moment, alors nous poursuivons vers notre prochain résultat de recherche :

# AddHandler cgi-script .cgi

Vous voici face à la première décision majeure concernant votre installation Apache.
Quand un répertoire a été ScriptAliasé (comme votre répertoire CGI-Executables), les fichiers contenus dans ce répertoire sont toujours exécutés comme des scripts CGI.
Si les fichiers sont déplacés hors de ce répertoire (disons par exemple dans votre DocumentRoot), ils seraient délivrés comme des fichiers normaux.

En activant la ligne AddHandler, vous indiquez à Apache comment exécuter et lancer n’importe quel fichier se terminant par .cgi.
Ceci peut être le cas pour tout répertoire et tout utilisateur, et est souvent considéré comme une faille de sécurité (par exemple, si vous avez un serveur FTP avec accès non sécurisé qui accède directement à votre espace web, un utilisateur mal intentionné pourrait envoyer un script .cgi vérolé, puis l’exécuter depuis son navigateur).

Dans l’installation d’origine d’Apache sur Mac OS X, les scripts CGI sont uniquement autorisés à l’intérieur de /Library/Webserver/CGI-Executables/.
Supprimer les commentaires des lignes précédentes (en effaçant le caractère #) permet l’exécution de scripts CGI depuis n’importe quel répertoire utilisateur, tel que /Users/morbus/Sites.
Dans notre cas, comme nous n’utilisons pas les répertoires Users (parce qu’ils provoquent la création d’URL peu esthétiques pour l’intranet GatesMcFarlaneCo), nous allons laissé ces lignes commentées.

Si l’accès CGI est déjà activé (comme pour les lignes AddModule et loadModule au début de notre article), nous devrions être capable d’exécuter un des scripts pré-installés et de voir le résultat, pas vrai ?
Essayez http://127.0.0.1/cgi-bin/test-cgi (oui, test-cgi et non pas test.cgi).
La page d’accueil n’est probablement pas très réconfortante : “FORBIDDEN” hurle Apache. “Vous n’avez pas les droits d’accès !”.

Hein ? Pourquoi cela n’a-t-il pas fonctionné ?
C’est maintenant que les fichiers de log du serveur web Apache vont se révéler utiles.
Si vous vous souvenez de notre discussion à propos de httpd -V auparavant, vous vous souviendrez que le fichier log des accès d’Apache est /var/log/httpd/access_log.
Regardons la dernière ligne de ce fichier, atteinte facilement par tail :

tail /var/log/httpd/access_log

Vous verrez que la dernière ligne ressemble à :

127.0.0.1 - - [19/Feb/2003:20:26:22 -0500]
  "GET /cgi-bin/test-cgi HTTP/1.1" 403 292

En deux mots, cette ligne indique d’où la requête provient (127.0.0.1), l’heure à laquelle le fichier à été demandé, le protocole utilisé (HTTP/1.1), le code réponse (403), et la taille de cette réponse (292 octets).
Tout est bien indiqué, mais cela ne nous dit pas ce qui ne va pas.
Pour cela nous devons visualiser notre fichier de log erreurs (dont l’emplacement est également révélé par httpd -V) :

tail /var/log/httpd/error_log
.
.
[Wed Feb 19 20:26:22 2003] [error] [client 127.0.0.1]
  file permissions deny server execution:
  /Library/WebServer/CGI-Executables/test-cgi

Et voilà !
Ceci nous indique exactement ce qui ne va pas–les droits d’accès au fichier ne sont pas adaptés.
Pour qu’Apache puisse exécuter un script CGI, le script en question doit avoir les droits en “exécution”.
Pour donner ces droits au fichier test-cgi, tapez ce qui suit dans le Terminal :

cd /Library/WebServer/CGI-Executables
sudo chmod 755 test-cgi

Après l’exécution de cette commande (le système vous demandera le mot de passe administrateur), rechargez l’URL, et vous verrez alors différentes informations d’environnement.
(Pour en savoir plus sur les droits/permissions et le chmod et sudo, consultez votre moteur de recherche internet favori, un geek sympa, ou votre bibliothèque de livre O’Reilly.)

Avec ces concepts CGI assimilés, vous pouvez maintenant installer des applications CGI pour agrémenter votre intranet.
Vous avez besoin d’une application de gestion de contenu pour que les développeurs de GatesMcFarlaneCo soient au courant des progrès du développement ?
Essayer le très populaire Movable Type.

Activation des Includes Server-Side

Les Includes Server-Side, plus connus sous le nom de SSI, vous permettent d’inclure du texte issu d’autres fichiers ou scripts dans la page en cours de traitement.
Ce processus est effectué par Apache avant que la page ne soit envoyée à l’utilisateur–un visiteur ne peut ni savoir ce que vous avez inclus, ni où.

En général, les SSI sont utilisés pour inclure des éléments comme les en-têtes, bas de page et des cadres “Quoi de neuf” répétés sur toutes les pages du site.
Quand vous devez changer les dimensions du logo de votre site, par exemple, vous pouvez modifier l’en-tête inclu uniquement, et les modifications seront répercutées immédiatement sur toute page intégrant cet include.

Les SSI, par défaut, sont désactivés.
Pour les activer, nous allons utiliser la même astuce “recherche de la fonctionnalité” déjà utilisée.
Ouvrez votre fichier de configuration Apache, et rechercher “server side”.
Notre seul résultat est situé près du AddHandler des scripts CGI :

# To use server-parsed HTML files
#
# AddType text/html .shtml
# AddHandler server-parsed .shtml

Heureusement, c’est exactement ce que nous recherchons.
Ces simples lignes Add nous en apprennent beaucoup.
Elles établissent un modèle basé sur ce que nous avons déjà vu pour les CGI.
Si vous vous en souvenez, nous aurions pu activer la fonctionnalité CGI pour les fichiers se terminant par .cgi–en d’autres termes, tout fichier créé avec une extension .cgi (qu’il soit ou non un programme CGI), aurait été traité comme un script executable.

De même, ces lignes nous indiquent que nous pouvons activer la fonctionnalité SSI pour les fichiers se terminant par .shtml.
Que nous utilisions ou non la fonctionnalité dans ces fichiers importe peu–ils seront quand même traités comme tel.

Ceci est un point important.
Vous pourriez penser “si les SSI sont si pratiques, pourquoi ne pas les activer pour les fichiers .html ?”
En fait, il s’agit d’un problème de vitesse.
Si vous avez 3.000 fichiers .html, et seulement 1.000 d’entre eux utilisent SSI, Apache recherchera quand même des instructions SSI dans les 2.000 autres.
C’est un gaspillage de ressources.
Même si le traitement des SSI n’entraine que peu charge sur le système, si vous recevez 50.000 requêtes par seconde, la charge cumulée peu devenir importante.
Cela n’est pas trop important pour notre intranet GatesMcFarlaneCo, mais c’est bon à savoir pour de futurs projets Apache.

Pour le moment, enlever le commentaire des lignes AddType et AddHandler.
Ceci libérera la puissance des SSI.
Mais où ?
Avec les CGI, nous avons vu une configuration qui indiquait que les CGI se trouvaient dans /Library/Webserver/CGI-Executables/–nous devons maintenant indiquer à Apache où trouver nos SSI.

Comme nous construisons un intranet qui se trouvera au niveau de /Library/Webserver/Documents (le DocumentRoot d’Apache), c’est là que nous voulons que nos SSI soient actifs.
Allez en haut du fichier de configuration Apache et recherchez “/Library/Webserver/Documents/”.
Le deuxième résultat ressemble à ce qui suit (nous avons enlevé les lignes commentées de cet exemple) :

<Directory "/Library/WebServer/Documents">
   Options Indexes FollowSymLinks MultiViews
   AllowOverride None
   Order allow,deny
   Allow from all
</Directory>

Vous remarquez que ces lignes sont semblables à l’entrée Directory que nous avons vu quand nous recherchions les CGI.
Comme d’habitude nous allons passez dessus rapidement (nous étudierons plus attentivement les lignes que nous avons ignorées plus loin dans notre série).
Pour l’instant, ajoutez le mot Includes à la ligne Options de cette façon :

Options Indexes FollowSymLinks MultiViews Includes

Options est une directive Apache qui peut activer ou non différentes fonctionnalités pour le <Directory> (Répertoire) spécifié et tous ses sous-répertoires.
Un sous-répertoire peut modifier la configuration donnée par son père.
Dans de prochains articles, nous discuterons un peu plus des différentes configurations disponibles avec Options.

Comme nous avons effectué des modifications dans le fichier de configuration d’Apache, nous devons le relancer (pour qu’il prenne en compte le nouveau /etc/httpd/httpd.conf).
La façon la plus simple est par le panneau de préférences Partage.
Comme nous avons démarré le serveur web en partie 1, nous devons maintenant l’arrêter puis le redémarrer pour que nos modifications soient prises en compte.

Remarque : Si après avoir cliqué sur Démarrer, la ligne d’état indique toujours “En cours de chargement…” après plusieurs secondes, vous devez avoir une erreur dans le fichier de configuration Apache, créée lors de la modification.
Les préférences de Partage s’attendent à un fichier de configuration valide, et restent bloquées tant qu’elle ne reçoivent pas de réponse positive d’Apache (qu’elles n’obtiendront jamais).
Pour vérifier le fichier de configuration, entrez httpd -t dans le Terminal–s’il y a une erreur, le numéro de la ligne erronée sera affiché.

Pour vérifier que les SSI fonctionnent correctement, renommez le fichier index.html que nous avons créé en première partie en index.shtml (puisque .shtml est la seule extension que nous avons indiquée pour les SSI), et éditer le pour qu’il ressemble à :

<html>
<body>
 <h1>Gleefully Served By Mac OS X</h1>
 <pre>
  <!--#include virtual="/cgi-bin/test-cgi"-->
 </pre>
</body>
</html>

Ici, nous incluons le script CGI de test dans le contenu de notre page index principale.
Quand vous chargez http://127.0.0.1/index.shtml dans votre navigateur, vous verrez le message “Gleefully Served”, ainsi que les éléments générés par le script CGI.
Nous aurions pu également créer un fichier statique (navigation.html) et l’inclure dans index.shtml.
Remarque : L’utilisation de l’extension .shtml nous oblige à utiliser une URL plus longue–http://127.0.0.1/index.shtml au lieu de simplement http://127.0.0.1/.
Nous verrons pourquoi (et comment le corriger en utilisant DirectoryIndex) dans les articles suivants.

SSI est configuré et fonctionne, mais que pouvez vous faire avec ?
Et si votre département du marketing souhaite créer une galerie d’images des nouvelles publicités à venir ?
Pour une étude plus approfondie de SSI, lisez cet article SSI Image Gallery, également rédigé par votre serviteur.

Quoi d’Autre ?

Dans notre prochain article, je vous indiquerai comment activer PHP et vérifier qu’il fonctionne correctement.
Jusque là, bon courage avec CGI et SSI.

Textes originaux en anglais sur O’Reilly : Apache Web Serving with Jaguar, Part 2 par Kevin Hemenway

opoppon Serveurs Web apache, Mac OS X, réseau, serveur web