2. Message

Les clients et serveurs HTTP/1.1 communiquent en envoyant des messages. Voir la section 3 de [HTTP] pour la terminologie générale et les concepts de base de HTTP.

2.1. Format du message (Message Format)

Un message HTTP/1.1 consiste en une ligne de départ suivie d'un CRLF et d'une séquence d'octets dans un format similaire au format de message Internet [RFC5322] : zéro ou plusieurs lignes de champ d'en-tête (collectivement appelées "en-têtes" ou "section d'en-tête"), une ligne vide indiquant la fin de la section d'en-tête, et un corps de message optionnel.

HTTP-message   = start-line CRLF
                 *( field-line CRLF )
                 CRLF
                 [ message-body ]

Un message peut être soit une requête du client vers le serveur, soit une réponse du serveur vers le client. Syntaxiquement, les deux types de messages ne diffèrent que par la ligne de départ, qui est soit une ligne de requête (pour les requêtes) soit une ligne d'état (pour les réponses), et par l'algorithme de détermination de la longueur du corps du message (section 6).

start-line     = request-line / status-line

En théorie, un client pourrait recevoir des requêtes et un serveur pourrait recevoir des réponses, en les distinguant par leurs différents formats de ligne de départ. En pratique, les serveurs sont implémentés pour n'attendre qu'une requête (une réponse est interprétée comme une méthode de requête inconnue ou invalide), et les clients sont implémentés pour n'attendre qu'une réponse.

HTTP utilise certains éléments de protocole similaires aux extensions Internet Mail multiusages (MIME) [RFC2045]. Voir l'annexe B pour les différences entre les messages HTTP et MIME.

2.2. Analyse du message (Message Parsing)

La procédure normale pour analyser un message HTTP consiste à lire la ligne de départ dans une structure, à lire chaque ligne de champ d'en-tête dans une table de hachage par nom de champ jusqu'à la ligne vide, puis à utiliser les données analysées pour déterminer si un corps de message est attendu. Si un corps de message a été indiqué, il est alors lu comme un flux jusqu'à ce qu'une quantité d'octets égale à la longueur du corps du message soit lue ou que la connexion soit fermée.

Un destinataire DOIT analyser un message HTTP comme une séquence d'octets dans un encodage qui est un sur-ensemble de US-ASCII [USASCII]. L'analyse d'un message HTTP comme un flux de caractères Unicode, sans tenir compte de l'encodage spécifique, crée des vulnérabilités de sécurité en raison des différentes façons dont les bibliothèques de traitement de chaînes gèrent les séquences de caractères multi-octets invalides qui contiennent l'octet LF (%x0A).

Bien que le terminateur de ligne pour la ligne de départ et les champs soit la séquence CRLF, un destinataire PEUT reconnaître un seul LF comme terminateur de ligne et ignorer tout CR précédent.

Un expéditeur NE DOIT PAS générer un CR nu (un caractère CR non immédiatement suivi de LF) dans les éléments de protocole autres que le contenu. Un destinataire d'un tel CR nu DOIT considérer cet élément comme invalide ou remplacer chaque CR nu par SP avant de traiter l'élément ou de transmettre le message.

2.3. Version HTTP (HTTP Version)

HTTP utilise un schéma de numérotation "<major>.<minor>" pour indiquer les versions du protocole. Cette spécification définit la version "1.1". La section 2.5 de [HTTP] spécifie la sémantique des numéros de version HTTP.

La version d'un message HTTP/1.x est indiquée par un champ HTTP-version dans la ligne de départ. HTTP-version est sensible à la casse.

HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
HTTP-name     = %s"HTTP"