Le Web

L'auteur de cette page est : Jean-Baptiste Yunes

L'hypertexte

Ce mot désigne un type de documents dans lesquels le texte est agrémenté non seulement d'annotations, d'index, sommaires ou références mais surtout de renvois à d'autre documents. Évidemment c'est la forme numérique d'un tel texte qui est ainsi nommée, car il est alors possible de rendre aisée la navigation à travers les liens relationnels établis. Le texte n'est alors plus conçu linéairement mais fragmenté en composantes liées par des relations sémantiques. De plus, ce qui différencie un texte habituel (par exemple celui d'une encyclopédie) d'un hypertexte c'est la possibilité qu'offre le second d'évoluer au cours du temps. Cette évolution peut évidemment concerner le fond mais aussi les relations entre les fragments.

De nombreuses autres caractéristiques propres aux hypertextes peuvent être dégagées comme par exemple la possibilité de créer des textes génériques pour lesquels la consultation n'est faite que sur des instances générées en temps-réél. Ou encore la délocalisation des fragments qui contribue à une possible répartition dans l'espace.

L'hypertexte peut être encore étendu en hypermédia. Cette fois-ci il ne s'agit plus de texte mais de fragments de documents en tout genre (sonores, graphiques fixes ou animés..) toujours liés entre eux.

Il existe un article que chaque spécialiste de l'hypertexte considère comme fondateur : c'est "As we may think" de Vannevar Bush paru en 1945! Mais vous pouvez aussi consulter The Electronic Labyrinth.

De nombreuses applications ou produits sont aujourd'hui hypertextes ou hypermédia : systèmes d'aide aux utilisateurs pour les logiciels les plus courants, dictionnaire ou encyclopédies numérisées, CD-ROM, DVD...

L'application de ces différents concepts a conduit aujourd'hui à ce que l'on appelle la Toile ou World Wide Web, qui n'est autre qu'un système hypermédia à l'échelle de la planète (vision optimiste ou idéaliste) sinon à l'échelle du monde dit développé (vision plus réaliste dans laquelle se pose évidemment le problème de l'exclusion technologique et culturelle).

Le Web

Il s'agit d'une construction applicative coopérante fonctionnant sur le réseau Internet. Un ensemble de serveurs fournissent à la demande des documents typés (texte simple ou balisé, image fixe ou animée, etc.) aux clients désirant de les consulter. Nombre de ces documents contiennent des références à d'autres documents que l'on peut obtenir auprès d'un autre serveur que la source première. Chacun de ses documents étant alors vu comme un fragment du document constitué par l'ensemble des fragments obtenus par le parcours itératif de tous les liens. Évidemment une telle tentative est par nature vouée à l'échec car les documents se modifient au cours du temps (et donc les liens qu'ils contiennent), voire disparaissent. Il n'est pas pensable d'obtenir, en général, l'instantané d'un document : c'est un objet vivant dont on ne peut saisir la totalité.

Il existe une organisation internationale chargée du développement du Web nommé W3C (World Wide Web consortium) hébergé par trois instituts : le MIT/LCS (Laboratory of Computer Science du Massachusett Institute of Technology) aux États-Unis, l'INRIA (Institut National de Recherche en Informatique et en Automatique) en France et l'Université de Keio au Japon. Plusieurs centaines de partenaires participent aux activités du consortium : spécifications, logiciels, outils, normalisation...

Les documents généralement typés en HTML sont donc échangés en utilisant le protocole HTTP.

Le protocole HTTP

Ce protocole est normalisé par différents documents : RFC 1945 et RFC 2616 qui en définissent trois versions :

  1. 0.9 qui n'est autre que le protocole définit à l'origine par Tim Berners-Lee,
  2. 1.0 qui apporte de très nombreuses fonctionnalités (typage des documents, codage du contenu, identification, ...)
  3. 1.1 maintenant la plus avancée qui permet de réaliser différentes négociations, d'obtenir des canaux persistants, etc.

Le port TCP par défaut est le 80.

HTTP/0.9

Les conversations dans cette version du protocole sont des plus simples : après avoir initié une connection avec le serveur, le client envoie une requête (commande et paramètres), reçoit en réponse un document. Après réception (respectivement envoi) la connection est fermée par le client (respectivement serveur). Il n'existe qu'un seul type de requête : GET dont la forme est "GET" <sp> URI <crlf>. La réponse du serveur étant un corps de document (suite d'octets) qui doit être lu jusqu'à fermeture de la connexion par le serveur. Par exemple :

$ telnet www.liafa.jussieu.fr www
Trying 127.0.0.1...
Connected to www.liafa.jussieu.fr.
Escape character is '^]'.
GET /~yunes/a.txt demande de lecture du document
Ceci est un document... contenu du document réclamé
Connection closed by foreign host.

Correspond exactement à la transaction réalisée par un navigateur désirant charger le document par l'URI http://www.liafa.jussieu.fr/~yunes/a.txt. Attention : l'URI de la requête GET ne doit pas contenir le protocole (sous-entendu par le port employé lors de la connexion), ni le nom de la machine (sous-entendu aussi par la connexion) : ce qui reste est donc une URI locale. Sauf dans le cas où la connexion est réalisée à travers un serveur proxy. En ce cas, il FAUT laisser l'URI d'origine.

HTTP/1.0

Cette version du protocole a introduit différents types de requêtes ainsi que la possibilité de décrire les contenus échangés. Le document décrivant cette version est la RFC 1945.

La grammaire (simplifiée) est la suivante :

Message-HTTP = Requête-Simple | Réponse-Simple | Requête-Complète | Réponse-Complète
Requête-Simple = "GET" SP URI CRLF
Réponse-Simple = Corps-Entité
Requête-Complète = Ligne-Requête ( Entête-Général | Entête-Requête | Entête-Entité )* CRLF [Corps-Entité]
Ligne-Requête = Méthode SP URI SP Version-HTTP CRLF
Méthode = "GET" | "HEAD" | "POST" | Méthode-Étendue
la méthode HEAD permet de ne recevoir que les informations sur la ressource. GET permet de recevoir les informations puis les données associées. Quant à POST elle permet d'indiquer que l'utilisateur désire envoyer des données; dans ce cas la requête est suivie par un Corps-Entité.
Version-HTTP = "HTTP" "/" CHIFFRE+ "." CHIFFRE+
spécifie la version du protocole utilisée pour générer la requête ou la réponse. Ex: HTTP/1.0
Entête-Général = Date | Pragma
Date = "Date" ":" Date-HTTP
permet de spécifier la date à laquelle le message à été généré.
Pragma = "Pragma" ":" Directive-Pragma
permet de spécifier certaines particularités du dialogue.
Directive-Pragma = "no-cache" | Pragma-Étendu
la valeur no-cache permet d'interdire aux serveurs intermédiaires d'utiliser une copie du document en réponse à la requête. Ainsi l'utilisateur obtiendra une copie fraîche de l'original.
Entête-Requête = Autorisation | Propriétaire-Agent | Si-Modifié-Depuis | Source | Agent
Autorisation = "Authorization" ":" Identification
Identification = Identification-Basique | Identification-Étendue
permet de spécifier le schéma d'identification utilisé
Identification-Basique = "Basic" SP <codage en base64 d'un couple identité/mot-de-passe>
ce schéma d'identification est le plus simple et très certainement le moins sûr. Il ne doit pas être utilisé pour réaliser des protections avancées.
Propriétaire-Agent = "From" ":" mél
ce champ permet de spécifier l'adresse électronique de l'utilisateur courant du navigateur.
Si-Modifié-Depuis = "If-Modified-Since" ":" Date-HTTP
permet de réaliser une requête GET conditionnelle. Si le document n'a pas été modifié depuis la date spécifiée le serveur renverra une réponse de type 304.
Source = "Referer" ":" URI
permet de spécifier l'URI du document dans lequel on a trouvé le lien menant à celui réclamé.
Agent = "User-Agent" ":" Texte
permet de spécifier le navigateur utilisé. Les valeurs ne sont pas normalisées. Ex: User-Agent: Mozilla/4.04 (X11; I; SunOS 5.4 sun4m)
Entête-Entité = Permission | Codage | Longueur | Type | Péremption | Dernière-Modification | Entête-Étendue
Permission = "Allow" ":" Méthode+
permet de spécifier les méthodes supportées par cette ressource.
Codage = "Content-Encoding" ":" Type-Codage
permet de spécifier le codage utilisé pour transmettre le document. Il s'agit généralement d'une compression.
Type-Codage = "x-gzip" | "x-compress" | Type-Étendu
spécifie le codage utilisé lors de la transmission des données.
Longueur = "Content-Length" ":" CHIFFRE+
permet de spécifier la longueur exprimée en octets du Corps-Entité
Type = "Content-Type" ":" Type-MIME
permet de spécifier le type MIME associé aux données après application du décodage. Ex: Content-Type: text/html.
Péremption = "Expires" ":" Date-HTTP
spécifie la date de péremption de la ressource. Elle signifie simplement que les données pourront être considérées comme obsolètes passé cette date, mais en aucune manière que la ressource ne sera plus accessible.
Dernière-Modification : "Last-Modified" ":" Date-HTTP
permet de spécifier la date de dernière modification de la ressource.
Corps-Entité = OCTET*
c'est la suite d'octets qui devra être lue soit à concurrence de la Longueur spécifiée, soit de la coupure de la connexion. Cette suite doit être décodée inversement au schéma de Codage pour être ensuite interprétée selon le Type.
Réponse-Complète = Ligne-Réponse ( Entète-Général | Entête-Réponse | Entête-Entité )* CRLF [Corps-Entité]
Ligne-Réponse = Version-HTTP SP Code SP Texte
indique quelque version du protocole est utilisée pour répondre à la requête, quelle erreur a été générée et un petit texte explicatif.
Code = CHIFFRE3
permet d'indiquer le type de réponse. Il en existe 5 classes principales (spécifiées par le premier chiffre) :
1xx
réponses de type informationnelle (encore non employées)
2xx
succès. La requête a bien été reçue et acceptée.
3xx
succès partiel. La requête est correcte mais nécessite des opérations supplémentaires pour être correctement réalisée.
4xx
échec causé par le client. La requête contient des erreurs de syntaxe ou est incomplète.
5xx
échec causé par le serveur. Le serveur est incapable de réaliser l'opération.
Les codes existants sont les suivants :
200 OK
En réponse à GET le serveur renvoie une Réponse-Complète et un Corps-Entité. En réponse à HEAD le serveur ne renvoie que les informations d'entête (Réponse-Complète - Corps-Entité). En réponse à POST le serveur renvoie un document résultat.
201 Created
En réponse à POST le serveur indique que la ressource a été créée et qu'elle est désormais disponible à travers l'URI renvoyé dans le Corps-Entité.
202 Accepted
Indique simplement que la requête a été acceptée. Il s'agit des requêtes provoquant des calculs différés.
204 No Content
Le serveur désire indiquer que la requête est correcte mais qu'il n'y a aucune information en retour. Par conséquent le navigateur ne doit pas modifier l'affichage.
300 Multiple Choices
Permet au serveur d'indiquer que la ressource est disponible à differents endroits, en ce cas le Corps-Entité doit contenir la liste des équivalents.
301 Moved Permanently
Permet au serveur d'indiquer que la ressource ne sera plus jamais disponible à cette URI et qu'il faut désormais utiliser la nouvelle Position.
302 Moved Temporarily
Permet au serveur d'indiquer que la ressource n'est plus disponible à cette URI, qu'il faut pour l'instant utiliser l'adresse spécifiée par Position, mais que dans le futur la ressource redeviendra disponible.
304 Not Modified
Permet de répondre aux requêtes conditionnelles (Si-Modifié-Depuis).
400 Bad Request
Le serveur est incapable d'interpréter la requête qui est probablement mal formée.
401 Unauthorized
La ressource n'est disponible qu'avec une Identification. Le champ Schéma-Identification permet de spécifier quel type d'identification est attendu.
403 Forbidden
L'accès à cette ressource est formellement interdit, avec ou sans identification. La requête ne doit pas être reproduite en l'état.
404 Not Found
Le serveur n'est pas capable de localiser la ressource.
500 Internal Server Error
501 Not Implemented
Cette fonctionnalité n'est pas supportée par le serveur.
502 Bad Gateway
Le serveur (en tant que passerelle ou mandataire) a reçu une réponse invalide en provenance du serveur.
503 Service Unavailable
Le serveur indique qu'il est pour l'instant incapable de répondre, le client doit réessayer plus tard.
Entête-Réponse = Position | Serveur | Schéma-Identification
Position = "Location" ":" URI
permet de spécifier l'exact localisation de la ressource.
Serveur = "Server" ":" Texte
permet de spécifier quel serveur a répondu. Ex : Server: Apache/1.3.9 (Unix) PHP/3.0.12
Schéma-Identification = "WWW-Authenticate" ":" Valeur
permet de spécifier la méthode d'indentification à employer pour accéder à la ressource. Ex: WWW-Authenticate: Basic realm="UK". Un client pourrait tenter d'accéder à la ressource en employant Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== (codage base 64 du couple Alladin/open sesame a priori définit dans le domaine UK).
Valeur = Schéma SP+ Domaine ( Paramètres )*
permet de spécifier le schéma d'indentification à utiliser ainsi que l'espace des noms.
Schéma = "Basic" | Texte
Domaine = "realm" "=" Texte

Un échange dans cette version pourrait prendre la forme suivante :

$ telnet www.liafa.jussieu.fr wwwTrying 127.0.0.1...
Connected to www.liafa.jussieu.fr.
Escape character is '^]'.
GET /~yunes/a.txt HTTP/1.0 demande de lecture du document
HTTP/1.0 200 OK réponse au format 1.0. Tout va bien...
Date: Thu, 07 Dec 2000 15:39:22 GMT Date de la réponse
Server: Apache/1.3.9 (Unix) PHP/3.0.12 Identification du serveur
Last-Modified: Thu, 07 Dec 2000 12:40:34 GMT Date de dernière modification du document
Content-Length: 24 Longueur de la réponse
Content-Type: text/plain Type du document
Ceci est un document... Les voilà les 24 octets...
Connection closed by foreign host.

HTTP/1.1

Le document décrivant cette version du protocole est la RFC 2616.

Les connexions persistantes

Auparavant le chargement de chaque URL nécessitait une connexion TCP spécifique (voir HTTP/0.9). Il est désormais possible d'utiliser une connexion persistante afin de communiquer efficaçement avec le serveur considéré. Cela permet de limiter les ouvertures et fermetures incessantes de connexions TCP, de permettre une communication pipelinée entre le client et le serveur, de limiter les délais de latence dus aux ouvertures TCP et de permettre de reporter des erreurs HTTP sans pénaliser le client par une fermeture de la connexion.

Les serveurs conformes à cette spécification doivent absolument supporter ce mode de fonctionnement. De plus ce doit être le mode opératoire par défaut, ainsi le client doit lui aussi se comporter en conséquence. Mais ce comportement peut être modifé par négociation :

Les connexions persistantes permettent de pipeliner les requêtes aux conditions suivantes :

L'interaction avec les serveurs mandataires doit respecter certaines règles :

Le Langage HTML

C'est un langage permettant de décrire la structure d'un document ainsi que les divers éléments qui le compose. Il s'agit essentiellement de marquer un texte à l'aide de balise dont la sémantique est prédéfinie (d'où son nom HyperText Markup Language). De nombreuses versions de ce langage ont été développées, la dernière étant HTML 4.01. Pour en savoir plus, lisez le cours.