Architecture des échanges de données sur le web

Les webmestres et chefs de projet web doivent souvent arbitrer entre diverses solutions techniques. Ils doivent établir des cahiers des charges pour des réalisations de logiciels externalisés et pour l'hébergement de leurs sites. Ce cours vise à présenter les principaux critères techniques de choix. Il présente ensuite les principales données techniques de l'hébergement web qui permettent d'effectuer certains choix stratégiques dans la conception éditoriale d'un site web.

Les connaissances et compétences suivantes sont prérequises pour ce cours.

Ce document n'est qu'un support de cours, il ne prétend pas être autonome. Le cours correspondant est délivré dans le cadre du mastère Web éditorial de l'Université de Poitiers. Ce document a été conçu au format DocBook pour être consulté sous forme de pages web (XHTML, cette version) ou sous forme imprimée (PDF, cette version).

Ce document, destiné aux étudiants du mastère Web éditorial de l'Université de Poitiers, est mis à disposition de tous. Son usage est gratuit dans le cas de formations délivrées par un organisme à but non lucratif (institution gouvernementale, association). En cas de formation dans un cadre à but lucratif ou pour tout autre usage, prendre contact avec l'auteur ou ses ayant-droits.

© 2002-2007, Yannis Delmas , reproduction, adaptation et traduction réservées.

Les requêtes et les réponses HTTP ont toutes deux la même forme générale : une série de méta-informations envoyées en entête suivie d'un corps de message. Dans le cas des réponses, le corps de message est le document transmis lui-même, éventuellement encodé. Pour avoir une idée de l'en-tête de requête envoyé par un client à un serveur on peut utiliser le petit code PHP suivant :

foreach(apache_request_headers() as $nom => $valeur) {
    echo "$nom:\t$valeur\n";
}

Pour connaître l'en-tête de réponse renvoyé par un serveur pour une page donnée, le plus simple est d'utiliser l'extension « web developper » de Firefox et de sélectionner dans le menu : « information > view response headers ».

Voici un exemple d'en-tête et un exemple de réponse HTTP, que nous allons ensuite analyser, point par point, pour ce qui concerne un chef de projet web.

Exemple (fictif) d'entête de requête HTTP :

GET /cours_prog_web/test-entete.php?a=b&c=d+e HTTP/1.1
Host: yannis.delmas-rigoutsos.nom.fr
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20061201 Firefox/2.0.0.8 (Ubuntu-feisty)
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Charset: UTF-8,*
Accept-Encoding: gzip,deflate
Accept-Language: fr,fr-fr;q=0.9,en;q=0.8,en-us;q=0.6,el;q=0.5,de;q=0.4,it;q=0.3,nl;q=0.1
Connection: keep-alive
Keep-Alive: 300
Cookie: session=2348f5a1c0b11ddcb3250fc7c10f0944
Referer: http://yannis.delmas-rigoutsos.nom.fr/documents/index.html

Exemple (fictif) d'entête de réponse HTTP :

HTTP/1.1 200 OK
Date: Thu, 22 Nov 2007 12:35:27 GMT
Server: Apache
Connection: Keep-Alive
Keep-Alive: timeout=15, max=100
Content-Type: text/html; encoding=UTF-8
Content-Encoding: gzip
Content-Length: 11222
X-Powered-By: PHP/5.1.6-1
Set-Cookie: session=2348f5a1c0b11ddcb3250fc7c10f0944

Le protocole du web [RFC2616] définit trois principales méthodes de requêtes HTTP, c'est à dire trois principaux types de requêtes HTTP. Ces requêtes permettent aux logiciels clients web (généralement des navigateurs) de commander des opérations aux logiciels serveurs web.

La méthode la plus courante est la méthode GET. Elle demande simplement à récupérer le contenu associé à une URI. Les données transmises sont dans l'URI même. Les autres informations de la requête ne sont donc que les cookies et la configuration du client. Comme on le voit sur l'exemple ci-dessus, l'URI est décomposée : d'une part le serveur (si le port était indiqué, il serait à la suite dans la ligne Host), d'autre part la suite de l'URI.

La méthode POST sert principalement pour les formulaires. En effet l'URI est peu commode pour transmettre des informations nombreuses et/ou volumineuses : tous les clients et serveurs ne supportent pas des URI trop longues et, surtout, cela peut gêner l'utilisateur, s'il souhaite se repérer ou enregistrer la page. En revanche, les informations envoyées par la méthode POST en dehors de l'URI ne seront pas enregistrées dans un signet. La méthode POST envoie les données en les plaçant dans le corps de la requête HTTP, à la suite de l'entête.

La troisième méthode usuelle, HEAD, n'est pas directement accessible aux utilisateurs. Fonctionnellement, il s'agit d'une version de la requête GET qui doit engendrer les mêmes types de traitements, hormis la production du document lui-même. Le serveur se contentera donc de renvoyer un entête de réponse, sans contenu. Ceci permet aux caches et proxies, notamment, de tester la présence, la date et le type des documents, plus généralement, de recevoir toutes les méta-informations les concernant.

Ces trois méthodes fournissent l'essentiel des méthodes utilisées par le web. Il en existe toutefois d'autres, notamment une extension du protocole HTTP, appelée WebDAV (Web-based Distributed Authoring and Versioning) ou DAV permettant d'utiliser HTTP pour servir des fichiers, en lecture et écriture. La grande nouveauté de ce système, qui a vocation à supplanter un jour le FTP, est de garder trace de versions successives d'un document et, à terme, de permettre le travail simultané de plusieurs utilisateurs sur un même document. Aujourd'hui, malgré les affirmation des éditeurs la plupart des principales plateformes DAV ne sont pas encore irréprochables. DAV est très bien adapté au stockage de documents pour un environnement numérique de travail (il est en place, par exemple, sur l'ENT de l'Université de Poitiers).

Accept-Language: fr,fr-fr;q=0.9,en;q=0.8,en-us;q=0.6,el;q=0.5,de;q=0.4,it;q=0.3,nl;q=0.1

Le premier élément d'entête auquel nous nous intéresseront est la langue. On voit, dans l'exemple de requête ci-dessus, que les navigateur transmettent systématiquement aux serveurs la liste des langues indiquées par l'utilisateur dans la configuration du navigateur par ordre décroissant de préférence (pour Firefox 2 : édition > préférences > avancées > général > langues).

Ceci veut dire que les serveurs web peuvent utiliser cette indication pour s'adapter aux préférences de l'utilisateur, pour les pages statiques comme pour les pages produites dynamiquement.

Il est extrêment décevant de voir que cette fonctionnalité très simple à mettre en oeuvre et source d'un grand confort pour l'utilisateur est encore fort peu utilisée par les éditeurs de sites web, qui laissent le “soin” à l'utilisateur de cliquer sur un icone de langue, dans le meilleur des cas (mais plus souvent un icone de pays, ce qui est parfois gênant). On comparera avec le grand confort proposé, par exemple, par Google, qui offre une interface dans la langue préférée, quel que soit le pays ciblé (p.ex. sur www.google.gr).

Quand on utilise le serveur web Apache l'aiguillage linguistique automatique est extrêmement simple à mettre en oeuvre. Par exemple, si les pages index.html.en et index.html.fr existent, l'une de ces deux pages sera fournie au client quand il demandera index.html (à condition qu'il n'existe pas de fichier portant ce nom, bien entendu).

Ceci veut également dire qu'il est possible (et même simple) de faire des statistiques pour suivre la langue principale des visiteurs d'un site. Ceci peut être extrêmement instructif quand il s'agit de décider dans quelles langues doit être édité le site. Pour une étude plus fine il est, toutefois, conseillé de s'appuyer également sur des statistiques géographiques (cf. infra).

Accept-Charset: UTF-8,*

Pour que le contenu textuel d'une page soit lisible, il est essentiel qu'il soit établi dans un jeu de caractères lisible sur l'ordinateur des visiteurs. Ceci demande le concours de plusieurs éléments.

Le respect des encodages est absolument essentiel quand il s'agit de pages mettant en oeuvre une application, web, en particulier les WCMS. En effet, si l'encodage de la page n'est pas parfait, l'envoi des données de formulaire, donc également les données ensuite sauvegardées dans l'application risque d'être incorrect.

Accept: text/xml,application/xml,application/xhtml+xml,text/html,text/plain,image/png,*/*
Accept: image/gif, image/x-xbitmap, image/jpeg, application/x-shockwave-flash, */*

Autre type d'encodage, celui du document : dans quel format est-il composé ? Là encore le navigateur doit commencer par indiquer les formats qu'il est capable de comprendre. Les format compris sont mis sous la forme de types MIME. Dans le premier exemple ci-dessus, le client indique qu'il comprend XML, XHTML, HTML, le texte brut, les images PNG et qu'il essaiera de se debrouiller pour tout autre format. En pratique les formats textuels sont souvent sous-entendus, comme dans le second exemple, et le navigateur précise seulement des formats d'images. Internet explorer indique parfois aussi, quand la suite MSOffice est installée, les types application/vnd.ms-powerpoint, application/vnd.ms-excel et application/msword.

Content-Type: text/html; encoding=UTF-8
Content-Type: text/html

Toute réponse HTTP comprend, au minimum, l'indication du format de son contenu. Le plus souvent les serveurs web déterminent le format d'un fichier statique en observant son extension (.html, .png etc.). Pour cette raison, il est absolument essentiel que cette extension soit correcte, sinon l'affichage sur le navigateur a toute chance d'être désastreux. Quand il s'agit d'un document textuel, l'encodage des caractères est parfois précisé, comme dans le premier exemple ci-dessus.

Accept-Encoding: gzip,deflate

Observons enfin dans l'entête de requête l'indication Accept-Encoding. Il ne s'agit plus là du codage d'un document à proprement parler mais de l'encodage de la transmission du document. Dans cet exemple le navigateur indique qu'il comprend les encodage gzip et deflate, qui sont deux algorithmes de compression de données (le premier est surtout utilisé sous Unix et le second est utilisé par le format populaire ZIP), en plus de la transmission simple qui consiste envoyer le fichier tel quel. Quand il le peut le serveur utilise ces possibilités de compression pour réduire sa bande passante de sortie (au prix d'une charge de calcul, bien sûr). Ceci permet parfois de gagner aussi en rapidité, quand le temps de compression/décompression est inférieur au gain de temps de transmission (surtout utiles pour les gros fichiers qui se compressent bien et les connexions bas-débit). Bien entendu, le fichier est décompressé à l'arrivé par le navigateur pour être affiché correctement à l'utilisateur.

Outre les données de configuration, le client transmet au serveur des informations qu'il stocke de façon plus ou moins permanente : les cookies [biscuits].

Le web étant mise en oeuvre au moyen d'un protocole purement client-serveur utilisant des requêtes séparées les unes des autres : il ne permet pas, en soi, le travail suivi sur un ensemble de données au sein d'une application, ce qu'on appelle une session de travail. Il y a deux moyens de contourner cet écueil : Le premier est de passer comme un relais, de page en page, les informations pertinentes sous la forme de champs de formulaire (éventuellement cachés). Une variante consiste à réécrire toutes les URI internes de la page pour leur ajouter des informations à retransmettre au serveur à la prochaine demande de page. Ces méthodes sont assez efficaces tant que les données sont peu nombreuses et qu'il n'est pas nécessaire de prolonger la session de travail au-delà d'une succession de pages qui s'enchaîne. Elle ne permet pas, en revanche, de personnaliser l'interface ou l'accès à un site, de façon plus permanente. Le second moyen consiste à stocker des informations dans le client et à les renvoyer systématiquement au serveur dans certaines conditions. C'est le principe des cookies, définis par Netscape en 1996.

Un cookie peut être considéré comme la donnée des informations suivantes (toutes facultatives, sauf le contenu) :

Le point important, concernant les cookies, est qu'il sont définis et renvoyés dans les entête des requètes et réponses HTTP. En conséquence, quand un cookie est proposé par un serveur à un client, celui-ci ne sera disponible que pour les requêtes suivantes. Concrètement, les opérations se déroulent ainsi :

Pour observer les cookies envoyé à un navigateur on peut configurer ce dernier pour qu'il signale chaque demande de cookie (tous les navigateurs ne le permettent pas - ceci est vite pénible tant les cookies sont nombreux). Avec Firefox, il est possible d'installer l'extension « view cookies » qui liste tous les cookies concernés par une page donnée (menu « informations sur la page », onglet « cookies »).

Les premiers sites de vente en ligne ont pu utiliser des cookies pour stocker le panier d'un visiteur, toutefois, la méthode a très vite montré ses limites avec l'augmentation du nombre de produits disponibles. Pour implémenter réellement une session de travail d'application web, une méthode plus élaborée s'est vite imposée : le suivi de session. Il consiste à mettre en place le pendant des cookies du côté des serveurs web, sous la forme d'objets appelés sessions. Une telle “session” n'est guère plus qu'un fichier ou un jeu d'enregistrements associés à un utilisateur le temps de sa session de travail sur une application web. Comme ce fichier stocke généralement la quasi-totalité des informations nécessaire, il n'est plus nécessaire de mettre dans les cookies de l'utilisateur qu'un numéro de session. Ce mécanisme est, aujourd'hui, totalement automatisé dans PHP, ce qui permet aux programmeurs d'utiliser des sessions sans s'inquiéter de gérer le fichier de session ou le cookie enregistrant le numéro de session.

Le deuxième type d'usage des cookies est d'enregistrer les préférences de l'utilisateur pour un site donné (observer, par exemple, les cookies de Google et, en particulier, leur évolution quand on visite la page « préférences »). Jusqu'au début des années 2000, ceci était généralement suffisant. Toutefois, depuis, l'usage de la personnalisation des sites s'est considérablement développé, du moins pour les sites les plus dynamiques. Un cookie n'est plus, dans ce cas, suffisant pour stocker toutes les données qui concernent un utilisateur. Sur ces sites, ce qui concerne un utilisateur donné doit être placé dans une base de données : ces sites tendent de plus en plus, dans leurs technologies, à se rapprocher de véritables environnements numériques de travail. Les sites de vente en ligne les plus élaborés relient bien entendu ces données à un logiciel de gestion de la relation client (GRC) : les achats précédents ou les pages lues fournissent de précieuses indications sur les goûts et les intérêts d'un prospect, qui permettent même, à l'idéal, de lui faire des suggestions d'achats.

Pour n'importe quel site web d'ampleur, il est essentiel de bien connaître ses usagers. Un premier niveau consiste à pister anonymement ses visiteurs, en observant les pages (ou suites de pages) visitées. Un simple cookie de session suffit pour cela (au minimum pour ne pas lui asséner dix fois la même publicité). Le niveau suivant consiste à établir des profils de consultation, idéalement en relation avec un logiciel de GRC, et à s'adapter à ces profils (connaître le client est bien, le satisfaire est mieux). L'évolution actuelle est celle de la personnalisation. Le degré le plus simple de personnalisation, passif, est de permettre à l'utilisateur de personnaliser ses service, en particulier de mettre au premier plan ceux qu'il utilise le plus volontiers. Mais il peut également s'agir de méthodes actives de suggestion de services. Par exemple (Amazon), on pourra observer que de nombreux lecteurs de tel ouvrage ont également acheté tel autre ; une méthode active consiste alors à proposer un avertissement, une page, un e-mail, etc. de suggestions d'achat. Ces méthodes révolutionnent aujourd'hui le commerce culturel en donnant accès au plus grand nombre à des ouvrages d'audience restreinte. Elles augmentent ainsi considérablement le maché potentiel de ces produits ; c'est le phénomène de « longue traîne » [long tail], en partie au détriment de la vente de masse (cf. cours. E. Leguay).

Pour administrer les contenus d'un site, il est absolument essentiel d'en connaître les visiteurs. Quand ceux-ci sont nombreux, ceci passe nécessairement par l'utilisation d'outils statistiques.

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20061201 Firefox/2.0.0.8 (Ubuntu-feisty)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1) Gecko/20061010 Firefox/2.0
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)

Les moteurs de recherche ne sont pas que des outils aux mains des internautes. Il peuvent fournir également des outils extrêmement efficaces à l'éditeur d'un site web.

L'outil le plus simple à disposition consiste à utiliser comme outil de recherche “interne” à son site un grand moteur de recherche. Ceci permet d'une part de profiter de la puissance de ces moteurs et, d'autre part, de vérifier concrètement que l'infrastructure technique du site est compatible avec ce moteur. Cette technologie n'est pas forcément indiquée dans les cas où le site comporte des parties confidentielles mais est bien adaptée aux sites entièrement ouverts au public.

Le deuxième type d'outil consiste à décrire son site d'une manière efficace pour les “araignées” des moteurs de recherche. Le minimum est de disposer d'un fichier décrivant l'accès à ces robots. Pour les sites vivants, il est aujourd'hui impératif de disposer d'un ou plusieurs fils RSS^[1] décrivant les nouveautés du site. Ceci est, bien sûr, utile aux robots mais permet surtout aux visiteurs de s'abonner à ces nouveautés et à des sites “amis” d'afficher ces nouveautés sous forme de liens afférents. Enfin, l'idéal est de disposer d'une carte de site, décrivant l'ensemble du site pour les robots.

Le troisième type d'outil est beaucoup plus élaboré et s'obtient généralement sous la forme d'une prestation d'une société d'analyse statistique. Il consiste à analyser les mots-clefs utilisés par les visiteurs qui sont arrivés sur le site en provenance d'un moteur de recherche. En effet, les éléments de recherche sont dans l'URI de la page de réponse, donc disponibles dans la donnée Referer de l'entête de requête HTTP.

Le dernier élément sur lequel nous voulons insister est la persistance des URL. Du fait que le web comporte de très nombreuses pages dont le contenu n'est pas, ou pas souvent, remis à jour, il résulte une inertie considérable des URL, dans les signets, dans le web... et par conséquent dans les moteurs de recherche. Pour prendre un exemple parlant continue, à ce jour, à recevoir des notifications d'erreur pour une adresse utilisée pendant une ou deux semaines en 1994 ou 1995.

Tout éditeur de site web doit bien avoir toujours présent à l'esprit ce fait. Il est donc impératif que toute URL qui amène à un site un nombre non négligeable de visiteurs garde reste “active”. Cela signifie que le contenu doit y être maintenu. Si cela venait, un jour à ne plus être souhaitable ou pertinent, il est impératif, alors, de mettre en place une redirection, c'est à dire un dispositif renvoyant les visiteurs de l'URL en question vers une autre adresse, publiant un contenu à jour et pertinent. De telles redirections peuvent être mises en place à titre temporaire ou définitif, selon le besoin. Une redirection définitive demande aux navigateurs de mettre à jour leurs signets automatiquement.

Ces redirections sont également utilisées par les moteurs de recherche. En effet, une notoriété importante d'une URL sur un moteur de recherche fait partie du patrimoine d'un éditeur. Cela constitue même une part très importante de l'actif de certaines sociétés. Il est absolument essentiel de le préserver.

Signalons enfin que quand un même contenu est accessible au moyen de plusieurs URL, il est important que toutes ces URL sauf une soient des redirections, de façon à ne pas “diluer” la notoriété auprès des moteurs de recherche. Une notoriété divisée par deux, par exemple, peut ainsi envoyer de la première page aux oubliettes, même si les robots des moteurs de recherche développent des stratégies d'identification des doublons.