1. Introduction

1.1. Purpose (Objectif)

Le protocole de transfert hypertexte (Hypertext Transfer Protocol, HTTP) est une famille de protocoles sans état (Stateless), de niveau application (Application-Level), de requête/réponse (Request/Response) qui partagent une interface générique (Generic Interface), une sémantique extensible (Extensible Semantics) et des messages auto-descriptifs (Self-Descriptive Messages) pour permettre une interaction flexible avec les systèmes d'information hypertexte basés sur le réseau.

HTTP masque les détails de la mise en œuvre d'un service en présentant une interface uniforme (Uniform Interface) aux clients qui est indépendante des types de ressources fournies. De même, les serveurs n'ont pas besoin de connaître l'objectif de chaque client : une requête peut être considérée isolément plutôt que d'être associée à un type spécifique de client ou à une séquence prédéterminée d'étapes d'application. Cela permet d'utiliser efficacement des implémentations à usage général dans de nombreux contextes différents, réduit la complexité des interactions et permet une évolution indépendante au fil du temps.

HTTP est également conçu pour être utilisé comme protocole d'intermédiation (Intermediation Protocol), dans lequel les proxies (Proxies) et les passerelles (Gateways) peuvent traduire des systèmes d'information non-HTTP en une interface plus générique.

Une conséquence de cette flexibilité est que le protocole ne peut pas être défini en termes de ce qui se passe derrière l'interface. Au lieu de cela, nous sommes limités à définir la syntaxe de la communication (Syntax of Communication), l'intention de la communication reçue (Intent) et le comportement attendu des destinataires (Expected Behavior). Si la communication est considérée isolément, les actions réussies devraient se refléter dans les changements correspondants de l'interface observable fournie par les serveurs. Cependant, étant donné que plusieurs clients peuvent agir en parallèle et peut-être à des fins contradictoires, nous ne pouvons pas exiger que ces changements soient observables au-delà de la portée d'une seule réponse.

1.2. History and Evolution (Histoire et évolution)

HTTP est le principal protocole de transfert d'informations pour le World Wide Web depuis son introduction en 1990. Il a commencé comme un mécanisme trivial pour les requêtes à faible latence, avec une seule méthode (GET) pour demander le transfert d'un document hypertexte présumé identifié par un nom de chemin donné. Au fur et à mesure que le Web s'est développé, HTTP a été étendu pour inclure les requêtes et les réponses dans des messages, transférer des formats de données arbitraires en utilisant des types de médias (Media Types) de type MIME et acheminer les requêtes via des intermédiaires (Intermediaries). Ces protocoles ont finalement été définis comme HTTP/0.9 et HTTP/1.0 (voir [HTTP/1.0]).

HTTP/1.1 a été conçu pour affiner les fonctionnalités du protocole tout en conservant la compatibilité avec la syntaxe de messagerie textuelle existante, améliorant son interopérabilité (Interoperability), son évolutivité (Scalability) et sa robustesse (Robustness) sur Internet. Cela comprenait des délimiteurs de données basés sur la longueur (Length-Based Data Delimiters) pour le contenu fixe et dynamique (fragmenté, Chunked), un cadre cohérent pour la négociation de contenu (Content Negotiation), des validateurs opaques (Opaque Validators) pour les requêtes conditionnelles (Conditional Requests), des contrôles de cache (Cache Controls) pour une meilleure cohérence du cache, des requêtes de plage (Range Requests) pour les mises à jour partielles et des connexions persistantes (Persistent Connections) par défaut. HTTP/1.1 a été introduit en 1995 et publié sur la piste des normes (Standards Track) en 1997 [RFC2068], révisé en 1999 [RFC2616] et révisé à nouveau en 2014 ([RFC7230] à [RFC7235]).

HTTP/2 ([HTTP/2]) a introduit une couche de session multiplexée (Multiplexed Session Layer) au-dessus des protocoles TLS et TCP existants pour échanger des messages HTTP concurrents avec une compression de champ efficace (Field Compression) et un push serveur (Server Push). HTTP/3 ([HTTP/3]) offre une plus grande indépendance pour les messages concurrents en utilisant QUIC comme transport multiplexé sécurisé sur UDP au lieu de TCP.

Les trois versions majeures de HTTP s'appuient sur la sémantique définie par ce document. Elles ne se sont pas rendues obsolètes les unes les autres car chacune présente des avantages et des limitations spécifiques selon le contexte d'utilisation. Les implémentations doivent choisir le transport et la syntaxe de messagerie les plus appropriés pour leur contexte particulier.

Cette révision de HTTP sépare la définition de la sémantique (ce document) et de la mise en cache ([CACHING]) de la syntaxe de messagerie HTTP/1.1 actuelle ([HTTP/1.1]) pour permettre à chaque version majeure du protocole de progresser indépendamment tout en se référant à la même sémantique de base.

1.3. Core Semantics (Sémantique de base)

HTTP fournit une interface uniforme pour interagir avec une ressource (Resource, Section 3.1) - indépendamment de son type, de sa nature ou de son implémentation - en envoyant des messages qui manipulent ou transfèrent des représentations (Representations, Section 3.2).

Chaque message est soit une requête (Request), soit une réponse (Response). Un client construit des messages de requête qui communiquent ses intentions et achemine ces messages vers un serveur d'origine (Origin Server) identifié. Un serveur écoute les requêtes, analyse chaque message reçu, interprète la sémantique du message par rapport à la ressource cible (Target Resource) identifiée et répond à cette requête avec un ou plusieurs messages de réponse. Le client examine les réponses reçues pour voir si ses intentions ont été exécutées, déterminant quoi faire ensuite en fonction des codes d'état (Status Codes) et du contenu reçus.

La sémantique HTTP comprend les intentions définies par chaque méthode de requête (Section 9), les extensions à ces sémantiques qui peuvent être décrites dans les champs d'en-tête de requête (Request Header Fields), les codes d'état qui décrivent la réponse (Section 15) et d'autres données de contrôle et métadonnées de ressource (Resource Metadata) qui peuvent être données dans les champs de réponse.

La sémantique comprend également les métadonnées de représentation (Representation Metadata) qui décrivent comment le contenu est destiné à être interprété par un destinataire, les champs d'en-tête de requête qui peuvent influencer la sélection du contenu et les divers algorithmes de sélection qui sont collectivement appelés « négociation de contenu » (Content Negotiation, Section 12).

1.4. Specifications Obsoleted by This Document (Spécifications rendues obsolètes par ce document)

Titre	Référence	Voir
HTTP Over TLS	[RFC2818]	B.1
HTTP/1.1 Message Syntax and Routing [*]	[RFC7230]	B.2
HTTP/1.1 Semantics and Content	[RFC7231]	B.3
HTTP/1.1 Conditional Requests	[RFC7232]	B.4
HTTP/1.1 Range Requests	[RFC7233]	B.5
HTTP/1.1 Authentication	[RFC7235]	B.6
HTTP Status Code 308 (Permanent Redirect)	[RFC7538]	B.7
HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields	[RFC7615]	B.8
HTTP Client-Initiated Content-Encoding	[RFC7694]	B.9

Tableau 1

[*] Ce document rend obsolètes uniquement les parties de la RFC 7230 qui sont indépendantes de la syntaxe de messagerie HTTP/1.1 et de la gestion des connexions ; le reste de la RFC 7230 est rendu obsolète par « HTTP/1.1 » [HTTP/1.1].

---