3. Terminology and Core Concepts (Terminologie et concepts de base)
HTTP a été créé pour l'architecture du World Wide Web (WWW) et a évolué au fil du temps pour prendre en charge les besoins d'évolutivité d'un système hypertexte mondial. Une grande partie de cette architecture se reflète dans la terminologie utilisée pour définir HTTP.
3.1. Resources (Ressources)
La cible d'une requête HTTP est appelée une « ressource » (Resource). HTTP ne limite pas la nature d'une ressource ; il définit simplement une interface qui pourrait être utilisée pour interagir avec les ressources. La plupart des ressources sont identifiées par un identifiant de ressource uniforme (Uniform Resource Identifier, URI), comme décrit dans la section 4.
L'un des objectifs de conception de HTTP est de séparer l'identification des ressources de la sémantique des requêtes, ce qui est rendu possible en investissant la sémantique de la requête dans la méthode de requête (section 9) et quelques champs d'en-tête modifiant la requête. Une ressource ne peut pas traiter une requête d'une manière incompatible avec la sémantique de la méthode de la requête. Par exemple, bien que l'URI d'une ressource puisse impliquer une sémantique qui n'est pas sûre, un client peut s'attendre à ce que la ressource évite les actions non sûres lors du traitement d'une requête avec une méthode sûre (Safe Method) (voir section 9.2.1).
HTTP s'appuie sur la norme d'identifiant de ressource uniforme (URI) [URI] pour indiquer la ressource cible (section 7.1) et les relations entre les ressources.
3.2. Representations (Représentations)
Une « représentation » (Representation) est une information destinée à refléter un état passé, actuel ou souhaité d'une ressource donnée, dans un format qui peut être facilement communiqué via le protocole. Une représentation se compose d'un ensemble de métadonnées de représentation (Representation Metadata) et d'un flux potentiellement illimité de données de représentation (Representation Data, section 8).
HTTP permet le « masquage d'information » (Information Hiding) derrière son interface uniforme en définissant la communication par rapport à une représentation transférable de l'état de la ressource, plutôt que de transférer la ressource elle-même. Cela permet à la ressource identifiée par un URI d'être n'importe quoi, y compris des fonctions temporelles comme « la météo actuelle à Laguna Beach », tout en fournissant potentiellement des informations qui représentent cette ressource au moment où un message est généré [REST].
L'interface uniforme est similaire à une fenêtre à travers laquelle on ne peut observer et agir sur quelque chose qu'en communiquant des messages à un acteur indépendant de l'autre côté. Une abstraction partagée est nécessaire pour représenter (« prendre la place de ») l'état actuel ou souhaité de cette chose dans nos communications. Lorsqu'une représentation est un hypertexte, elle peut fournir à la fois une représentation de l'état de la ressource et des instructions de traitement qui aident à guider les futures interactions du destinataire.
Une ressource cible peut être fournie avec, ou être capable de générer, plusieurs représentations qui sont chacune destinées à refléter l'état actuel de la ressource. Un algorithme, généralement basé sur la négociation de contenu (Content Negotiation, section 12), serait utilisé pour sélectionner l'une de ces représentations comme étant la plus applicable à une requête donnée. Cette « représentation sélectionnée » (Selected Representation) fournit les données et les métadonnées pour évaluer les requêtes conditionnelles (section 13) et construire le contenu pour les réponses 200 (OK), 206 (Partial Content) et 304 (Not Modified) à GET (section 9.3.1).
3.3. Connections, Clients, and Servers (Connexions, clients et serveurs)
HTTP est un protocole client/serveur qui fonctionne sur une « connexion » (Connection) de couche transport ou de session fiable.
Un « client » (Client) HTTP est un programme qui établit une connexion à un serveur dans le but d'envoyer une ou plusieurs requêtes HTTP. Un « serveur » (Server) HTTP est un programme qui accepte les connexions afin de servir les requêtes HTTP en envoyant des réponses HTTP.
Les termes client et serveur se réfèrent uniquement aux rôles que ces programmes jouent pour une connexion particulière. Le même programme peut agir comme un client sur certaines connexions et comme un serveur sur d'autres.
HTTP est défini comme un protocole sans état (Stateless Protocol), ce qui signifie que la sémantique de chaque message de requête peut être comprise isolément, et que la relation entre les connexions et les messages qui y circulent n'a aucun impact sur l'interprétation de ces messages. Par exemple, une requête CONNECT (section 9.3.6) ou une requête avec le champ d'en-tête Upgrade (section 7.8) peut se produire à tout moment, pas seulement dans le premier message sur une connexion. De nombreuses implémentations dépendent de la conception sans état de HTTP afin de réutiliser les connexions proxy ou d'équilibrer dynamiquement la charge des requêtes sur plusieurs serveurs.
Par conséquent, un serveur ne doit pas (MUST NOT) supposer que deux requêtes sur la même connexion proviennent du même agent utilisateur à moins que la connexion ne soit sécurisée et spécifique à cet agent. Certaines extensions HTTP non standard (par exemple, [RFC4559]) sont connues pour violer cette exigence, entraînant des problèmes de sécurité et d'interopérabilité.
3.4. Messages
HTTP est un protocole sans état de requête/réponse pour échanger des « messages » (Messages) sur une connexion. Les termes « expéditeur » (Sender) et « destinataire » (Recipient) se réfèrent à toute implémentation qui envoie ou reçoit un message donné, respectivement.
Un client envoie des requêtes à un serveur sous la forme d'un message de « requête » (Request) avec une méthode (section 9) et une cible de requête (section 7.1). La requête peut également contenir des champs d'en-tête (section 6.3) pour les modificateurs de requête, les informations du client et les métadonnées de représentation, du contenu (section 6.4) destiné à être traité conformément à la méthode, et des champs de fin (section 6.5) pour communiquer les informations collectées lors de l'envoi du contenu.
Un serveur répond à la requête d'un client en envoyant un ou plusieurs messages de « réponse » (Response), chacun incluant un code d'état (section 15). La réponse peut également contenir des champs d'en-tête pour les informations du serveur, les métadonnées de la ressource et les métadonnées de représentation, du contenu à interpréter conformément au code d'état, et des champs de fin pour communiquer les informations collectées lors de l'envoi du contenu.
3.5. User Agents (Agents utilisateurs)
Le terme « agent utilisateur » (User Agent) se réfère à l'un des divers programmes clients qui initient une requête.
La forme la plus familière d'agent utilisateur est le navigateur Web à usage général, mais ce n'est qu'un petit pourcentage des implémentations. D'autres agents utilisateurs courants incluent les robots d'exploration (Spiders, robots de traversée du Web), les outils en ligne de commande, les écrans d'affichage, les appareils électroménagers, les balances, les ampoules, les scripts de mise à jour de firmware, les applications mobiles et les dispositifs de communication de toutes formes et tailles.
Être un agent utilisateur n'implique pas qu'il y ait un utilisateur humain interagissant directement avec l'agent logiciel au moment d'une requête. Dans de nombreux cas, un agent utilisateur est installé ou configuré pour fonctionner en arrière-plan et enregistrer ses résultats pour une inspection ultérieure (ou enregistrer uniquement un sous-ensemble de ces résultats qui pourraient être intéressants ou erronés). Les robots d'exploration, par exemple, reçoivent généralement un URI de départ et sont configurés pour suivre un certain comportement lors de l'exploration du Web en tant que graphe hypertexte.
De nombreux agents utilisateurs ne peuvent pas, ou choisissent de ne pas, faire de suggestions interactives à leur utilisateur ou fournir un avertissement adéquat pour les problèmes de sécurité ou de confidentialité. Dans les rares cas où cette spécification exige de signaler des erreurs à l'utilisateur, il est acceptable que ce signalement ne soit observable que dans une console d'erreurs ou un fichier journal. De même, les exigences selon lesquelles une action automatisée doit être confirmée par l'utilisateur avant de continuer peuvent être satisfaites via des choix de configuration anticipés, des options d'exécution ou le simple évitement de l'action non sûre ; la confirmation n'implique aucune interface utilisateur spécifique ni interruption du traitement normal si l'utilisateur a déjà fait ce choix.
3.6. Origin Server (Serveur d'origine)
Le terme « serveur d'origine » (Origin Server) se réfère à un programme qui peut générer des réponses autoritaires (Authoritative Responses) pour une ressource cible donnée.
La forme la plus familière de serveur d'origine sont les grands sites Web publics. Cependant, comme les agents utilisateurs étant assimilés aux navigateurs, il est facile d'être induit en erreur en pensant que tous les serveurs d'origine sont identiques. Les serveurs d'origine courants incluent également les unités de domotique, les composants réseau configurables, les machines de bureau, les robots autonomes, les flux d'actualités, les caméras de circulation, les sélecteurs de publicité en temps réel et les plateformes de vidéo à la demande.
La plupart des communications HTTP consistent en une requête de récupération (GET) pour une représentation d'une ressource identifiée par un URI. Dans le cas le plus simple, cela pourrait être accompli via une seule connexion bidirectionnelle (===) entre l'agent utilisateur (UA) et le serveur d'origine (O).
request >
UA ======================================= O
< response
Figure 1
3.7. Intermediaries (Intermédiaires)
HTTP permet l'utilisation d'intermédiaires (Intermediaries) pour satisfaire les requêtes via une chaîne de connexions. Il existe trois formes courantes d'« intermédiaire » HTTP : proxy, passerelle et tunnel. Dans certains cas, un seul intermédiaire peut agir comme un serveur d'origine, un proxy, une passerelle ou un tunnel, en changeant de comportement en fonction de la nature de chaque requête.
> > > >
UA =========== A =========== B =========== C =========== O
< < < <
Figure 2
La figure ci-dessus montre trois intermédiaires (A, B et C) entre l'agent utilisateur et le serveur d'origine. Un message de requête ou de réponse qui parcourt toute la chaîne passera par quatre connexions distinctes. Certaines options de communication HTTP peuvent s'appliquer uniquement à la connexion avec le voisin non-tunnel le plus proche, uniquement aux extrémités de la chaîne, ou à toutes les connexions le long de la chaîne. Bien que le diagramme soit linéaire, chaque participant peut être engagé dans plusieurs communications simultanées. Par exemple, B peut recevoir des requêtes de nombreux clients autres que A, et/ou transmettre des requêtes à des serveurs autres que C, en même temps qu'il traite la requête de A. De même, les requêtes ultérieures peuvent être envoyées via un chemin de connexions différent, souvent basé sur une configuration dynamique pour l'équilibrage de charge.
Les termes « amont » (Upstream) et « aval » (Downstream) sont utilisés pour décrire les exigences directionnelles par rapport au flux de messages : tous les messages circulent de l'amont vers l'aval. Les termes « entrant » (Inbound) et « sortant » (Outbound) sont utilisés pour décrire les exigences directionnelles par rapport à la route de la requête : entrant signifie « vers le serveur d'origine », tandis que sortant signifie « vers l'agent utilisateur ».
Un « proxy » (Proxy) est un agent de transfert de messages qui est choisi par le client, généralement via des règles de configuration locales, pour recevoir des requêtes pour certains types d'URI absolus et tenter de satisfaire ces requêtes via une traduction via l'interface HTTP. Certaines traductions sont minimes, comme pour les requêtes proxy pour les URI « http », tandis que d'autres requêtes peuvent nécessiter une traduction vers et depuis des protocoles de couche application entièrement différents. Les proxies sont souvent utilisés pour regrouper les requêtes HTTP d'une organisation via un intermédiaire commun pour des services de sécurité, des services d'annotation ou une mise en cache partagée. Certains proxies sont conçus pour appliquer des transformations à des messages ou du contenu sélectionnés pendant qu'ils sont transmis, comme décrit dans la section 7.7.
Une « passerelle » (Gateway) (également appelée « proxy inverse » Reverse Proxy) est un intermédiaire qui agit comme un serveur d'origine pour la connexion sortante mais traduit les requêtes reçues et les transmet en entrant vers un autre serveur ou d'autres serveurs. Les passerelles sont souvent utilisées pour encapsuler des services d'information hérités ou non fiables, pour améliorer les performances du serveur grâce à la mise en cache « accélérateur » (Accelerator), et pour permettre le partitionnement ou l'équilibrage de charge des services HTTP sur plusieurs machines.
Toutes les exigences HTTP applicables à un serveur d'origine s'appliquent également à la communication sortante d'une passerelle. Une passerelle communique avec les serveurs entrants en utilisant n'importe quel protocole qu'elle souhaite, y compris des extensions privées à HTTP qui sont en dehors du champ d'application de cette spécification. Cependant, une passerelle HTTP-to-HTTP qui souhaite interopérer avec des serveurs HTTP tiers doit se conformer aux exigences d'agent utilisateur sur la connexion entrante de la passerelle.
Un « tunnel » (Tunnel) agit comme un relais aveugle entre deux connexions sans modifier les messages. Une fois actif, un tunnel n'est pas considéré comme une partie de la communication HTTP, bien que le tunnel puisse avoir été initié par une requête HTTP. Un tunnel cesse d'exister lorsque les deux extrémités de la connexion relayée sont fermées. Les tunnels sont utilisés pour étendre une connexion virtuelle via un intermédiaire, par exemple lorsque la sécurité de la couche transport (Transport Layer Security, TLS, [TLS13]) est utilisée pour établir une communication confidentielle via un proxy de pare-feu partagé.
Les catégories ci-dessus pour l'intermédiaire ne considèrent que ceux agissant comme participants à la communication HTTP. Il existe également des intermédiaires qui peuvent agir sur les couches inférieures de la pile de protocoles réseau, en filtrant ou en redirigeant le trafic HTTP sans la connaissance ou l'autorisation des expéditeurs de messages. Les intermédiaires réseau sont indiscernables (au niveau du protocole) d'un attaquant sur le chemin, introduisant souvent des failles de sécurité ou des problèmes d'interopérabilité en violant par erreur la sémantique HTTP.
Par exemple, un « proxy d'interception » (Interception Proxy) [RFC3040] (également communément appelé « proxy transparent » Transparent Proxy [RFC1919]) diffère d'un proxy HTTP car il n'est pas choisi par le client. Au lieu de cela, un proxy d'interception filtre ou redirige les paquets TCP sortants du port 80 (et occasionnellement d'autres trafics de ports courants). Les proxies d'interception se trouvent couramment sur les points d'accès réseau publics, comme moyen d'appliquer l'abonnement au compte avant de permettre l'utilisation de services Internet non locaux, et dans les pare-feu d'entreprise pour appliquer les politiques d'utilisation du réseau.
3.8. Caches
Un « cache » (Cache) est un stockage local de messages de réponse précédents et le sous-système qui contrôle son stockage, sa récupération et sa suppression de 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 sur les futures requêtes équivalentes. Tout client ou serveur peut (MAY) utiliser un cache, bien qu'un cache ne puisse pas être utilisé en agissant comme un tunnel.
L'effet d'un cache est que la chaîne requête/réponse est raccourcie si l'un des participants le long de la chaîne a une réponse mise en cache applicable à cette requête. Ce qui suit illustre la chaîne résultante si B a une copie mise en cache d'une réponse antérieure de O (via C) pour une requête qui n'a pas été mise en cache par UA ou A.
> >
UA =========== A =========== B - - - - - - C - - - - - - O
< <
Figure 3
Une réponse est « pouvant être mise en cache » (Cacheable) si un cache est autorisé à stocker une copie du message de réponse pour une utilisation dans la réponse aux requêtes ultérieures. Même lorsqu'une réponse peut être mise en cache, il peut y avoir des contraintes supplémentaires placées par le client ou par le serveur d'origine sur le moment où cette réponse mise en cache peut être utilisée pour une requête particulière. Les exigences HTTP pour le comportement du cache et les réponses pouvant être mises en cache sont définies dans [CACHING].
Il existe une grande variété d'architectures et de configurations de caches déployées sur le World Wide Web et à l'intérieur des grandes organisations. Celles-ci incluent les hiérarchies nationales de caches proxy pour économiser la bande passante et réduire la latence, les réseaux de distribution de contenu qui utilisent la mise en cache de passerelle pour optimiser la distribution régionale et mondiale des sites populaires, les systèmes collaboratifs qui diffusent ou multidiffusent des entrées de cache, les archives d'entrées de cache pré-récupérées pour une utilisation dans des environnements hors ligne ou à haute latence, et ainsi de suite.
3.9. Example Message Exchange (Exemple d'échange de messages)
L'exemple suivant illustre un échange de messages HTTP/1.1 typique pour une requête GET (section 9.3.1) sur l'URI http://www.example.com/hello.txt :
Requête du client :
GET /hello.txt HTTP/1.1
User-Agent: curl/7.64.1
Host: www.example.com
Accept-Language: en, mi
Réponse du serveur :
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain
Hello World! My content includes a trailing CRLF.