Aller au contenu principal

3. Message Format (Format des Messages)

Tous les messages HTTP se composent d'une ligne de départ, suivie d'une séquence d'octets de syntaxe similaire à l'Internet Message Format [RFC5322]: zéro ou plusieurs champs d'en-tête (collectivement appelés "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
                 *( header-field CRLF )
                 CRLF
                 [ message-body ]

3.1. Start Line (Ligne de Départ)​

Un message HTTP commence par une ligne de départ (start-line).

start-line     = request-line / status-line

3.1.1. Request Line (Ligne de Requête)​

Une ligne de requête (request-line) commence par un jeton de méthode, suivi d'une cible de requête, d'une version de protocole et se termine par CRLF.

request-line   = method SP request-target SP HTTP-version CRLF
method         = token

3.1.2. Status Line (Ligne de Statut)​

La première ligne d'un message de réponse est la ligne de statut (status-line), composée de la version du protocole, d'un espace, d'un code de statut, d'un autre espace, d'une phrase de raison éventuellement vide, et se terminant par CRLF.

status-line = HTTP-version SP status-code SP reason-phrase CRLF
status-code = 3DIGIT
reason-phrase  = *( HTAB / SP / VCHAR / obs-text )

3.2. Header Fields (Champs d'En-tête)​

Chaque champ d'en-tête se compose d'un nom de champ insensible à la casse suivi d'un deux-points (":"), d'un espace blanc facultatif, de la valeur du champ et d'un espace blanc facultatif.

header-field   = field-name ":" OWS field-value OWS
field-name     = token
field-value    = *( field-content / obs-fold )
field-content  = field-vchar [ 1*( SP / HTAB ) field-vchar ]
field-vchar    = VCHAR / obs-text
obs-fold       = CRLF 1*( SP / HTAB )

3.2.1. Field Extensibility (Extensibilité des Champs)​

Les champs d'en-tête sont entièrement extensibles: il n'y a pas de limite au nombre de champs d'en-tête pouvant être utilisés dans un message.

3.2.2. Field Order (Ordre des Champs)​

L'ordre dans lequel les champs d'en-tête avec des noms de champs différents sont reçus n'est pas significatif.

3.2.3. Whitespace (Espaces Blancs)​

L'espace blanc facultatif (OWS) est utilisé uniquement pour améliorer la lisibilité.

OWS            = *( SP / HTAB )
RWS            = 1*( SP / HTAB )
BWS            = OWS

3.2.4. Field Parsing (Analyse des Champs)​

Les messages sont analysés en utilisant une approche générique indépendante des noms de champs individuels.

3.2.5. Field Limits (Limites de Champs)​

Les implémentations HTTP ne placent pas de limites prédéfinies sur la longueur de chaque champ d'en-tête ou sur la longueur de la section d'en-tête dans son ensemble.

3.2.6. Field Value Components (Composants de Valeur de Champ)​

La plupart des valeurs de champ d'en-tête HTTP sont définies en utilisant une grammaire commune de types de valeurs de champ.

token          = 1*tchar
tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
               / "+" / "-" / "." / "0"-"9" / "A"-"Z" / "^" / "_"
               / "`" / "a"-"z" / "|" / "~"
quoted-string  = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext         = HTAB / SP / "!" / %x23-5B / %x5D-7E / obs-text
quoted-pair    = "\" ( HTAB / SP / VCHAR / obs-text )
comment        = "(" *( ctext / quoted-pair / comment ) ")"
ctext          = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text

3.3. Message Body (Corps du Message)​

Le corps du message (message-body, si présent) d'un message HTTP est utilisé pour transporter la charge utile (payload) du message.

message-body = *OCTET

3.3.1. Transfer-Encoding​

L'en-tête Transfer-Encoding énumère les noms de codage de transfert correspondant à la séquence de codages de transfert qui ont été (ou seront) appliqués à la charge utile afin de former le corps du message.

Transfer-Encoding = 1#transfer-coding

Un serveur DOIT générer un code de statut 400 (Bad Request, Mauvaise Requête) pour toute requête reçue qui contient à la fois un en-tête Content-Length et un Transfer-Encoding.

3.3.2. Content-Length​

L'en-tête Content-Length fournit la longueur anticipée du corps du message en octets.

Content-Length = 1*DIGIT

3.3.3. Message Body Length (Longueur du Corps du Message)​

La longueur d'un corps de message est déterminée par l'un des éléments suivants (dans l'ordre de priorité):

  1. Toute réponse à une requête HEAD et toute réponse avec un code de statut 1xx (Informational, Informatif), 204 (No Content, Pas de Contenu) ou 304 (Not Modified, Non Modifié) est toujours terminée par la première ligne vide après les champs d'en-tête.

  2. Si un en-tête Transfer-Encoding est présent et que la valeur du codage de transfert chunked est la valeur finale, alors le corps du message consiste en un ou plusieurs chunks.

  3. Si un en-tête Content-Length est présent, sa valeur décimale en octets représente à la fois la longueur de la charge utile et la longueur du corps du message.

  4. Si le message utilise le codage de transfert "multipart/byteranges" et que l'en-tête Content-Length n'est pas autrement spécifié, alors ce type de média auto-délimité définit la longueur du corps du message.

  5. Par fermeture de la connexion par le serveur.

3.4. Handling Incomplete Messages (Gestion des Messages Incomplets)​

Un serveur qui reçoit un message de requête incomplet, généralement en raison d'une connexion fermée prématurément, DOIT répondre avec un code de statut 400 (Bad Request, Mauvaise Requête).

3.5. Message Parsing Robustness (Robustesse de l'Analyse des Messages)​

Bien que les exigences de ce document soient exprimées en termes de conformité stricte, les implémentations sont encouragées à être tolérantes lors de l'analyse.

Dernière mise à jour le