RFC du protocole HTTP : Introduction

1.1 Objectif

L'Hypertext Transfer Protocol (HTTP) est un protocole de niveau application suffisamment léger et rapide, pour la transmission de documents distribués et multimédia à travers un système d'information multi-utilisateurs. HTTP à été utilisé à l'initiative du Word-Wide Web dès 1990. Cette spécification décrit les fonctionnalités le plus souvent rencontrées dans les implémentation "client/serveur HTTP/1.0". Elle est divisée en deux section. Les fonctions usuellement exploitées de HTTP sont décrites dans le corps de ce document. Les autres fonctions, moins utilisées sont listées dans l'annexe D.

Les systèmes d'information pratiques nécessitent des fonctions plus évoluées que la simple récupération de données, parmi lesquelles on trouve la possibilité d'effectuer des recherches, les fonctions de remise à jour, et d'annotation. HTTP permet d'utiliser un ensemble non exhaustif de méthodes pour définir l'objet d'une requête. Il s'appuie essentiellement sur la normalisation des Uniform Resource Identifier (URI) [2], soit sous forme de "site" (URL) [4] ou de noms (URN) [16], pour indiquer l'objet sur lequel porte la méthode. Les messages sont transmis sous une forme similaire à celle de la messagerie électronique (Mail) [7] et des extensions Multipurpose Internet Mail Extensions (MIME) [5]. HTTP est aussi un protocole e communication générique entre des "utilisateurs" et des routeurs/proxies vers d'autres protocoles, tels que SMTP [12], NNTP [11], FTP [14], Gopher [1], et WAIS [8], permettant une accès de base à des ressources hypermédia, et simplifiant l'implémentation d'interfaces utilisateur.

1.2 Terminologie

Cette spécification utilise un certain nombre de termes pour désigner les participants et les objets d'une communication HTTP.

Connexion

Un circuit virtuel s'appuyant sur une couche de transport pour la communication d'information entre deux applications.

Message

L'unité de base d'une communication HTTP, consistant en une séquence structurée d'octets définie à la Section 4 et transmis via la connexion.

Requête

Un message de requête HTTP (défini en Section 5).

Réponse

Un message de réponse HTTP (défini en Section 6).

Ressource

Un service ou objet du réseau pouvant être identifié par une URI (Section 3.2).

Entité

Une représentation particulière de données, ou la réponse d'une ressource de type service, incluse dans une requête ou une réponse. Une entité représente une métainformation sous la forme d'une en-tête et d'un contenu sous la forme d'un corps, ou "body".

Client

Un programme applicatif dont la fonction principale est d'émettre des requêtes.

Utilisateur

Le client qui a émis la requête. Celui-ci peut être un navigateur, un éditeur, un "spiders" (robot d'exploration), ou autre utilitaire.

Utilisateur final

L'utilisateur humain pilotant le programme utilisateur.

Serveur

Un programme applicatif acceptant des connexions dans le but traiter des requêtes en délivrant une réponse.

Serveur origine

Le serveur dans laquelle se situe physiquement une ressource.

Proxy

Un programme intermédiaire qui cumule les fonctions de serveur et de client. Les requêtes sont soit traitées en interne ou répercutées, éventuellement converties, sur d'autres serveurs. Un proxy doit interpréter, puis reconstituer un message avant de le réemettre. Les proxies sont souvent utilisés comme portes d'accès côté utilisateur à des réseaux protégés par un "firewall" ou comme intermédiaire pour convertir des protocoles non supportés par l'utilisateur.

Gateway ou routeur

Un serveur jouant le rôle d'intermédiaire pour d'autres serveurs. Contrairement à un Proxy, un routeur reçoit les requêtes comme s'il était le serveur origine pour la ressource; le client n'étant pas nécessairement conscient de "communiquer" avec un routeur. Les routeurs sont souvent utilisés comme porte d'accès côté serveur d'un réseau protégé par "firewall" et comme convertisseur de protocole pour accéder à es ressources hébergées sur des systèmes non-HTTP.

Tunnel

Un tunnel est un programme applicatif servant de relais "transparent" entre deux connexions. Une fois actif, cet élément n'est plus considéré comme faisant partie de la connexion HTTP, bien qu'il soi issu d'une requête HTTP. Le tunnel cesse d'exister lorsque les deux sens de la connexion ont été fermés. Les tunnels sont utilisés lorsqu'une "porte" est nécessaire et que l'intermédiaire ne peut, ou ne doit pouvoir interpréter la communication.

Cache

Un espace de stockage local destiné à enregistrer les réponses et le sous-système contrôlant ces enregistrements, leur relecture et leur effacement. Un cache enregistre des réponses dans le but de diminuer le temps d'accès et la charge du réseau lors de requêtes identiques ultérieures. Tout client ou serveur peut implémenter un cache, bien que le serveur ne puisse exploiter ce cache, faisant office de tunnel.

Un programme pouvant aussi bien être serveur que client; l'utilisation que nous ferons de ces termes s'appliquera à la situation qu'à le programme vis à vis d'une connexion particulière, plutôt qu'à ses possibilités effectives. De même tout serveur peut être à la fois serveur origine, proxy, routeur, ou tunnel, changeant alors de comportement en fonction des requêtes reçues.

1.3 Fonctionnement global

Le protocole HTTP est basé sur un paradigme requête/réponse. Un client établit une connexion vers un serveur et lui envoie une requête sous la forme d'une méthode, d'une URI, du numéro de version, suivi d'un message de type MIME contenant les modificateurs de la requête, les informations sur le client, et éventuellement un corps. Le serveur répond par une ligne d'état, incluant la version de protocole et un message de succès ou d'erreur, suivi d'un message de type MIME contenant l'information sur le serveur, metainformation, et le corps éventuel.

La plupart des communications HTTP sont initiées par un utilisateur et consistent en une requête devant être appliquée (il s'agit d'une méthode) à une ressource sur son serveur origine. Dans le cas le plus simple, ceci peut être réalisé par une connexion simple (v) entre l'utilisateur (UA) et le serveur origine (O).

       Requête ------------------------>
    UA -------------------v------------------- O
       <----------------------- Réponse

Une situation plus complexe peut apparaître lorsque un ou plusieurs intermédiaires sont présents dans la chaîne de communication. On trouvera trois types d'intermédiaires: les proxy, les routeurs, et les tunnels. Un proxy est un agent actif, recevant les requêtes destinées à une URI dans sa forme absolue, recomposant tout ou partie du message, et réémettant la requête transformée à destination de l'URI. Un serveur est un agent actif, agissant en tant que "surcouche" par rapport à d'autres serveurs et si nécessaire, traduisant le protocole à destination et en provenance du serveur visé. Un tunnel est un agent passif ne servant que de relais entre deux parties d'une même connexion, et de ce fait sans modifier le message; les tunnels sont utilisés lorsque le message doit traverser un intermédiaire (comme un "firewall") même si celui-ci ne peut interpréter le contenu des messages.

Requête -------------------------------------->
    UA -----v----- A -----v----- B -----v----- C -----v----- O
       <------------------------------------- Réponse

La figure ci-dessus montre le cas de trois intermédiaires (A, B, et C) entre l'utilisateur et le serveur origine. Une requête ou réponse passant d'un bout à l'autre doit transiter par quatre connexions. Cette distinction est important car certaines options d'une communication HTTP peuvent ne s'appliquer qu'à la connexion la plus proche, sans même passage par un tunnel, et accessible uniquement des extrémités, ou au contraire à toutes les connexions impliquées dans la chaîne. Bien que ce schéma soit linéaire, chaque participant peut être engagé dans plusieurs communications simultanées. Par exemple, B peut être en train de recevoir de nombreuses requêtes de clients autres que A, et émettre des requêtes vers d'autres serveurs que C, tout en interprétant les requêtes issues de A.

Toute partie de communication n'étant pas un tunnel doit posséder un cache pour le stockage des requêtes. L'intérêt de cette pratique est que la chaîne requête/réponse peut être considérablement raccourcie si l'un des intermédiaires dispose déjà d'une instance de la ressource dans son cache. Le diagramme suivant montre le cas où B dispose dans son cache d'une copie d'une réponse précédemment envoyée par O (via C) et répond à une requête identique de UA (à noter que dans cet exemple, ni UA ni A ne disposent de cette même réponse en cache).

       Requête ---------->
    UA -----v----- A -----v----- B - - - - - - C - - - - - - O
       <--------- Réponse

Toutes les réponses ne peuvent être "cachées", et certaines requêtes peuvent utiliser des modificateurs induisant un comportement particulier du cache. Certaines applications HTTP/1.0 utilisent des heuristiques pour décrire ce qui est ou non "cachable", mais ces règles ne sont pas standardisées.

Sur Internet, les communications HTTP s'appuient principalement sur le protocole de connexion TCP/IP. Le port utilisé par défaut est le port TCP 80 [15], d'autres ports pouvant être utilisés. Ceci n'exclut pas que HTTP puisse être implémenté au dessus d'un autre protocole d'Internet, ou sur d'autres types de réseau. HTTP nécessite seulement un transport fiabilisé; tout protocole garantissant la sécurité de transmission peut être utilisé pour supporter HTTP, la place qu'occupent les données des requêtes et réponses HTTP/1.0 dans les unités de transmission de ces protocoles restant en dehors du contexte de ce document.

Excepté pour des applications expérimentales, la pratique courante spécifie qu'une connexion doit être initiée par un client avant transmission de la requête, et refermée par le serveur après délivrance de la réponse. Les deux côtés, client et serveur, doivent être préparés à ce que la connexion soit coupée prématurément, suite à une action de l'utilisateur, une temporisation automatique, ou une faute logicielle, et doivent apporter une réponse prévisible à cette situation. Dans tous les cas, la fermeture d'une connexion qu'elle qu'en soit la raison est assimilable à la conclusion de la requête, quel que soit l'état.

1.4 HTTP et MIME

HTTP/1.0 exploite un grand nombre d'implémentation prévues pour les MIME, tels que définis dans la RFC 1521 [5]. L'appendice C décrit comment HTTP l'utilisation des "Internet Media Types" typiquement utilisés par la messagerie électronique, et indique les différences de comportement.