Pseudo-Weblog

HTTP, le retour.

Un peu de terminologie, histoire de se retrouver plus tard en terrain connu. Cela paraît toujours assez rébarbatif, mais, d'expérience, il est primordial que les mots soient "bien" compris. La liste qui suit est une traduction approximative et commentée de la RFC 2616, section 1.3..

Connection

Un circuit virtuel au niveau de la couche de transport entre deux programmes, établi dans le but de communiquer. En général, une connection TCP entre deux machines.

Message

L'unité de base d'une communication HTTP, constituée d'une séquence d'octets structuré, en conformance avec les règles de la RFC 2616, chapitre 4, et transmise par la connection.

Requête

Un message de requête, comme défini par la RFC 2616, chapitre 5.

Réponse

Un message de réponse, comme défini par la RFC 2616, chapitre 5.

Resource

Un objet ou un service pouvant être identifié par une URI, comme défini par la RFC 2616, chapitre 3.2. Certaines resources peuvent avoir de multiples représentations (plusieurs langages, formats de donnée, taille, résolution), ou peuvent varier selon d'autres critères (voir ci-dessous).

Entité

L'information transmise en tant que "données utiles" d'une requête ou d'une réponse. Une entité est la somme des méta-données transmises sous forme d'en-têtes et du contenu, transmis sous la forme d'un corps d'entité ainsi que défini par la RFC 2616, Section 7.

Représentation

Une entité inclue dans une réponse sujette à la négociation de contenu, ainsi que décrit dans la RFC 2616, Section 12. Il est possible d'obtenir plusieurs représentations associées à un status particulier de la réponse.

Négociation de contenu

Le mécanisme permettant de sélectionner la représentation lors du traitement d'une requête, comme défini dans la RFC 2616, section 12. La représentation des entités de toute réponse peut être negociée, ceci est valable aussi pour les réponses d'erreur.

Variante

Une resource peut avoir une ou plusieurs représentations à chaque instant. Chaque représentation est appellée "Variante". L'utilisation de ce mot n'implique pas que la resource est sujette à la négociation de contenu.

Client

Un programme créant une connection dans le but d'envoyer des requêtes.

Agent utilisateur

Le client à l'origine de la requête. Le plus souvent, un navigateur, éditeur ou araignée.

Serveur

Programme applicatif acceptant des connections dans le but de traîter les requêtes et de renvoyer les réponses. N'importe quel programme peut à la fois agir en tant que client, ou serveur. L'utilisation de ces qualificatifs ne se rapporte qu'au rôle du programme pour une connection donnée plutôt qu'à toutes ses possibilités. Ainsi, un serveur peut agir en tant que serveur originel, proxy, passerelle, tunnel et changer de comportement suivant la nature de chaque requête.

Serveur originel

Le serveur hébergeant une resource ou une future resource.

Proxy

Un intermédiaire agissant en tant que client et serveur, ayant pour but d'envoyer des requêtes en lieu et place d'autres clients. Les requêtes peuvent être traitées par le Proxy, ou en les propageant, après une possible traduction, à d'autres serveurs. Il est a noter que le groupe de travail WREC a produit une terminologie complète des intermédiares.

La liste n'est pas encore complète, je vais surement en faire un document séparé.

Les notions de variante et négociation de contenu font référence au concept de resource. Aux debuts du Web, les resources etaient des documents statiques et l'association "document" <-> "URI" est une simplification encore trè répandue. De même, l'architecture de la plupart des serveurs Web ne tient pas compte de ce qu'est une resource, ou une URI. Au lieu d'agir en tant que serveurs d'URI, ils agissent en tant que programme effectuant une action générique, avec pour paramètres des en-têtes, et un bout d'URI. Une manière pratique et rapide, mais hélas eloignée du concept de resource, et qui modifie la granularité du comportement de l'URI au serveur (à ne pas confondre avec l'hôte, car un serveur peut héberger plusieurs hôtes).

à suivre...