De mieux en mieux : site.simple

Nous pouvons maintenant commencer à créer des sites web réalistes. Pour commencer progressivement, notre site sera celui d’un petit commerce en ligne, Butterthlies, Inc., qui crée et vend des cartes postales. Nous devons lui attribuer quelques adresses web mais, comme nous ne comptons pas encore nous ouvrir sur le monde extérieur, elles appartiendront à notre propre réseau : de cette façon, toutes les machines de ce réseau sauront qu’elles n’ont pas besoin de sortir sur le Web pour prendre contact avec nous. Nous avons donc modifié le fichier \windows\hosts de la machine Windows 95 sur laquelle s’exécute le navigateur, ainsi que le fichier /etc/hosts de la machine Unix sur laquelle tourne le serveur pour qu’ils contiennent les lignes suivantes :

127.0.0.1 localhost

192.168.123.2 www.butterthlies.com

192.168.123.2 sales.butterthlies.com

192.168.123.3 sales-IP.butterthlies.com

192.168.124.1 www.faraway.com

La ligne concernant localhost est obligatoire, nous l’avons donc laissée, mais n’envoyez pas de requêtes au serveur sur cette adresse car les résultats pourraient être assez troublants.

Vous devrez sûrement consulter votre administrateur réseau pour qu’il effectue des modifications similaires.

En fait, site.simple est site.toddle auquel on a apporté quelques modifications mineures. Pour commencer, entrez les commandes suivantes, selon votre système d’exploitation :

% test -d logs || mkdir logs

% httpd -d `pwd` -f `pwd` /conf/httpd.conf

Ouvrez une fenêtre DOS et, à partir de la ligne de commande, faites :

c> cd \program files\apache group\apache

c> apache -k start

c>Apache/1.3.26 (Win32) running ...

Pour arrêter Apache, vous devrez ouvrir une deuxième fenêtre DOS et faire :

c> apache -k stop

c> cd logs

c> edit error.log

Comme ces manipulations seront identiques pour tous nos sites d’exemple, nous ne les mentionnerons plus.

À partir de maintenant, il n’y aura que très peu de différences entre les configurations du serveur pour Windows et pour Unix. Sauf si le contraire est explicitement mentionné, supposez que nos explications s’appliquent aux deux versions.

Il est appréciable d’avoir un journal de ce que l’on fait. Dans la première édition de ce livre, nous avions remarqué qu’un fichier access_log était automatiquement créé dans ...site.simple/logs mais, curieusement, l’Apache Group a brisé la compatibilité ascendante et il faut désormais indiquer explicitement l’emplacement du fichier journal à l’aide de la directive TransferLog dans le fichier de configuration.

Le fichier .conf/httpd.conf contient donc désormais :

User webuser

Group webgroup

ServerName www.butterthlies.com

DocumentRoot /usr/www/APACHE3/APACHE3/site.simple/htdocs

TransferLog logs/access_log

Dans .htdocs, nous avons toujours 1.txt, qui contient cette fois-ci :

Re-bonjour à tout le monde depuis site.simple !

Vous vous rappelez de notre script go du chapitre précédent ? Lancez-le, puis allez dans un navigateur client et faites-le pointer vers http://www.butterthlies.com. Vous devriez voir :

Index of /

. Parent Directory

. 1.txt

Cliquez sur 1.txt pour voir apparaître, comme précédemment, un message très inspiré.

Tout cela semble très satisfaisant, mais il reste un mystère à élucider : nous obtenons les mêmes résultats si nous nous connectons à http://sales.butterthlies.com. Nous n’avons mentionné ni ces URL, ni les adresses IP de ces sites dans le fichier de configuration de site.simple, pourquoi obtient-on quand même une réponse ?

La clé de l’énigme vient du fait que, lorsque nous avons configuré la machine du serveur, nous avons demandé à l’interface réseau de répondre à n’importe laquelle de ces adresses :

192.168.123.2

192.168.123.3

Par défaut, Apache écoute sur toutes les adresses de la machine et répond de la même façon à chacune d’entre elles. Si vous avez configuré des hôtes virtuels (ce qui n’est pas le cas ici), Apache les parcourt à la recherche d’une adresse correspondant à celle de la connexion entrante ; il utilise alors la configuration de l’hôte virtuel s’il en trouve un qui convient, ou la configuration principale dans le cas contraire. Nous verrons plus loin comment contrôler plus précisément tout cela à l’aide des directives BindAddress, Listen et <VirtualHost>.

Il faut souligner que ce fonctionnement (ce passage rapide entre des configurations différentes) semble mettre Nestcape et Internet Explorer dans un beau pétrin. Lorsque vous utilisez Netscape comme navigateur, vous pouvez vérifier que le serveur fonctionne correctement en appuyant sur la touche Ctrl pendant que vous demandez à recharger le fichier que vous examiniez. Dans les cas extrêmes, il peut être nécessaire de désactiver la mise en cache en allant dans Édition ® Préférences ® Avancé ® Cache. Fixez les caches mémoire et disque à 0 et cochez l’option « Chaque fois que je visualise la page » de la comparaison de la page du cache à celle du réseau. Avec Internet Explorer, cochez « À chaque visite de la page ». Si vous ne le faites pas, le navigateur a tendance à afficher un mélange de plusieurs réponses du serveur car on fait ce qu’un utilisateur ou un administrateur ne font généralement jamais : basculer entre différentes versions d’un même site avec différentes versions d’un même fichier. À chaque fois que l’on passe d’une version récente à une plus ancienne, Netscape pense que sa version en cache est à jour.

Revenons au serveur : arrêtez Apache par un Ctrl-C et examinez les fichiers logs. Dans le fichier .logs/access_log, vous devriez voir une ligne comme celle-ci :

192.168.123.1--- [<date et heure>] "GET / HTTP/1.1" 200 177

200 est le code de réponse qui signifie que tout s’est bien passé pour cette requête et 177 est le nombre d’octets transférés. Il ne devrait rien y avoir dans ... /logs/error_log car il n’y a pas eu de problème : il est cependant conseillé d’y jeter un coup d’œil de temps en temps en utilisant les dates et les heures enregistrées pour circonscrire un problème éventuel.

Les choses étant ce qu’elles sont, des problèmes peuvent survenir, ou un client peut demander quelque chose que le serveur est incapable de fournir : il est donc conseillé de permettre la gestion de ces événements en utilisant la directive ErrorDocument.

ErrorDocument

La directive ErrorDocument permet d’indiquer ce qui doit se passer lorsqu’un client demande un document inexistant.

ErrorDocument code-erreur "document" (avec Apache 2)

Configuration du serveur, hôte virtuel, répertoire, .htaccess

Il y a quatre façons de réagir aux problèmes ou aux erreurs :

1. Produire un unique message d’erreur, fixé une fois pour toutes.
2. Produire un message personnalisé.
3. Rediriger le client vers une URL locale, qui prendra en charge le problème ou l’erreur.
4. Rediriger le client vers une URL externe, qui prendra en charge le problème ou l’erreur.

Par défaut, Apache utilisera la première option ; les autres doivent être configurées via la directive ErrorDocument suivie d’un code de réponse HTTP et d’un message ou d’une URL. Dans ce contexte, le message doit être placé entre des apostrophes doubles ( " ), qui ne font pas partie du message lui-même. Apache fournira parfois des informations supplémentaires concernant le problème ou l’erreur.

Les URL peuvent être des URL locales qui commencent par une barre de fraction ( / ), ou des URL complètes pouvant être résolues par le client. Par exemple :

ErrorDocument 500 http://truc.exemple.com/cgi-bin/tester

ErrorDocument 404 /cgi-bin/mauvaises_urls.pl

ErrorDocument 401 /infos_abonnement.html

ErrorDocument 403 "Désolé : vous n’avez pas le droit d’accès à cette ressource"

Lorsqu’un ErrorDocument pointe vers une URL distante (c’est-à-dire, une URL commençant par une méthode comme « http »), Apache redirigera le client vers le document indiqué, même s’il est sur le même serveur. Ce comportement a plusieurs conséquences, la plus importante étant qu’une directive ErrorDocument 401 doit désigner un document local : cela provient de la nature même du schéma d’authentification HTTP de base.