le plus petit. Dans les courriers
electroniques, vous savez tous qu'écrire en majuscules équivaut à
CRIER. Html est plus nuancé: nous avons les tags emphasis et
strong qui mettent en valeur plus ou moins fortement
leur contenu. Dans les environnements graphiques, le texte est affiché
avec une police à espacement proportionnel, et c'est parfois inadapté.
le tag télétype force le butineur à utiliser une police à
largeur fixe. Enfin, pour terminer par quelque chose de simple, le tag
, celui qui n'est pas englobant, trace une ligne horizontale qui
traverse l'écran, on appelle ça une 'horizontal rule'. Maintenant, on
se calme, c'est fini.
c) Les Hyper-liens: Voyons maintenant ce qui fait la force du
ouèbe: le GOTO ! Certaines parties de votre page (texte et/ou image)
peuvent être rendues réactives. C'est à dire qu'une action sur cette
partie de la page (eg: un bon cliquettement de souris) va demander au
butineur de charger une nouvelle page. Cette page est désignée par son
URL ou Uniform Ressource Locator. En gros, c'est son emplacement dans
l'Internet. Le tag utilisé pour les hyper-liens est un tag englobant.
Il a cette forme: LIEN. Par exemple, si nous désirons
rajouter un lien à notre première page, nous pouvons remplacer la
ligne numéro 6 par ceci:
J'aime beaucoup Pamela
A partir de maintenant, quand cette page s'affichera dans votre
butineur, le mot Pamela sera mis en valeur (non, on n'a aucun moyen de
supprimer le soulignement des liens ;-) d'une façon quelconque. Il est
devenu réactif. Donc, activons-le. Notre butineur va décoder le HREF:
il trouve qu'il doit demander le document 'ouba.html' au serveur
'pam.ander.son', en utilisant le protocole 'http'. Il va donc le
faire, et dans ce nouveau document il va y avoir d'autres liens et
ainsi de suite.
3) Le protocole HTTP
HTTP est l'acronyme de "HyperText Transfer Protocol".
Actuellement dans sa version 1.0 mais la 1.1 est en bonne voie. Si
j'ai le temps, je vais y jeter un coup d'oeil pour vous en parler, car
elle apporte des avantages incontestables.
Ce protocole régit les communications entre le serveur ouèbe et
le client butineur. Il serait en théorie indépendant de la 'couche
transport', mais en pratique, on ne le trouve que sur TCP/IP. Bien
qu'à une époque, certains hackers furieux de chez Novell aient
implémenté HTTP sur SPX/IPX, l'équivalent Novell de TCP/IP. C'était au
temps de l'UnixWare (ex AT&T, ex USL, now SCO). Comme quoi, tout peut
arriver.
La première chose à savoir sur HTTP, et surement la plus
surprenante pour les habitués des mainframes et/ou du videotext, c'est
que HTTP est un protocole "state-less" ou "sans état". D'une requète à
l'autre, ni le client ni le serveur ne mémorisent d'informations sur
la ou les requètes passées. Pour la simple consultation de Pamela
Anderson, ce n'est pas sâle. Par contre, nous verrons plus tard tous
les problèmes que cela pose pour les applications interactives
(interactive, Pamela :-). Bien entendu, un certain nombre de
'truandes' et/ou d'améliorations permettent de corriger cette
déficience.
Pour voir le déroulement des opérations, c'est très simple:
puisque HTTP est posé sur TCP et utilise l'Ascii, un petit coup de
telnet et vous allez comprendre. DEMO. Vous voyez, il n'y a rien de
compliqué ?
$ telnet machin.ici 80 commande unix
Trying 193.30.30.30 ... telnet ...
Connected to machin.ici ... nous ...
escape char is '^]' ... parle
GET /foobar.html HTTP/1.0 nous tapons la requete,
puis une ligne vide.
et la, maintenant, le serveur nous
envoie le document...
Quand c'est fini, la connexion est coupée.
$
Une requète complète est constituée d'une ou plusieurs lignes de
texte en ascii NVT, c.a.d. théoriquement terminées par la séquence
CR/LF. La fin de la requète est marquée par une ligne vide. La
première ligne d'une requète est décomposable en trois champs séparés
par un espace. Le 1er champ est un mot-clef, le second est la
référence du document et le troisième champ indique le protocole
utilisé et son numéro de version. Les différents mot-clefs du
protocole http 1.0 sont:
GET obtenir un document (infos et contenu)
HEAD obtenir des infos sur un document
POST envoyer des données au serveur
PUT envoyer un document au serveur
DELETE effacer un document du serveur
TRACE demande des renseignements aux proxies
OPTIONS pour negocier les options.
En première approche, HEAD, GET et POST sont les trois requètes
les plus utiles. GET demande la page. HEAD permet d'obtenir quelques
informations sur une page, sans avoir à la charger en entier. POST
permet d'envoyer des informations de taille quelconque (et surtout
importante) vers un serveur: contenu d'un formulaire comprenant de
nombreux champs, par exemple. PUT permet d'envoyer un fichier dans le
serveur et DELETE permet de boire le café. Quand aux deux dernières,
je ne sais pas vraiment à quoi ça sert ...
4) Les serveurs
Bon, là, je suis un peu embèté car je n'ai pas grand chose à
dire. Dans ma carrière de ouèbeur, j'ai utilisé essentiellement trois
serveurs, deux sous Unix et un sous Windows 3.11, ne riez pas, il y a
aussi de très bons softs pour Fenètres de MiniDoux !
A l'heure actuelle, si vous devez apprendre un serveur, je vous
conseille de choisir Apache. Si plus de 45% des serveurs ouèbes du
monde sont des Apaches, il y a peut-etre une raison. Par contre, si la
malchance vous a collé a Windaube95, je pense ne pas me tromper en
vous suggérant Website de O'Reilly. Et si vous êtes en 'never
terminated', patientez encore quelques semaines, vous allez bientôt
avoir un Apache aussi !
5) Les Nano-serveurs
Le nano-serveur est une "invention" que j'ai faite il y a déja
deux ans, alors que je travaillais dans une boite de gestion, sur le
système UnixWare. Je ne pense pas être le seul à avoir découvert ce
concept, mais le terme nano-serveur me plait beaucoup, et j'en
revendique la paternité.
Le principe est simple: il consiste à utiliser le protocole HTPP
de façon classique. Par contre le nano-serveur n'utilise pas la partie
'path' de l'URL pour chercher des fichiers, mais comme des arguments,
un peu à la façon d'argv[]. Après décodage de cette 'ligne de
commande', il peut executer l'action spécifique pour laquelle il a été
écrit. On a donc des périphériques d'affichage performants et offerts
gracieusement par MickeySoft pour faire plein de choses avec nos
Linucses. Il suffit de respecter le protocole HTTP, et la partie qui
nous interesse n'est pas énorme, et d'écrire du HTML pour piloter
l'affichage.
Autre possibilité, plus subversive, de l'architecture nano-
serveur: espionner les butineurs. Nous avons vu un peu plus haut
qu'une requète HTTP était constitué de lignes de texte et terminée par
une ligne vide. D'habitude, personne, en dehors de l'indien, ne voie
ces lignes. Un nano-serveur spécialisé peut, par contre, les stocker
et vous les resservir gentiment enrobées dans du HTML. Je l'ai déja
fait, c'est très instructif. Et je considèrerais oeuvre de salubrité
publique l'installation de ce type de nano-serveur sur la machine
Excalibur. Signature de la pétition à la sortie.
6) Les butineurs
En avant, voici le sujet le plus sensible de la conférence. Qui
n'a pas vu ces fantastiques 'flame-wars' dans les newsgroups ? "mon
Netscape est mieux que ton Arena", "Vous n'y comprenez rien, le
meilleur c'est MSIE 11.01 sur Windaube eNTi", "Moi, je dis qu'il n'y a
que Lynx de valable, le reste c'est que des trucs de gonzesse", etc...
etc... Pour ajouter au débat, sachez que je suis en train d'essayer de
faire marcher Net-Tamer (e-mail, news, www, ftp, telnet, ping,
daytime, etc...) sur mon pécé 286. Ce soft n'est pas encore au point,
mais l'auteur semble très motivé. Affaire à suivre.
Un butineur (browser pour les non-québécois) est la partie
'cliente' du ouèbe. Sa première fonction est d'aller chercher par HTTP
une page à partir de son URL, d'extraire de cette page les hyper-liens
et d'afficher le tout sur votre écran/synthétiseur de parole/tablette
Braille. Il doit également vous permettre de 'pointer' un des liens de
la page courante afin de prélever la page désignée. goto début. Le
reste n'est que de l'enrobage.
7) Les scripts CGI
CGI est l'acronyme de "Common Gateway Interface", que l'on peut
traduire approximativement par "Interface de Porte Commune". C'est pas
très beau, et puis ça donne IPC, qui est l'acronyme de "Inter Process
Communication", ce qui peut prèter à confusion, quoique...
Cette interface, dans sa forme actuelle, a été mise au point par
le NCSA, National Center for Supercomputing Application, (plus connu
comme étant le créateur de Mosaic, ancètre commun de Netscape et
MSIE). Elle est actuellement standardisée sour la forme du rfcXXXX.
Le but de cette interface est de définir la communication entre
le serveur httpd et un programme externe afin que le serveur fasse
'relais' dans les deux sens entre un butineur/client et ce programme,
exécuté sous le controle du serveur.
Lequel programme devant pouvoir être écrit dans n'importe quel
langage à peu près civilisé. Dans les systèmes Unix (et dérivés) cela
signifie trois choses: entrée et sortie standard, accès aux variables
d'environnement. Pour une classe un peu particulière de CGI (ceux qui
gèrent les cf. mon article dans le numéro 3 de go@elfix) il
faut aussi avoir accès à la ligne de commande (argc, argv).
Commençons par un exemple très simple: l'affichage des variables
d'environnement sans aucune mise en forme. Il y a des numéros de
lignes car c'est un CGI vraiment très basique.
1 #!/bin/sh
2 echo "Content-type: text/plain"
3 echo
4 printenv
La ligne 1 indique au système l'interpreteur à utiliser. La ligne
2 envoie un type MIME, qui servira au butineur pour selectionner la
façon d'afficher ce qu'il va recevoir. Cette ligne fait partie de
l'en-tète de la réponse HTTP. La ligne 3 est vide et signale la fin de
l'en-tete. Le butineur sait donc qu'il va recevoir du texte à afficher
tel quel (plain). Et finalement, la ligne 4 affiche toute les
variables. Cela semble rien du tout, mais vous venez de découvrir la
puissance du tandem ouèbe/CGI. Exercice: essayer de trouver toutes les
commandes Unix qui pourraient prendre la place de printenv. Il y en a
beaucoup [ps|who|free|netstat]. Combiné avec une page qui liste tous
ces petits CGI, vous avez de quoi surveiller votre machine dans un
confort quasi Billgateux.
8) Les CGI vu du coté administration.
Mettre un CGI dans une page ouèbe, si vous ètes relié à
l'Internet, c'est laissez à 100 millions de personnes la possibilité
d'executer un programme dans _votre_ machine. Tous le monde n'est pas
net dans l'Internet. Et même si vous êtes dans un contexte fermé, une
bêtise est toujours possible. Il faut donc prendre des précautions.
En général, on fait tourner le logiciel serveur avec un couple
UID/GID muni du minimum de privilèges nécessaires. Ce qui implique que
les processus enfants du serveur, donc vos scripts CGI, utiliseront
aussi cette identité. Un script qui fonctionne correctement depuis le
prompt, donc avec votre uid/gid habituel, ne marchera pas forcément
quand il sera exécuté depuis le serveur ouebe.
10) Les visualiseurs externes.
Nous avons vu qu'à chacun des types de données stockées dans ou
produite par un serveur était associé un "type mime" que l'on retrouve
dans le champ "Content-type" de la réponse http. En général, le
serveur ouèbe possède une table de correspondance extension de fichier
vers type mime. Pour chacun des documents envoyés vers le butineur, le
type mime associé est également envoyé et le butineur dispose d'une
table de correspondance entre les types mime et la méthode
d'exploitation des données de ce type.
Par exemple, dans le serveur de mon bureau, j'ai un soft qui
fabrique des images au format PCX. Dans le fichier srm.conf d'Apache,
j'ai rajouté une directive "AddType image/pcx pcx" pour les documents
statiques, et j'utilise "Content-type: image/pcx" dans les scripts.
Coté Windaube 95, j'ai rajouté l'association "image/pcx=PBRUSH.EXE"
dans la configuration de Mosaic, et celui-ci lance Paintbrush dès
qu'arrive un PCX. Inutile de vous dire que c'est beaucoup plus
difficile avec IE :-) On peut utiliser cette possibilité pour beaucoup
de choses...
On retrouve le même principe pour les modules 'plugs-in' de
Netscape, mais je n'ai pas encore eu le temps d'étudier la chose.
14) Les Images dans le Ouèbe
Nous avons vu que le tag 
permettait
d'include une image au sein d'une page Ouèbe. Les formats de fichier
reconnus par la grande majorité des browsers sont: XBM (monochrome),
GIF (256 couleurs) et Jpeg (2^24 couleurs). En configurant des
visualiseurs externes, on peut bien entendu accéder à d'autres
formats, mais ce n'est plus de l'image en ligne.
La source de l'image est une URL, on peut donc avoir un fichier
en local ou un fichier qui provient d'un autre serveur: 
. D'autre part, le fichier image peut
être fabriqué par un programme. Par exemple, notre exemple peut être
facilement transformé en CGI:
1 #!/bin/sh
2 echo "Content-type: image/gif"
3 echo
4 cat foobar.gif
Quel est l'intérèt de cette façon de faire ? Absolument aucun
pour le moment, mais rajoutons une ligne à ce script, et les choses
changent:
5 echo $HTTP_REMOTE_ADDR >> remote.log
Et nous avons un enregistrement des adresses des 'hosts' qui ont
chargé cette image. Vous voyez, le Ouèbe, c'est vraiment des principes
simples, mais la mise en oeuvre est un peu plus compliquée dans la
réalité. N'oublions pas que _plusieurs_ clients peuvent charger en
même temps cette image, et donc il faut regler les conflits d'accès au
fichier 'remote.log'. Mon expérience personnelle m'a néammoins montré
que dans ce cas précis, et à des niveaux de charge raisonnable, ça
marche correctement.
Bien entendu, la méthode orthodoxe pour éviter ces conflits
nécessite de mettre un 'lock' sur le fichier, mais cela est assez
délicat à faire en bash.
15) Les sons et la musique dans le Ouèbe
Tout d'abord, allez relire le passage sur les visualiseurs
externes car c'est exactement les mêmes principes qui seront utilisés.
17) Ecrire des CGI en Fortran/f2c.
Quoi ? le Fortrash ! mais c'est un langage obsolète, complètement
ringard, pourquoi pas en Cobol ? Parce que je n'ai pas de Cobol dans
mon Linux. Plus sérieusement, c'est en lisant les news que cette idée
m'est venue. Je voyais passer de temps en temps des messages demandant
si cela était possible, et les réponses étaient assez "ironiques". Je
me suis donc penché sur la chose.
Il faut essentiellement écrire une librairie C pour récuperer les
variables d'environnement et décoder les requètes de formulaires. Je
ne pense pas que le boulot soit énorme, il faut juste trouvé comment
f2c gère ses variables de type texte.
Je commence à avoir quelques trucs qui fonctionnent, mais ce
n'est pas encore assez 'fini' pour être diffusé. Si il y a des
personnes interessées, contactez-moi pour avoir plus de détails.
21) Les compteurs de "hits"
Ahhh, que voilà un beau sujet de controverse. Tous ces petits
chiffres rigoureusement inutiles, obstinéments imprécis, sagement
rangés en bas des pages, qui essayent de se camoufler en s'encadrant
d'une phrase humoristique. Imaginez-vous les giga-octets de bande
passante dépensée par le futile égo humain ? Surtout avec les
compteurs qui s'incrémentent à chaque 'reload'. Ceux-là, des fois, je
me les fait à grand coup de TrashBrowser. Ce qui est très bon pour mon
égo à moi.
Voyons plutôt comment c'est réalise. On peut distinguer 3 étapes
dans la vie du compteur de 'hits': le déclenchement, l'addition et
l'affichage. Je passerais brièvement sur l'addition, tout le monde
sait faire une addition (en général, c'est sur des nombres entiers,
c'est pas trop dur). La gestion des accès concurrents à la base de
données sous-jacente ne doit pas vous poser de problèmes non plus.
Examinons plutôt le reste de l'opération.
Il existe deux grandes variétés de compteurs de hits, les
"graphiques" et les "textes". Cette distinction a une influence sur le
déclenchement, l'architecture et l'affichage.
a) les compteurs graphiques: Ils sont déclenchés lors d'une
requète de chargement d'image activée par un tag du genre:
et génèrent en sortie un fichier
graphique (xbm, gif, jpeg, peu importe). Ce fichier est donc
fabriqué indépendemment de la page texte, et peut-être par
un serveur différent. Cette catégorie peut être subdivisée
en deux branches: le compteur peut être un script CGI
conventionnel, ou un serveur spécialisé, un gros nano-
serveur en quelque sorte :-)
b) les compteurs textes: On les trouve dans les pages de la
catégorie "Serveur Side Include" ou "Parsed HTML". Un
marquage spécifique doit être dissimulé dans un commentaire
HTML: Le serveur, au
moment d'envoyer cette page dans le tuyau, la parcours,
cherche ces marquages, les decodes, exécute le programme
correspondant, en récupère 'stdout' et insère ce texte à la
volée dans ce qui est envoyé au butineur. C'est donc le même
serveur qui fournit le compteur et la page.
En dehors de la différence visuelle, quels sont les avantages et
les inconvénients des deux méthodes ? Euh, voilà, là, je sais pas trop
quoi répondre pour le moment. Tout d'abord, commençons par un _réel_
inconvénient des compteurs textes: ils déclenchent presque
systématiquement les "surveilleurs de pages" du genre de Netmind/URL-
minder.
24) Notions avancées en HTML.
Je suis très désolé, mais je
n'ai pas eu le temps de faire
ce chapitre.
30) La génération de page automatique.
En dehors de la fabrication manuelle et des scripts CGI, il
existe une troisième méthode: la fabrication automatique de pages à
partir d'informations diverses et variées. Nos Unicses sont munis d'un
petit esclave méconnu: 'cron', qui peut déclencher à intervalles
réguliers l'exécution d'un programme. Et ce programme peut
confectionner une page Ouèbe.
J'ai choisi comme exemple une statistique sur les utilisateurs
d'un système. Il y aura en fait deux programmes: le premier va
échantillonner les données à intervalle régulier (15 minutes), et le
second, de périodicité plus faible (24 heures ou une semaine), fera
l'analyse et l'écriture de la page.
#!/bin/sh
/usr/bin/who |
/usr/bin/awk '{ print $1; }' >> sample.who
Ce script shell collecte la première colonne de la sortie de la
commande 'who' dans un fichier texte. Cette première colonne contient
le nom de login. Il doit être lancé à intervalle suffisamment
rapproché pour avoir un échantillonnage correct.
Ensuite, il faut analyser les données collectées. Deux scripts
sont utilisés. Le premier, en shell, va construire la page HTML. Il
commence par écrire l'en-tête, puis passe la main à un programme awk
qui fait les calculs, et enfin, il écrit la fin de la page. Pour
finir, il mémorise les echantillons de la dernière période et des
trois précédentes afin de 'lisser' les résultats. Que les matheux de
l'assistance me pardonne si ma démarche manque de rigueur :-)
#!/bin/sh
cat <<__EOF__
Statistique des utilisateur
Statistiques des utilisateurs
__EOH__
/bin/cat sample.who sample.1 sample.2 sample.3 |
./cumul.awk >> page.html
cat <<__EOF__
__EOF__
/bin/cp sample.2 sample.3
/bin.cp sample.1 sample.2
/bin/cp sample.who sample.1
/bin/rm sample.who
La partie calcul est écrite en awk (ah, que voilà un langage bien
intuité !) qui permet facilement ce genre de manipulations. Notez la
concision de la première partie du script: l'indice de la table qui
sert à compter est vraiment le nom d'utilisateur !
#!/usr/bin/awk -f
{
table[$1]++;
total++;
}
END {
for (i in table)
printf "%-12s %4d %7.3f\n",
i, table[i], (table[i]/total)*100.0;
printf "nbre echantillons %d\n", total;
}
Voila, ce n'est qu'un exemple d'une utilité somme toute limitée,
mais cette méthode peut s'applique à beaucoup de choses. Elle permet
surtout de découpler la création de la page de sa consultation.
42) Conclusion
Pourquoi ce chapitre est-il numéroté 42 ?
Parce que 42 est la réponse à la question universelle
sur la Vie, l'Univers et le Reste.
J'espère que cette modeste conférence vous aura
donné envie d'aller plus avant dans l'étude des
techniques Ouèbes. Au sein de l'association, nous
pourrions envisager une étude commune, par exemple
la construction d'un nano-serveur, (nom de code
"Cassoulet") et qui contiendrais toutes les idées
plus ou moins farfelues qui ne vont pas tarder à
naitre dans vos cerveaux surchauffés par l'été.