Évitez la navigation.
AFUL · Parinux · FFII France · APRIL · ADULLACT · MongueursPerl · Wikipédia · OFSET · Scidéralle · LéaLinux · LinuxFrench · LinuxFr · FirstJeudi · AgendaLibre

sylvain(à)lhullier(.)org

Les dessous du Web

Dénouer le sac de noeuds

Du néant au Web : un peu d'histoire

Résister à une guerre nucléaire ...

Au début de l'informatique, les ordinateurs étaient non seulement lents et volumineux mais aussi isolés, c'est-à-dire qu'ils ne communiquaient pas entre eux. Ancêtre de l'internet que nous connaissons tous aujourd'hui, Arpanet fut le premier grand réseau d'ordinateur imaginé ; il a été pensé et mis au point pour des projets de recherche par les militaires états-uniens à la fin des années 1960. Le but de ce réseau était de relier des centres militaires dispersés sur le territoire du pays et avait pour contrainte de devoir résister à une attaque atomique de l'adversaire soviétique (il faut se remettre en tête le contexte de la Guerre Froide).

Le principal moyen technique prévu pour parvenir à cet exploit était de faire en sorte que les données qui devaient être transmises d'un centre à un autre pouvaient utiliser plusieurs chemins différents. C'est-à-dire que ces données n'étaient pas obligées de passer par la même "route" à chaque fois, plusieurs itinéraires étant disponibles. Les centres militaires étaient donc reliés à plusieurs autres centres de façon à créer le maillage le plus complet possible. Ainsi, si lors d'une attaque nucléaire un centre devait disparaître de la carte, le réseau restait fonctionnel car les données pouvaient encore transiter par d'autres routes. Aucun centre n'était indispensable aux communications.

Le premier réseau des réseaux est donc né de la Guerre Froide et était prévu pour résister à une attaque atomique ! C'est à cette époque qu'est mise au point la transmission des données par paquets : les données sont découpées en petites unités, envoyées sous cette forme et ré-assemblées à l'arrivée. C'est un peu comme si, pour envoyer un arbre par la poste, on en faisait de fines tranches que l'on envoyait dans une multitudes d'enveloppes et que le destinataire recollait pour avoir son arbre ...

... puis l'explosion du Web

Dès le début des années 1970, les organismes civils de recherche états-uniens se connectent ce réseau pour échanger des informations. En outre, plusieurs réseaux parallèles voient le jour dédiés à divers usages et publics. En juillet 1977, les principaux réseaux civils fusionnent pour donner naissance à Internet, réseau auquel les militaires ne participèrent pas directement.

C'est durant les années 1980 qu'apparaissent de nouveaux moyen de communication comme le courriel (email), les forums de discussion, l'échange de fichiers etc. La technique de transmission des paquets devient alors IP, Internet Protocole. Entre eux, les ordinateurs s'identifient au moyen de suites de nombres : les adresses IP ; il s'agit d'une suite de 4 nombres de 0 à 255 qui forme l'identifiant unique d'un ordinateur sur le réseau. Tout ordinateur connecté à Internet a une adresse IP qui lui est propre. Dans le même temps, le réseau commence à devenir mondial mais reste presque exclusivement dédié à la recherche scientifique.

En 1990 est inventé, en Suisse au CERN (Centre Européen de Recherche Nucléaire), un nouveau protocole : HTTP (hyper-text transfert protocol, protocole de transfert hypertexte) et surtout un nouveau concept : hypertexte. L'hypertexte est l'idée simple (mais encore faut-il l'avoir eu!) que l'on peut cliquer à l'aide de la souris sur certaines zones de texte pour changer de page : le lien hypertexte est ainsi né. Cela paraît idiot, mais jusque là, la notion de navigation n'existait pas : on s'envoyait des courriels, on se transférait des fichiers ... Pas très sexy en fait.

Ce concept resta pourtant 3 ans inutilisé jusqu'à ce que l'université de l'Illinois aux États-Unis mette au point des logiciels permettant de le mettre en oeuvre. Un premier serveur HTTP (httpd) et un premier navigateur (Mosaic, dont on a fêté les 10 ans en avril de cette année) ont été rendu disponibles. Ce serveur httpd donnera naissance un peu plus tard à Apache (le célèbre serveur web utilisé aujourd'hui) et tous les navigateurs qui suivront (Netscape etc) s'inspirerons du navigateur Mosaic. À cette époque des pionniers, seuls quelques centaines serveurs mettaient en ligne quelques pages vues par quelques milliers de personnes tout au plus. Ce furent aussi les débuts du HTML qui introduisait le graphisme (pour le première fois des images et du texte sur une même page !). et conduira vers le multimédia. On nomma assez vite tout cela le World Wide Web (ou WWW), la toile d'araignée mondiale, même si Internet n'a pas attendu l'hypertexte pour être une toile d'araignée mondiale. Ce qu'il reste de cette époque, ce sont entre autres le mot Web et l'habitude d'avoir des noms de serveurs web commençant par www.

Depuis c'est l'explosion d'Internet, surtout poussée par le succès du Web justement, d'abord aux États-Unis puis en Europe et au Japon puis dans le reste du monde : universités puis entreprises privées et enfin grand public, tout le monde est aujourd'hui connecté.

Bon, mais comment ça fonctionne tout ça ?

Passons maintenant à inspecter les dessous du Web ...

Quelques gros mots

Le Web est donc basé sur le protocole HTTP. Un protocole est une manière de communiquer entre ordinateurs. On peut faire un parallèle avec une discussion par talkie-walkie : chacun attend que l'autre ait dit STOP pour prendre la parole, il s'agit ici d'un protocole entre deux personnes. HTTP est un protocole entre ordinateurs, il indique comment transmettre des informations sur le réseau pour ce qui concerne le Web.

Sur internet et en particulier sur le Web, tout a une adresse : une URL. Entre autres, ce sont les fameuses adresses de la forme http://www.linuxfr.org/2002/12/12/10651.html qui apparaissent dans la barre de votre navigateur. URL signifie en anglais Uniform Resource Locator, que l'on traduit mot à mot par localisateur uniforme de ressource. Derrière cet affreux nom se cache en fait une idée simple et puissante : une ressource (un fichier, une page, une image etc) peut avoir une adresse fixe sur Internet ; transmettre cette adresse à une personne sans lui envoyer la ressource, c'est lui permettre d'accéder à la ressource sans devoir passer par vous (elle y accède directement).

Les URL du Web ont une syntaxe précise :

C'est quoi un serveur web ?

Essentiel au fonctionnement du Web, mais caché au fin fond du réseau, le serveur web est celui qui dispose de l'information qui intéresse l'utilisateur. Son rôle est donc essentiel.

Les serveurs web sont des ordinateurs constamment connectés à Internet, souvent hébergés en grand nombre dans des salles climatisées spécialisées. Ces ordinateurs ont un système d'exploitation (souvent Linux® ou BSD, mais bien d'autres sont possibles) et un programme : le serveur web. En fait le terme serveur web a deux sens : il s'emploie aussi bien pour désigner le programme en question que pour désigner de l'ordinateur sur lequel il est lancé.

Ce programme serveur web est constamment présent sur le système, il est en fonctionnement 24h/24 et 7j/7 : cela est nécessaire si vous voulez pouvoir naviguer sur les sites à toute heure du jour et de la nuit. Pour qualifier un tel programme en anglais, on parle de daemon traduit en français par démon ou programme résident en mémoire.

Et que fait ce programme ? Il attend les connexions sur le port auquel il est affecté (donc souvent le 80) et y répond (nous verrons bientôt comment).

Le plus connu des serveurs web est le logiciel libre Apache, il représente plus de 60% des serveurs au monde (source NetCraft mars 2003) et il est le premier depuis 1996 (même source). C'est donc un produit éprouvé, réputé et reconnu.

Et mon navigateur dans tout ça ?

Ok, tout cela est très bien, mais comment le navigateur affiche-t-il la page web dont je viens de lui donner l'adresse ? Et bien, cela ne se fait pas en une seule étape. Imaginons le cas d'une page HTML comportant des images.

Tout d'abord, le navigateur se connecte au serveur cité, au port éventuellement indiqué (sinon il utilise le port 80). Il va ensuite demander la page HTML en question via une requête au serveur (nous détaillerons ce qu'est une requête dans la suite) ; en réponse à cette requête, le serveur va lui transmettre la page. Mais ce HTML est transmis sous forme d'un simple fichier (comment faire autrement ?), c'est-à-dire sous la forme qu'apparaît une page HTML dans un éditeur de texte (emacs, vi, gedit, kedit ...). Cela signifie que les images ne sont pas transmises.

À cette étape, le navigateur va analyser le HTML qu'il vient de recevoir et à chaque inclusion d'image qu'il rencontrera (tag HTML <img src="image.png">) il fera une autre requête au serveur pour obtenir l'image. Il y aura autant de requêtes que d'images inclues dans la page. Notez bien que si la page HTML inclut des images stockées sur d'autres serveurs (c'est-à-dire sur d'autres ordinateurs), le navigateur doit se connecter à ces serveurs pour leur faire des requêtes. Il n'est pas simple d'être un navigateur !

 schéma

Lorsque l'on charge une page avec beaucoup de grosses images, on voit souvent que les images apparaissent les unes après les autres. Cela vient du fait que chacune de ces images fait l'objet d'une requête indépendante pour laquelle le temps de réponse peut donc varier.

Passons à la pratique

Il est possible de se prendre pour un navigateur et de se connecter à un serveur web pour faire une requête "à la main". Ah bon c'est possible ça ? Ben oui : nous allons jouer au client HTTP face au serveur HTTP. Nous allons, par exemple, accéder à la page http://www.linux-pratique.com/index.php?view=sondage

Se connecter

Et je fais comment avec mon navigateur ? Heu ... tu ranges ton navigateur, et tu prends un terminal. Le programme que nous allons utiliser se nomme telnet Comment fonctionne ce programme ? Il prend deux arguments : le nom de l'ordinateur et le numéro de port. Le nom de l'ordinateur à contacter est ici www.linux-pratique.com et, faute de port indiqué, il s'agit du port 80. Dans notre terminal, nous tapons donc la commande suivante :

$ telnet www.linux-pratique.com 80

Le programme telnet va donc convertir le nom du serveur en son adresse IP et tenter de s'y connecter. Si tout se passe bien, le programme affiche la chose suivante :

Trying 195.6.242.140...

On voit alors l'adresse IP du serveur en question : 195.6.242.140. Si tout se passe bien une nouvelle fois, au bout d'un certain temps (qui peut être infime), le programme affiche la chose suivante :

Connected to www.linux-pratique.com.
Escape character is '^]'.

La connexion s'est alors bien passée. C'est à nous de causer. Et comment cause-t-on ? Et bien c'est justement le protocole HTTP qu'il faut connaître. Ce protocole fait l'objet d'une définition précise que les serveurs et les navigateurs se doivent de respecter. Dans notre cas, nous allons utiliser le minimum nécessaire pour obtenir notre page. Notez bien que toutes les commandes HTTP que nous allons envoyer au serveur sont très sensibles au fait que les lettres soient en majuscules ou en minuscules, sont très sensibles à la présence ou non d'espaces etc ...

Faisons notre requête

Nous allons faire une requête HTTP au serveur, comme le ferait tout bon navigateur. La première ligne d'une telle requête comporte le mot GET obligatoirement en majuscule, suivi d'une espace, suivie du chemin d'accès à la page, suivi d'une espace, suivie du niveau de protocole. Ce qui donne (respecter exactement les majuscules/minuscules ainsi que les espaces) :

GET /index.php?view=sondage HTTP/1.0

Terminez votre ligne par un retour chariot. Des lignes dites d'en-tête vont venir à la suite. Une ligne d'en-tête est de la forme suivante : un nom de variable, suivie du signe deux-points, suivi d'une espace, suivie de la valeur de la variable. Parmi celles-ci, une d'entre elle est obligatoire : celle qui indique au serveur le nom qui nous a permis de le contacter. Mais il ne connaît pas son nom ? allez-vous me demander. J'expliquerai pourquoi plus loin. Nous devons donc écrire la ligne suivante :

Host: www.linux-pratique.com

Terminons cette autre ligne par un retour chariot. Il serait éventuellement possible de fournir d'autres lignes d'en-tête, mais nous allons arrêter là. Un navigateur fournira bien plus d'en-têtes au serveur, mais cela ne change rien pour notre démonstration. Pour signaler au serveur que nous avons fini notre requête et qu'il doit y répondre, il faut laisser une ligne vide, c'est-à-dire taper une nouvelle fois un retour chariot.

La totalité de la requête que nous faisons au serveur est donc la suivante :

GET /index.php?view=sondage HTTP/1.0
Host: www.linux-pratique.com

Tout le monde suit ?

Ce que répond le serveur

Juste après avoir tapé la ligne vide, le serveur émet sa réponse et nous déconnecte. La réponse est souvent très rapide et si le volume de HTML dépasse la taille du terminal, les lignes que nous avons tapées ont alors disparues dans des profondeurs accessibles au moyen de la barre de défilement du terminal. Je vous invite à tenter de remonter dans votre terminal de façon à retrouver ces lignes.

La réponse du serveur est la suivante :

HTTP/1.1 200 OK
Date: Thu, 24 Apr 2003 16:09:01 GMT
Server: Apache/1.3.23 (Unix) Debian GNU/Linux PHP/4.1.2
X-Powered-By: PHP/4.1.2
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>GNU/Linux Pratique</title>
</head>
<body>
<img src="img/logo.jpg" class="logo" alt="GNU/Linux Pratique Logo">
<p>Actuellement en kiosque</p>
<h2>GNU/Linux Pratique 17</h2>

....

<img src='http://www.linuxmag-france.org/img/LMHS14.jpg'
     border='0' width='145' alt='GNU/Linux Magazine Hors Série'>
<br>
</body>
</html>

Détaillons. La première ligne est la ligne de statut. Elle indique le niveau de protocole que le serveur est capable de produire (passons les détails). Elle indique un numéro de statut ; il s'agit ici de 200, ce qui signifie que la requête s'est bien passée. Il existe plein d'autres numéros de statut voués à des rôles divers et variés ; celui que vous connaissez sans doute, c'est le code 404 signifiant que la page n'existe pas : voici l'erreur 404 expliquée ! La fin de la ligne est un petit texte en anglais expliquant le statut (ici OK).

Les cinq lignes suivantes sont des lignes d'en-tête. Elles comportent des informations sur la page en question et sur le serveur ; ici le serveur a décidé de nous en fournir cinq (il aurait bien pu en fournir d'autres dans un ordre différent et un nombre quelconque). La première ligne d'en-tête indique l'heure actuelle sur le serveur. La seconde indique le nom, la version, le système et les modules du serveur web qui répond ; on notera qu'il s'agit d'Apache avec le module PHP sur une Debian. La ligne suivante en remet une couche sur PHP (dont nous parlerons plus loin). La quatrième ligne concerne le protocole HTTP et indique au navigateur que la connexion sera coupée après transmission du fichier (d'autres cas sont prévus dans HTTP). La dernière ligne d'en-tête indique le type de fichier transmis (ici du text/html) et la manière de représenter les lettres accentuées (encodage iso-8859-1 autrement nommé latin1).

La réponse du serveur comporte ensuite une ligne vide qui fait office de séparateur entre les lignes d'en-tête et le contenu du fichier transmis.

La suite (qui a été coupée dans cet article) constitue le fichier HTML que le navigateur devra analyser.

Bon, et les images ?

Comme je l'avais déjà indiqué précédemment, chaque image doit faire l'objet d'une requête individuelle. Les deux images laissées en exemple dans le HTML renvoyé par le serveur illustrerons parfaitement les cas qui peuvent se présenter pour un navigateur.

La première image est insérée dans la page au moyen du tag HTML suivant :

<img src="img/logo.jpg" class="logo" alt="GNU/Linux Pratique Logo">

Pour ce qui concerne l'opération de récupération de l'image sur le réseau, la seule information qui nous intéresse ici est celle contenue dans l'attribut src, c'est-à-dire son adresse. On note ici que l'adresse est relative, cela signifie que l'URL de l'image n'est pas indiquée complète (c'est-à-dire qu'elle ne commence pas par http:// etc).

Dans ce cas le navigateur doit calculer l'adresse exacte de la façon suivante. Sauf contre-indication dans le HTML, il doit considérer que l'adresse de l'image a pour base le répertoire de la page HTML qui la contient. Dans notre cas, il s'agit de http://www.linux-pratique.com/ (l'URL de la page privée du nom du fichier et des paramètres) ; l'adresse exacte de l'image est donc http://www.linux-pratique.com/img/logo.jpg ; le navigateur doit donc contacter le même serveur sur le même port et demander le fichier /img/logo.jpg

Exemple complémentaire, si la page avait pour URL http://www.linux-pratique.com/rep1/rep2/page.html et incluait une image dont l'adresse relative était ../rep3/image.png la requête se ferait sur le fichier /rep1/rep3/image.png

Second exemple, l'image de bas de page est insérée dans la page au moyen du tag HTML suivant :

<img src='http://www.linuxmag-france.org/img/LMHS14.jpg'
     border='0' width='145' alt='GNU/Linux Magazine Hors Série'>

Ici l'URL de l'image est donc absolue (par opposition à relative). Le navigateur doit donc contacter l'ordinateur www.linuxmag-france.org sur le port 80 et lui demander le fichier /img/LMHS14.jpg

Nous allons encore une fois nous mettre dans la peau du navigateur et faire la requête sur l'image :

$ telnet www.linuxmag-france.org 80

La connexion est établie :

Trying 195.6.242.140...
Connected to www.linuxmag-france.org.
Escape character is '^]'.

Faisons ensemble la requête :

GET /img/LMHS14.jpg HTTP/1.0
Host: www.linuxmag-france.org

Ce à quoi le serveur répond cela :

HTTP/1.1 200 OK
Date: Thu, 24 Apr 2003 18:41:20 GMT
Server: Apache/1.3.23 (Unix) Debian GNU/Linux PHP/4.1.2
Last-Modified: Fri, 14 Mar 2003 15:11:52 GMT
ETag: "be1b-623f-3e71f138"
Accept-Ranges: bytes
Content-Length: 25151
Connection: close
Content-Type: image/jpeg

... données binaires de l'image ...

Les données binaires de l'image ? Et bien oui, les formats d'images courants sont tous binaires, donc pas vraiment affichables dans un terminal. Si votre terminal est dans un drôle d'état (les caractères que vous tapez au clavier s'affichent étrangement) taper la commande reset, elle devrait tout remettre en état.

J'ai encore des questions !

L'en-tête Host

On ne m'a toujours pas expliqué pourquoi il faut donner au serveur son nom dans l'en-tête Host. Effectivement ... Peut-être avez vous noté que, lors de nos deux utilisations du programme telnet, les deux serveurs www.linux-pratique.com et www.linuxmag-france.org avaient la même adresse IP, en l'occurrence 195.6.242.140 ...

Cela signifie qu'un même ordinateur peut avoir plusieurs noms pour une même adresse IP. En fait, les DNS (programmes qui font la correspondance entre le nom d'un ordinateur et son adresse IP) peuvent parfaitement associer plusieurs noms à une même adresse.

Sur cet ordinateur, le programme serveur web doit être configuré de façon à ce que l'utilisateur ne voie rien de tout cela et croit à l'existence de plusieurs serveurs distincts. Dans notre exemple, l'ordinateur qui héberge les sites web www.linux-pratique.com et www.linuxmag-france.org comporte les fichiers de ces deux sites sur son disque dur ; selon le nom qui a permis de joindre le serveur, celui-ci va envoyer certains fichiers plutôt que d'autres. On parle de mutualisation. Dans Apache il s'agit du mécanisme des virtual host.

Pourquoi de telles astuces ? Parce que le nombre de sites web à mettre en ligne augmente plus vite que notre capacité à réduire la taille des ordinateurs, parce que le nombre d'adresses IP n'est pas infini et surtout parce qu'il ne sert à rien d'avoir un ordinateur entier dédié à l'hébergement d'un petit site qui à seulement quelques milliers de visites par jour ... Imaginez le cas d'hébergeurs comme free.fr, OVH, Online.fr, Amen ou même tuxfamily.org qui hébergent autant de sites web qu'ils ont de comptes, ils ne vont pas disposer un ordinateur par client ! Ils vont mutualiser les serveurs web ; certainement auront-ils plusieurs ordinateurs, mais chacun d'entre eux hébergera des milliers de sites.

Revenons à la question initiale : pourquoi faut-il communiquer au serveur le nom via lequel on le contacte ? Pour des raisons techniques, le serveur ne peut connaître tout seul que l'adresse IP via lequel on le contacte, il ne peut pas savoir le nom (souvenez vous de la conversion faite par telnet et donc par les navigateurs du nom en adresse IP avant la connexion). Or, pour pouvoir renvoyer la page du bon site, il faut qu'il connaisse ce site.

On peut faire l'expérience de cela via le cas pratique suivant : nous allons contacter le serveur commun aux deux sites www.linux-pratique.com et www.linuxmag-france.org au moyen de son adresse IP et faire en sorte d'obtenir la racine de chacun. Pour cela, nous allons à nouveau utiliser le programme telnet :

$ telnet 195.6.242.140 80

Et faisons la requête suivante (n'oubliez pas la ligne vide à la fin) :

GET / HTTP/1.0
Host: www.linux-pratique.com

La page d'accueil de Linux-Pratique nous est alors renvoyée. Faisons maintenant la même chose pour Linux-Magazine :

$ telnet 195.6.242.140 80

Et faisons la requête suivante :

GET / HTTP/1.0
Host: www.linuxmag-france.org

La page renvoyée est bien celle de Linux-Magazine !

C'est quoi HTTPS ?

Vous utilisez le Web tous les jours et vous ne savez peut-être pas que les informations que vous échangez ainsi circulent sur le réseau sous une forme lisible pour tout le monde. Cela signifie qu'une personne, présente sur un des ordinateurs qui vous relient au serveur web consulté, peut connaître exactement la teneur des échanges que vous faites. Je pense principalement à votre fournisseur d'accès, qui a, par ailleurs, obligation légale de conserver trace de toute connexion et de collaborer avec la justice.

Quelle importance puisque le contenu des sites web est disponible pour tous ? Effectivement, pour la plupart des sites, cela est sans importance (encore que ...). Mais qui n'a jamais consulté son courriel via le Web ? Qui n'a jamais participé à des discutions privées via un serveur web ? Et bien toutes les informations que vous envoyez ou recevez ne sont pas protégées, en tout cas en HTTP. Laissez vous votre facteur lire votre courrier ? Alors pourquoi laisser en faire autant sur Internet ?

HTTPS est un protocole web qui, par rapport à HTTP, apporte principalement l'avantage que la communication entre vous et le serveur est cryptée. Ce cryptage correspond au fait que seuls vous et le serveur avez accès à l'information échangée. Tout au plus, l'observateur extérieur sais que des informations transitent, mais il ne peut pas en connaître le contenu. Le sigle HTTPS vient de HTTP over SSL (HTTP utilisant SSL), SSL étant un célèbre composant logiciel de cryptage.

Les URL pour le protocole HTTPS commencent par https:// (étonnant non? ;-)), comme par exemple dans https://www.banquebipop.fr/ et c'est à cela que l'on peut savoir quel protocole est utilisé. Il existe différents niveaux de cryptage, mais soyez sûr d'être en HTTPS lorsque vous saisissez votre numéro de carte bleue ...

J'ai vu passé le mot PHP ...

PHP est un des langages de programmation qui permettent de rendre dynamiques les contenus des pages web.

Jusque dans les années 1995, les pages web étaient de simples fichiers texte contenant du HTML écrits une bonne fois pour toutes sur le disque dur du serveur web. Les sites en question étaient donc figées, on dit aussi statiques (par opposition à dynamiques).

La première idée fut de modifier le contenu des pages web affichées en fonction d'informations venant de l'utilisateur ; ce fut la naissance des formulaires. Les utilisateurs sont invités à saisir des données dans des champs texte ou choisir des valeurs proposées par des menus déroulants. Ensuite l'utilisateur doit cliquer sur un bouton de validation ; la page qui est finalement affichée prend en compte les informations saisies. Cette page ainsi affichée n'a donc pas d'existence comme fichier HTML sur le disque dur du serveur web : elle est calculée à la volée à chaque fois qu'un utilisateur remplit le formulaire. Pour cela, un petit programme doit générer la page en question, car elle est différente à chaque fois. Parmi les langages permettant de faire cela, PHP est sans doute le plus facile à apprendre pour les débutants et donc le plus répandu.

La seconde étape fut de stocker des information dans une base de données. Une base de données est un ensemble de programmes présents sur le serveur web, dont le rôle est de stocker des informations ; une base de données facilite la consultation, la modification, l'ajout et la suppression de telles informations. Ces opérations sont plus faciles à faire que si les données étaient bêtement stockées dans un fichier texte par exemple. La base de données la plus simple dans ce domaine est MySQL, elle est donc très fréquemment associée à PHP pour faire des pages dynamiques. On peut alors imaginer stocker les informations saisies dans le formulaire par l'utilisateur dans cette base de données d'un côté, et d'afficher toutes les informations de la base sur une autre page.

 schéma

On peut alors envisager de faire des livres d'or, des forums de discussion et bien d'autres choses sur le Web.

Conclusion

N'hésitez pas à m'écrire pour toute remarque, suggestion ...

Ce site respecte les standards de l'internet :
XHTML 1.1   ·   CSS v2   ·   Accessibilité
Plan du site  ·  Signature  ·  Imprimer la page
© 1999-2008 Sylvain Lhullier
http://sylvain.lhullier.org/publications/dessous-web.html
Creative Commons Attribution-ShareAlike