1. Introduction
1.1 Purpose (Objectif)
Le protocole de transfert hypertexte (Hypertext Transfer Protocol, HTTP) est un protocole au niveau application pour les systèmes d'information distribués, collaboratifs et hypermédias. HTTP est utilisé par l'initiative d'information mondiale du World-Wide Web depuis 1990. La première version de HTTP, appelée HTTP/0.9, était un protocole simple pour le transfert de données brutes à travers Internet. HTTP/1.0, défini dans RFC 1945 [6], a amélioré le protocole en permettant aux messages d'adopter un format de type MIME, contenant des métadonnées sur les données transférées et des modificateurs pour la sémantique requête/réponse. Cependant, HTTP/1.0 n'a pas suffisamment pris en compte les effets des proxies hiérarchiques, de la mise en cache, de la nécessité de connexions persistantes ou des hôtes virtuels. De plus, de nombreuses applications avec des implémentations incomplètes se déclaraient « HTTP/1.0 », rendant nécessaire un changement de version du protocole afin que deux applications communicantes puissent déterminer les capacités réelles l'une de l'autre.
Cette spécification définit le protocole appelé « HTTP/1.1 ». Ce protocole inclut des exigences plus strictes que HTTP/1.0 afin d'assurer une implémentation fiable de ses fonctionnalités.
Les systèmes d'information pratiques nécessitent plus de fonctionnalités que la simple récupération, notamment la recherche, les mises à jour frontales et l'annotation. HTTP permet un ensemble ouvert de méthodes et de champs d'en-tête pour indiquer le but d'une requête [47]. Il s'appuie sur la spécification de référence fournie par l'Identificateur de Ressource Uniforme (Uniform Resource Identifier, URI) [3], en tant que localisation (URL) [4] ou nom (URN) [20], pour indiquer la ressource à laquelle la méthode doit être appliquée. Les messages sont transmis dans un format similaire à celui utilisé par le courrier Internet [9], tel que défini par les Extensions Multiusages du Courrier Internet (Multipurpose Internet Mail Extensions, MIME) [7].
HTTP est également utilisé comme protocole générique pour la communication entre agents utilisateurs et proxies/passerelles vers d'autres systèmes Internet, notamment ceux supportés par les protocoles SMTP [16], NNTP [13], FTP [18], Gopher [2] et WAIS [10]. De cette manière, HTTP permet un accès hypermédia basique aux ressources disponibles provenant de diverses applications.
1.2 Requirements (Exigences)
Les mots-clés « MUST », « MUST NOT », « REQUIRED », « SHALL », « SHALL NOT », « SHOULD », « SHOULD NOT », « RECOMMENDED », « MAY » et « OPTIONAL » dans ce document doivent être interprétés comme décrit dans RFC 2119 [34].
Une implémentation n'est pas conforme si elle ne satisfait pas une ou plusieurs des exigences de niveau MUST ou REQUIRED du protocole qu'elle implémente. Une implémentation qui satisfait toutes les exigences de niveau MUST ou REQUIRED ainsi que toutes les exigences de niveau SHOULD de son protocole est dite « inconditionnellement conforme » (unconditionally compliant). Une implémentation qui satisfait toutes les exigences de niveau MUST mais ne satisfait pas toutes les exigences de niveau SHOULD de son protocole est dite « conditionnellement conforme » (conditionally compliant).
1.3 Terminology (Terminologie)
Cette spécification utilise de nombreux termes pour désigner les rôles joués par les participants et les objets dans la communication HTTP.
connection (connexion) Un circuit virtuel de couche transport établi entre deux programmes à des fins de communication.
message (message) L'unité de base de la communication HTTP, constituée d'une séquence structurée d'octets conforme à la syntaxe définie dans la section 4 et transmise via une connexion.
request (requête) Un message de requête HTTP, tel que défini dans la section 5.
response (réponse) Un message de réponse HTTP, tel que défini dans la section 6.
resource (ressource) Un objet de données réseau ou un service qui peut être identifié par un URI, comme défini dans la section 3.2. Les ressources peuvent être disponibles sous plusieurs représentations (par exemple, plusieurs langues, formats de données, tailles et résolutions) ou varier d'autres manières.
entity (entité) Les informations transférées en tant que charge utile d'une requête ou d'une réponse. Une entité se compose de métadonnées sous forme de champs d'en-tête d'entité et de contenu sous forme de corps d'entité, comme décrit dans la section 7.
representation (représentation) Une entité incluse dans une réponse soumise à la négociation de contenu, comme décrit dans la section 12. Il peut y avoir plusieurs représentations associées à un état de réponse particulier.
content negotiation (négociation de contenu) Le mécanisme de sélection de la représentation appropriée lors du service d'une requête, comme décrit dans la section 12. La représentation des entités dans toute réponse peut être négociée (y compris les réponses d'erreur).
variant (variante) Une ressource peut avoir une ou plusieurs représentations associées à un moment donné. Chacune de ces représentations est appelée une « variante » (variant). L'utilisation du terme « variante » n'implique pas nécessairement que la ressource est soumise à la négociation de contenu.
client (client) Un programme qui établit une connexion dans le but d'envoyer des requêtes.
user agent (agent utilisateur) Le client qui initie une requête. Il s'agit généralement de navigateurs, d'éditeurs, de robots d'exploration Web (web-traversing robots) ou d'autres outils pour utilisateurs finaux.
server (serveur) Une application qui accepte des connexions afin de servir des requêtes en envoyant des réponses. Tout programme donné peut être à la fois client et serveur. Notre utilisation de ces termes fait référence uniquement au rôle exécuté par le programme pour une connexion particulière, plutôt qu'aux capacités générales du programme. De même, tout serveur peut agir en tant que serveur d'origine, proxy, passerelle ou tunnel, en changeant de comportement en fonction de la nature de chaque requête.
origin server (serveur d'origine) Le serveur sur lequel une ressource donnée réside ou doit être créée.
proxy (proxy) Un programme intermédiaire qui agit à la fois comme serveur et comme client dans le but de faire des requêtes au nom d'autres clients. Les requêtes sont traitées en interne ou transmises, avec une traduction possible, à d'autres serveurs. Un proxy doit (MUST) implémenter à la fois les exigences client et serveur de cette spécification. Un « proxy transparent » (transparent proxy) est un proxy qui ne modifie pas la requête ou la réponse au-delà de ce qui est requis pour l'authentification et l'identification du proxy. Un « proxy non transparent » (non-transparent proxy) est un proxy qui modifie la requête ou la réponse afin de fournir certains services supplémentaires à l'agent utilisateur, tels qu'un service d'annotation de groupe, une conversion de type de média, une réduction de protocole ou un filtrage d'anonymat. Sauf indication explicite d'un comportement transparent ou non transparent, les exigences du proxy HTTP s'appliquent aux deux types de proxies.
gateway (passerelle) Un serveur qui agit comme intermédiaire pour un autre serveur. Contrairement à un proxy, une passerelle reçoit les requêtes comme si elle était le serveur d'origine de la ressource demandée. Le client demandeur peut ne pas être conscient qu'il communique avec une passerelle.
tunnel (tunnel) Un programme intermédiaire qui agit comme un relais aveugle entre deux connexions. Une fois activé, un tunnel n'est pas considéré comme partie prenante à la communication HTTP, bien qu'un tunnel puisse avoir été initié par une requête HTTP. Le tunnel cesse d'exister lorsque les deux extrémités des connexions relayées sont fermées.
cache (cache) Le stockage local des messages de réponse d'un programme et le sous-système qui contrôle le stockage, la récupération et la suppression de ses messages. Un cache stocke les réponses pouvant être mises en cache afin de réduire le temps de réponse et la consommation de bande passante réseau pour les requêtes équivalentes futures. Tout client ou serveur peut inclure un cache, bien qu'un serveur agissant comme tunnel ne puisse pas utiliser de cache.
cacheable (pouvant être mis en cache) Une réponse peut être mise en cache si un cache est autorisé à stocker une copie du message de réponse pour l'utiliser afin de répondre à des requêtes ultérieures. Les règles pour déterminer si une réponse HTTP peut être mise en cache sont définies dans la section 13. Même si une ressource peut être mise en cache, il peut y avoir des contraintes supplémentaires sur le fait qu'un cache particulier doive la mettre en cache.
first-hand (première main) Une réponse est de première main si elle provient du serveur d'origine, éventuellement via un ou plusieurs proxies. Une réponse est également de première main si sa validité a été vérifiée directement avec le serveur d'origine.
explicit expiration time (temps d'expiration explicite) Le moment où le serveur d'origine a l'intention qu'une entité ne soit plus retournée par un cache sans validation supplémentaire.
heuristic expiration time (temps d'expiration heuristique) Un temps d'expiration attribué par un cache en l'absence d'un temps d'expiration explicite.
age (âge) L'âge d'une réponse est le temps écoulé depuis que le serveur d'origine a envoyé la réponse (ou validé avec succès la réponse).
freshness lifetime (durée de fraîcheur) La durée entre la génération d'une réponse et son temps d'expiration.
fresh (frais) Une réponse est fraîche si son âge n'a pas encore dépassé sa durée de fraîcheur.
stale (périmé) Une réponse est périmée si son âge a dépassé sa durée de fraîcheur.
semantically transparent (sémantiquement transparent) Un cache se comporte de manière sémantiquement transparente lorsque son utilisation n'affecte ni le client demandeur ni le serveur d'origine, sauf pour améliorer les performances. Lorsqu'un cache fonctionne de manière sémantiquement transparente, le client reçoit exactement la même réponse (sauf pour les champs d'en-tête saut par saut) qu'il aurait reçue si elle avait été envoyée directement depuis le serveur d'origine, et le cache n'affecte pas le traitement des requêtes ultérieures.
validator (validateur) Un élément de protocole (par exemple, une étiquette d'entité ou un temps Last-Modified) utilisé pour déterminer si une entrée de cache est une copie équivalente d'une entité.
upstream/downstream (amont/aval) Amont et aval décrivent le flux des messages : tous les messages circulent de l'amont vers l'aval.
inbound/outbound (entrant/sortant) Entrant et sortant se réfèrent aux chemins de requête et de réponse par rapport à la requête : « entrant » signifie « vers le serveur d'origine », et « sortant » signifie « vers l'agent utilisateur ».
1.4 Overall Operation (Fonctionnement Général)
Le protocole HTTP est un protocole requête/réponse. Un client envoie une requête à un serveur sous forme de méthode de requête, d'URI et de version de protocole, suivis d'un message de type MIME contenant des modificateurs de requête, des informations sur le client et éventuellement du contenu de corps, transmis via une connexion. Le serveur répond par une ligne d'état, incluant la version du protocole du message et un code de succès ou d'erreur, suivis d'un message de type MIME contenant des informations sur le serveur, des métadonnées d'entité et éventuellement du contenu de corps d'entité. La plupart des communications HTTP sont initiées par un agent utilisateur et consistent en une requête pour une ressource sur un serveur d'origine. Dans le cas le plus simple, cela peut être accompli via une seule connexion (v) entre l'agent utilisateur (UA) et le serveur d'origine (O).
request chain ------------------------>
UA -------------------v------------------- O
<----------------------- response chain
Une situation plus complexe se produit lorsqu'un ou plusieurs intermédiaires sont présents dans la chaîne requête/réponse. Il existe trois formes courantes d'intermédiaires : proxy, passerelle et tunnel. Un proxy est un agent de transfert qui reçoit des requêtes pour un URI sous sa forme absolue, réécrit tout ou partie du message et transmet la requête reformatée vers le serveur identifié par l'URI. Une passerelle est un agent récepteur qui agit comme une couche au-dessus d'un autre serveur et, si nécessaire, peut traduire les requêtes vers le protocole du serveur sous-jacent. Un tunnel agit comme un point de relais entre deux connexions sans modifier les messages. Les tunnels sont utilisés lorsque la communication doit passer par un intermédiaire (tel qu'un pare-feu), même si l'intermédiaire ne peut pas comprendre le contenu des messages.
request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------- response chain
La figure ci-dessus montre trois intermédiaires (A, B et C) entre l'agent utilisateur et le serveur d'origine. Un message traversant l'ensemble de la chaîne requête/réponse utilise le mécanisme de passage des options de communication HTTP pour déterminer les paramètres de la connexion.
Toute partie qui n'agit pas comme un tunnel peut utiliser un cache pour satisfaire les requêtes. L'effet d'un cache sur la chaîne requête/réponse dépend des exigences de mise en cache des différents caches le long de la chaîne qui peuvent intercepter la requête ou la réponse. Le comportement de mise en cache et les réponses pouvant être mises en cache sont définis dans la section 13.
En pratique, il existe diverses configurations de modèles architecturaux sur Internet et au sein des organisations. Par exemple, un « fournisseur d'accès national » utilise généralement de grands caches proxy afin que plusieurs agents utilisateurs puissent accéder aux serveurs d'origine via la même chaîne de requêtes. Une autre configuration courante est le cache « proxy inverse », qui se trouve sous le nom d'hôte d'une organisation mais est contrôlé par ses clients ou par un tiers. Les caches de proxy inverse sont transparents pour les agents utilisateurs mais sont souvent gérés par les fournisseurs de réseau pour économiser le trafic traversant le réseau.
La communication HTTP se produit généralement sur des connexions TCP/IP. Le port par défaut est TCP 80 [19], mais d'autres ports peuvent également être utilisés. Cela n'empêche pas l'implémentation de HTTP sur d'autres protocoles sur Internet ou sur d'autres réseaux. HTTP suppose seulement un transport fiable. Tout protocole fournissant de telles garanties peut être utilisé. Le mappage des structures de requête et de réponse HTTP/1.1 sur les unités de données d'un protocole de transport donné est hors du champ de cette spécification.
Dans HTTP/1.0, la plupart des implémentations fermaient la connexion après chaque échange requête/réponse. Dans HTTP/1.1, un mécanisme permet d'utiliser la même connexion pour plusieurs échanges requête/réponse, comme décrit dans la section 8.1, en utilisant des « connexions persistantes » (persistent connections).