Chapitre 26 : Le serveur http

26.1 - Les différents logiciels serveurs

Les serveurs
Tableau comparatif

26.2 - Ecrire les procédures CGI sur le serveur
26.3 - L'option SSI
26.4 - La configuration du serveur

La sécurité
Le renvoi des pages sur un autre serveur http
Les alias
Les messages d'erreur

26.5 - L'option imagemap
26.6 - Les fameux cookies

Introduction
Syntaxe
Remarques
Exemple

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 ...

26.1 - Les différents logiciels serveurs

Les serveurs

En fonction du matériel utilisé, le serveur http sera biensûr différent en terme de nombre d'accès simultanés, en terme de protection et de contrôle.

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.

Nous nous bornerons ici à référencer un certain nombre de serveurs http dont nous donnons les abréviations suivantes pour plus de clarté dans la suite de l'exposé, les adresses des pages Web de ces serveurs sont également référencées dans cette liste. Il est évident que les pages Web de chacun des ces serveurs sont régies par le produit qu'elles présentent, et que ces pages s'évertuent à présenter les points forts de leur serveur. 

• AL : Alibaba de CSM
  [http://www.csm.co.at/csm/]
• AM : Amiga Web Server
  [http://www.phone.net/aws/]
• AP : Apache HTTP du projet Apache
  [http://www.apache.org/]
• AS : Apache HTTP version SSL
  [http://apachessl.c2.org/]
• CB : Commerce Builder
  [http://www.ifact.com/ifact/inet.htm]
• CL : Common Lisp -HTTP de John Mallery
  [http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html]
• CO : Cosmos Web server
  [http://www.ris.fr/]
• DE : OSU DEC threads server
  [http://kcgl1.eng.ohio-state.edu/www/doc/serverinfo.html]
• EM : Emwac Freeware HTTPS
  [http://emwac.ed.ac.uk/html/internet_toolchest/https/contents.htm]
• EN : Enterprise Web
  [http://www.beyond-software.com]
• ES : Esplanade
  [http://www.ftp.com/esplanade]
• EU : Esplanade Secure
  [http://www.ftp.com/esplanade]
• EX : Expresso HTTP server
  [http://www.capitalcity.com:4321/]
• FN : Fnord Server
  [http://www.wpi.edu/~bmorin/fnord/]
• FW : Folk Web
  [http://www.ilar.com/]
• GN : GN de John Franks
  [http://hopf.math.nwu.edu:70/]
• GS : GNN server
  [http://www.tools.gnn.com/]
• GO : GoServe de Mike Cowlishaw
  [http://www2.hursley.ibm.com/goserve/]
• IC : IBM Internet Connextion server
  [http://www.ics.raleigh.ibm.com/]
• IS : IBM Internet Connection Secure Server
  [http://www.ics.raleigh.ibm.com/]
• HC : httpd du CERN
  [http://www.w3.org/hypertext/WWW/Daemon/Status.html]
• HM : httpd4Mac de Bill Melotti
  [http://sodium.ch.man.ac.uk/pages/httpd4Mac/home.html]
• JS : Jazz Server
  [http://www.intranet.co.uk/]
• MI : Microsoft Internet Information Server
  [http://www.microsoft.com/infoserv]
• MQ : MacHTTP de Quarterdeck
  [http://www.quarterdeck.com/]
• NC : httpd de NCSA
  [http://hoohoo.ncsa.uiuc.edu]
• NM : Communications Builder par The Internet Factory
  [http://www.aristosoft.com/ifact/inet.htm]
• NP : NetPublisher de Ameritech Library Services
  [http://netpub.notis.com]
• NR : NetPresenz
  [http://www.share.com/stairways/]
• NS : Netscape Enterprise
  [http://www.netscape.com]
• NT : Netscape FastTrack
  [http://www.netscape.com]
• OP : WebServer d'Open Market
  [http://www.openmarket.com]
• OR : Oracle Web Server
  [http://www.oracle.com]
• OS : Secure WebServer d'Open Market
  [http://www.openmarket.com]
• PV : Purveyor de Process Software
  [http://www.process.com]
• PX : Plexus de Tony Sanders de BSDI
  [http://www.bsdi.com/server/doc/plexus.html]
• QW : Quaterdeck Web Server
  [http://www.quaterdeck.com]
• R6 : Region 6 Threaded HTTP Server de David Jones
  [http://kcgl1.eng.ohio-state.edu/www/doc/serverinfo.html]
• SI : Sioux
  [http://www.thawte.com/products/sioux/]
• SN : Spinnaker
  [http://www.searchlight.com]
• SP : Spinner
  [http://spinner.infovav.se/]
• SR : Spry Web server
  [http://server.spry.com/]
• SS : Spry Satety Web server
  [http://server.spry.com/]
• SU : Sunet httpd
  [http://www-swiss.ai.mit.edu/scsh/contrib/net/sunet.html]
• SW : Super Web Server
  [http://www.frontiertech.com/products/superweb.htm]
• TH : thttpd
  [http://www.acme.com/software/thttpd/]
• TW : Tec Web Server
  [http://www.tecs.com/]
• W4 : Web Server 400 Server
  [http://www.inetmi.com/products/webserv/webinfo.htm]
• WA : Web Share de Rick Troth
  [http://www.beyond-software.com/Software/Webshare.html]
• WB : WB Server
  [http://wwwdev.com/products/vbserver/vbserve.htm]
• WC : Webware Commercial Edition
  [http://www.edime.com.au/webware/]
• WH : Win HTTP de Robert Denny
  [http://www.city.net/win-httpd/]
• WN : WN
  [http://hopf.math.nwu.edu/]
• WS : WebSTAR de StarNine Technologies
  [http://www.starnine.com]
• WT : WebSite de O'Reilly and Associates
  [http://website.ora.com]
• ZS : Zeus Serveur
  [http://www.zeus.co.uk/]

Tableau comparatif

Ces tableaux référencent les serveurs par le choix de fonctionnalités suivant : 

• OS : désigne les systèmes d'exploitation sur les-quels fonctionnent les serveurs 
• Access-lists : identifie les serveurs qui protègent leurs pages par Access-listes
• Distribution : identifie le mode de distribution du serveur (freeware, commercial)
• SSL : identifie le niveau de sécurité du serveur pour les transacations commerciales 
• Interdiction domaine : identifie si le serveur est capable de restreindre l'accès aux utilisateurs d'un domaine 
• Interdiction IP : identifie si le serveur est capable de restreindre l'accès à certaines adresses IP 
• Couplage Base données : identifie si le serveur est dotée d'API de couplage avec une base de données sans utilisation de CGI. 
• Mot de passe : identifie si le serveur peut protéger certaines pages par un mot de passe 

• CO : Commercial 
• Fr : Freeware 
• Sh : Shareware/ période d'essai 
• 95 : Windows 95 
• MVS : Système d'exploitation des hosts IBM 
• VMS : Système d'exploitation Digital Equipment 
• NT : Windows NT serveur 
• 3.11 : Windows 3.11 
• Mac : MacOs d'Apple 
• U : Unix 
• NW : Netware 
• AC : supporte les access lists ou un mécanisme équivalent

26.2 - Ecrire les procédures CGI sur le serveur

Ecrire des procédures CGI demande de connaître la programmation, cette activité est plutôt réservée à un public averti.

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 

L'introduction du premier explique comment créer une première procédure CGI simple.

26.3 - L'option SSI

Les procédures SSI (Server-Side Includes) servent à afficher des informations dynamiques aux clients. Par exemple, vous pouvez envoyer le nombre de clients qui ont visité la page.

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 un programmation souple et rapide comme le montre le chapitre sur les SSI.

26.4 - La configuration du serveur

La sécurité

La sécurité d'un serveur http consiste à limiter l'accès du serveur à des clients suivant des critères tels que : 

• 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. 

Les façons de faire changent d'un serveur à l'autre mais généralement on retrouve des similitudes dans les méthodes de déclaration.

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

Il se peut que vous décidiez de changer votre page HTML de serveur http. Or ceci peut poser un problème si votre page est déclarée dans un grand nombre de sites; il est, en effet, impossible de connaître avec précision la liste des pages vous référençant.

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

Imaginez que votre home page s'apelle http://www.imaginet.fr/~gmaire/toc.htm et que cela ne vous parait pas très facile à retenir pour vos lecteurs. Vous pouvez demander à votre gestionnaire de site de changer cette adresse pour un alias plus convivial, par exemple http://www.imaginet.fr/ime.

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

Les messages d'erreur sont normalisés sur les serveurs http dans la mesure où ils sont numér

Regardons ces messages d'erreur : 

26.5 - L'option imagemap

L'option Imagemap permet lorsqu'une image cliquable est utilisée, de déterminer les actions à effectuer selon la région désignée.

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=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

26.6 - Les fameux cookies

Introduction

Deux connexions consécutives depuis un même client sont indépendantes au vu du protocole HTTP, c'est à dire qu'elles sont vues comme deux connexions totalement indépendantes, ceci n'est pas pratique, puisque le programme CGI sur le serveur, ne peut pas garder le contexte notamment dans le cadre d'applications plus complexes que la simple consultation de base de données. Notons qu'il existe plusieurs moyens classiques de contourner le problème : 

• 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.

Le serveur HTTP envoi les cookies dans l'entête HTTP au client. Ces cookies contiennent les différents descriptifs accompagnant les URL visitées, ces cookies sont conservées sur votre disque dur en vue d'être exploité lors d'une prochaine connexion.

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

Les cookies sont stockés sur le client dans un fichier cookies.txt, ces cookies peuvent être utilisés par un CGI, ou par JavaScript en utilisant l'une des propriétés de l'objet document.

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

Lorsque le cookie est envoyé par le serveur, le navigateur consulte sa liste des cookies et compare la liste des domaines et celle du domaine de l'URL consulté.

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

Un navigateur envoi une requête à un serveur HTTP et reçoit dans l'entête HTTP du document la réponse 

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

Ce cookie est sauvé sur le fichier cookie.txt et lorsque le client fait une requête sur le même serveur avec le chemin / il envoie au serveur le message suivant :

Cookie: VISITEUR=gilles

Puis il peut recevoir un autre cookie de ce serveur par exemple : 

Set-Cookie: CATEGORIE=Prospect; path=/

A ce moment l'information cookie relative à l'URL devient 

Cookie: VISITEUR=gilles; CATEGORIE=Prospect

Puis dans la même URL, si toujours avec le même navigateur, je décide d'acheter un produit le cookie suivant peut m'être envoyé : 

Set-Cookie: CATEGORIE=Client; path=/

Ainsi le navigateur est identifié par le fichier cookie avec l'information suivante :

Cookie: VISITEUR=gilles; CATEGORIE=Client