Chapitre 33 : Le serveur http

Dans le chapitre Ecrire sa page Web, nous avons vu comment écrire les pages html , avec la gestion des graphiques, des tableaux, et des procédures CGI.

Ce chapitre explicite comment installer cette page sur un serveur pour que tous puissent y accéder. Le serveur sera capable d'envoyer simultanément plusieurs pages html à plusieurs clients, il sera capable de prendre en compte les appels aux procédures CGI, il sera capable encore de filtrer les connectés et de tracer dans un fichier l'ensemble des connexions. Ces différentes options dépendront du matériel utilisé et du logiciel serveur que vous choisirez.

Il est bien évident qu'un serveur fonctionnant sur un Macintosh ou sous Windows sera moins puissant que son homologue s'exécutant sur un système Unix. Mais il est parfois intéressant de pouvoir faire fonctionner un serveur http sur un ordinateur personnel pour tester l'enchaînement de ses pages, les procédures CGI etc ...
 
 

33.1 - Les différents logiciels serveurs

Les serveurs

Vous trouverez un article en anglais sur la page de Webcompare [http://webcompare.iworld.com] qui vous donnera les dernières informations au sujet des différents serveurs, freeware, shareware ou commerciaux.

La page de Yahoo
[http://www.yahoo.com/Computers_and_Internet/Internet/World_Wide_Web/HTTP/Servers/]
concernant les serveurs http renvoit ici encore sur les meilleures ressources sur le sujet.

Si dans les précédentes versions d'UNGI nous donnions une liste des serveurs qui commençait à dater, nous nous bornerons maintenant à étudier les quelques serveurs les plus utilisés, c'est à dire les plus performants, en approfondissant leur fonctionnement.

Les serveurs étudiés ici sont donc

• Apache
• Microsoft Internet Information Server
• Netscape Enterprise Server
• Netscape FastTrack
• OmniHTTP
• Oracle Web Serveur
• Sioux
• WebSite de O'Reilly and Associates

Apache

Sur Windows NT Apache fonctionne comme un véritable service ou comme une application, et est compatible avec les ISAPI de Microsoft.
Apache fut le premier des serveur à offrir un module PERL monté en mémoire et permettant l'exécution de CGI PERL à haute vitesse.

Notons aussi que les fichiers de log sont tout à fait standards et peuvent être utilisés par tous les logiciels d'analyse et d'édition.
Les CGI peuvent avoir leur propre fichier de log, ce qui est indispensable puisque cette option permet de tester les problèmes de vos programmes.

Apache supporte les SSI, les inclusions de code HTML, le protocole HTTP/1.1, les mots de passe sur des pages, et enfin les SSL 2 et 3 sont supportées.

Sur le Web d'Apache, une rubrique intéressante doit être visitée, celle des projets autour d'Apache dans laquelle on  trouve :

•  un ensemble de modules PERL pour Apache
• le supports des SSL
• des protages sur Amiga, Macintosh, OS/2
• une intégration Apache Java
• un ajout d'interface graphique
• un langage de script interne aux pages HTML (PHP/FI) Notons que ce langage permet la manipulation de requêtes SQL

Microsoft Information Server

Les  points forts du serveur de Microsoft résident dans son ergonomie, puisque le serveur est administrable par un assistant graphique et également par le Web. Dans les versions actuelles, la gestion des logs est tout à fait identique à celle des autres serveurs. ( HTTP 1.1, SSL2, SSL3)

L'originalité du serveur IIS réside également dans son langage de scripting Active Server Page (que l'on reconnaît par l'extension des pages en asp). Par contre, ce langage propriétaire interdit tout portage sur un serveur autre que celui de la marque. Ainsi la prudence sera de mise pour les utilisateurs de serveurs Microsoft Information Serveur en Intranet qui pourraient être amenés à mettre leurs pages sur Internet, via un hébergeur  qui ne posséderaient pas ce type de serveur.

A noter le support des agents SNMP permettant notamment l'administration par les outils d'administration.

En outre, IIS est livré avec Microsoft Index Server qui est un moteur de recherche interne permettant d'indexer et de retrouver par mots clé les pages archivés sur le serveur. IIS est également étroitement couplé avec Front Page  et SiteServer Express les outils de développement de Microsoft.
 

Netscape Interprise Server et Commerce Server

Le serveur Netscape possède ses API, appelées NSAPI,  qui sont bien sûr différentes de celles proposées par Microsoft sous le nom de ISAPI. Aujourd'hui les produits périfériques des serveurs http, comme les connexions base de données sont généralement ISAPI et NSAPI mais une étude statistique prouve que ISAPI est davantage suivi que NSAPI. Les dernières versions de Netscape comprennent une interface JAVA Applet API qui permet au serveur de lancer des programmes JAVA de façon plus rapide, en gardant en mémoire l'interpréteur JAVA.

Les interfaces de maintenance par le Web ou par des programmes spécifiques sont d'aussi bonne facture que celles proposées par Microsoft. Ainsi la version 3 de Netscape Inrterprise serveur équivaut à la version 4 d'Internet Information serveur.

Il est à noter un compilateur JavaScript sur le serveur permettant de générer de façon dynamique les codes HTML.

Netscape a rejoint quelques technologies intéressantes telles que LDAP et CORBA.

Enfin Netscape Interprise Server se décline en produits de bureautique avec une version  personnelle de développement FastTrack  fournie avec une version de communicator accompagnée de son éditeur HTML.

OmniHTTP

33.2 - Ecrire les procédures CGI sur le serveur

Le développement peut être en C, en Pascal, en Basic ou en tout autre langage informatique.

Il existe cependant un langage très riche et très adapté à la manipulation des fichiers, c'est le langage PERL.

Le langage PERL regroupe la puissance des langages C, Shell Script, awk, sed et grep. Ceci ne dira rien aux néophytes mais pour les connaisseurs du système UNIX, cela évoque les langages les plus puissants et les plus astucieux.

Le langage PERL fait l'objet de deux chapitres du présent guide :

• Introduction au langage PERL
• Exercices en PERL

33.3 - L'option SSI

Cette option n'est pas présente sur tous les serveurs notamment les serveurs freeware.

Ceci peut se vérifier aisément par le programme suivant inclus dans votre page html :

La date est :

<!--exec cmd='date' -->

Si votre serveur httpd accepte les SSI vous pouvez vous engager vers une programmation souple et rapide comme le montre le chapitre sur les SSI.

33.4 - La configuration du serveur

La sécurité

• Des limitations sur les répertoires et sur les fichiers.
• Des protections sur les fichiers par un mot de passe.
• Les ACL (Access Control List) qui contiennent des informations sur les personnes, les groupes et les adresses IP qui ont le droit d'accès à des fichiers ou des répertoires.
• Les fichiers password, qui contiennent les mots de passe et les noms des utilisateurs qui ont accès au serveur.
• Les fichiers de groupe, qui contiennent des groupes d'utilisateurs qui ont le droit d'accès au serveur.

Certains serveurs ne disposent pas d'option de contrôle d'accès. Il faut donc se référer au cas par cas à la documentation des serveurs http.

Le renvoi des pages sur un autre serveur http

 La solution est prévue sur la plupart des serveurs http. Par exemple, sur le serveur NCSA, ceci se fait dans le fichier de configuration srm.conf à la rubrique redirection, en mettant le nouvel URL, comme le montre l'exemple suivant :

# ========================
# Aliasing and Redirection
# ========================
#
# Redirect allows you to tell clients about documents which used to exist in
# your server's namespace, but do not anymore. This allows you to tell the
# clients where to look for the relocated document.
#
# Format: Redirect fakename url
#

Les alias

 Ceci se fait dans le fichier de configuration srm.conf, dans la rubrique Aliasing. comme le montre la séquence suivante :

# Aliases: Add here as many aliases as you need, up to 20. One useful
# alias to have is one for the path to the icons used for the server-
# generated directory indexes. The paths given below in the AddIcon
# statements are relative.
#
# Format: Alias fakename realname
#
Alias /ime/ /~gmaire/manuel.htm

Les messages d'erreur

 Regardons ces messages d'erreur :

33.5 - L'option imagemap

Généralement l'option est contenue dans le fichier imagemap.conf sur le serveur http avec l'ensemble des fichiers de configuration. Ce fichier contient des lignes de la forme :

 carte : /directory/.../.../carte.map .

Ceci sera appelé dans la page html par la séquence :

 <A href="/imagemap/carte">
<img src=gif/arte.gif ismap>
</A>
Où carte représente un fichier image à cliquer. On peut avoir autant de lignes que de cartes à cliquer. Pour chaque carte on retrouvera dans le fichier carte.map correspondant, un ensemble de lignes du genre :

 #par defaut on appelle le programme prog1 (il y a bien un espace entre defaut et /demo)
default /demo/prog1.htm
#Les cercles sont définis par le centre et par le rayon, on appellera alors prog2 :
circle /demo/prog2.htm 50,50 50,10
# Les rectangles sont définis par les coins opposés :
rect /demo/prog3.htm 130,10 170,90
# Les polynômes sont définis par un ensemble de points
poly /demo/prog4.htm 250,10 210,90 290,90

 Ainsi un menu comprenant une carte sera défini avec plusieurs rectangles :

default /ismap/cit/no_image.html
rect /ismap/prog1.html 382,262 390,271
rect /ismap/prog2.html 373,394 383,406
rect /ismap/prog3.html 472,324 483,336

Pour trouver les coordonnées des rectangles ou des polynômes, il suffit de promener la souris sur la carte dans un bon lecteur de Web. Vous verrez le champ adresse de l'URL donner les informations sous la forme /cgi/procedure?x,y et il vous suffira alors de noter ces valeurs.

 Ceci peut se voir par exemple sur la carte de France france.htm bien que la procédure appelée soit un programme Perl et non pas un imagemap

33.6 - Les fameux cookies

Introduction

• utiliser des champs caché (HIDDEN) dans les formulaires (FORM), mais ceci est lourd à gérer à  moins de disposer d'un méta  langage comme celui mis en oeuvre pour le développement d'UNGI Hotline par exemple;
• utiliser un fichier sur le serveur mémorisant les états, mais ces fichiers ne peuvent pas être conservés indéfiniment, et en cas de reconnexion utlérieure par un accès bookmark, il est impossible d'honorer la requête;
• utiliser les cookies dont nous allons parler maintenant et qui ont fait couler beaucoup d'encre pour la raison que nous verrons.

Sur votre équipement, vous pouvez consulter le fichier cookie dans le dossier Netscape, program; il se trouve dans le fichier cookies.txt et il est lisible par un éditeur de texte. Ceci est une première chose à savoir, car il devient facile d'analyser quelles sont les URL que vous visitez (si ces URL contiennent des Cookies et que votre navigateur est activé pour les recevoir).
 
 

Regardons la structure du fichier cookie par l'analyse d'une ligne du  fichier cookie :
 
 

.scarabee.com TRUE / FALSE 942195540 LANG_scarabee

Nous savons déjà que le navigateur a interrogé une adresse contenant  .scarabee.com, probablement www.scarabee.com et la suite nous montrera les informations qui seront conservées au sujet de ce site par le navigateur.

Syntaxe

Un programme CGI utilise les cookies en ajoutant des informations dans l'entete HTTP sous la syntaxe suivante :

Set-Cookie: NOM=valeur [;EXPIRES=date] [;DOMAIN=nom_de_domaine][;PATH=chemin][;SECURE]
 
 

Les différents paramètres sont utilisés comme suit :

• NOM=valeur  ne doit pas contenir de ; de , et de caractère blanc, cette valeur est une URL éventuellement accompagnées d'arguments sous la forme %XX. NOM est donc une variable et valeur sa valeur. Exemple valide : STATUS=CLIENT
• EXPIRES=date date de validité du cookie. Après cette date d'expiration le cookie ne sera plus stocké sur le fichier cookie navigateur. Si aucune date n'est donnée, le cookie expire à la fin de la session. Le format de la date est jds, jj-mm-aa HH:MM:SS GMT jds est le jour de la semaine, jj est le jour du mois sur deux numériques, mm est le mois de l'année sur deux numériques, aa est l'année sur deux caractères.
• DOMAIN=nom_de_domaine donne le domaine d'un cookie. Sans valeur c'est le nom du serveur qui est utilisé.
• PATH=chemin définit le chemin d'un cookie. Sans valeur, le navigateur utilise le chemin du document qui a créé les cookies.
• SECURE définit si le cookie est transmis de façon sécurisée au serveur.

Remarques

La correspondance est faite uniquement sur la fin de l'URL, c'est à dire en comprenant l'extension de domaine (.com, .fr, .edu) et le nom précédent. Ainsi www.imaginet.fr sera sauvegardé avec l'identifiant DOMAIN imaginet.fr, mais le cookie du site www.imaginet.digipresse.fr sera enregistré avec l'identifiant DOMAIN digipresse.fr, alors que www.mail.imaginet.fr sera enregistré avec l'identifiant DOMAIN imaginet.fr.

La variable PATH quant à elle spécifie le chemin valide pour le cookie. Pour PATH=/ime avec DOMAIN=imaginet.fr,

l'enregistrement du COOKIE se fera pour /ime mais aussi pour /imediat ou pour /ime/toc.htm
 
 

Ainsi, lors de la consultation d'une URL correspondant au nom de domaine et au chemin, le navigateur, va envoyer la liste des variables sauvegardées sur votre disque dur.
 
 

Pour détruite un cookie, depuis le serveur, il suffit d'envoyer une variable avec une date d'expiration déjà expirée.
 
 

Les navigateurs peuvent sauver aujourd'hui 300 cookies, sachant que chacun d'eux peut contenir 4 Ko d'information. Il existe une limite de 20 cookies par domaine. Si ces limites sont atteintes, le navigateur détruit les  cookies avec la date d'expiration les plus récentes.
 
 

Exemple

Set-Cookie: VISITEUR=gilles ; path=/; expires=Wednesday,    09-Nov-99 23:12:40 GMT

Cookie: VISITEUR=gilles

Set-Cookie: CATEGORIE=Prospect; path=/

Cookie: VISITEUR=gilles; CATEGORIE=Prospect

Set-Cookie: CATEGORIE=Client; path=/