RFC du protocole HTTP : Messages HTTP
4. Messages HTTP
4.1 Types de messages
Les messages HTTP consistent en des requêtes émises par un utilisateur à destination d'un serveur, ou d'une réponse d'un serveur au destinataire.
HTTP-message = Requête_simple ; HTTP/0.9 messages
| Réponse_simple
| Requête_complète ; HTTP/1.0 messages
| Réponse_complète
Les requêtes et réponses "complètes" utilisent le format de message défini dans la RFC 822 [7] concernant la transmission d'entités. Ces deux messages peuvent contenir une en-tête optionnelle ainsi que le corps de l'entité. Le corps et l'en-tête de l'entité sont séparés par une ligne vide (soit une séquence CRLFCRLF).
Requête_complète = Ligne_requête ; Section 5.1
*( En-tête_générale ; Section 4.3
| En-tête_requête ; Section 5.2
| En-tête_entité ) ; Section 7.1
CRLF
[ Corps_entité ] ; Section 7.2
Réponse_complète = Ligne-état ; Section 6.1
*( En-tête_générale ; Section 4.3
| En-tête_réponse ; Section 6.2
| En-tête_entité ) ; Section 7.1
CRLF
[ Corps_entité ] ; Section 7.2
Les requête et réponse simple ne transportent jamais d'en-tête. Une seule requête est de ce type : GET.
Requête_simple = "GET" SP URI-visée CRLF
Réponse_simple = [ Corps_entité ]
L'usage des requêtes simples reste déconseillé, car il ne permet pas au serveur de définir le type de média dans sa réponse.
4.2 En-têtes de messages
Les champs d'en-têtes HTTP, dont l'en-tête_générale (Section 4.3), l'en-tête_requête (Section 5.2), L'en-tête_réponse (Section 6.2), et l'en-tête_entité (Section 7.1), ont tous le même format générique décrit dans le paragraphe 3.1 de la RFC 822 [7]. Chaque champ d'en-tête consiste en un nom suivi immédiatement d'un deux-points (":"), un espace (SP), et la valeur du paramètre. Les noms de champs sont insensibles à la casse. Les champs d'en-tête peuvent être écrits sur plusieurs lignes, à condition que le premier caractères des lignes suivantes soit SP ou HT. Cette pratique reste cependant déconseillée.
HTTP-header = nom ":" SP [ valeur ] CRLF
nom = nom_de_champ
valeur = *( contenu | LWS )
contenu = [les OCTETs décrivant la valeur, pouvant
être un *TEXT ou combinaison de noms,
caractères spéciaux, et chaînes entre
guillemets]
L'ordre dans lequel les champs d'en-tête sont reçus n'a pas d'importance. Une "bonne habitude" consistera toutefois à envoyer les champs d'en-tête_générale en premier, suivi des champs d'en-tête_requête ou d'en-tête_réponse, puis enfin les champs d'en-tête_entité.
Lorsque plusieurs champs de même nom doivent être définis avec des valeurs différentes, celles-ci doivent apparaître comme une liste séparée par des virgules [#(values)]. Il doit être possible de combiner cette définition multiple à partir des paires individuelles "nom: valeur", sans changer la sémantique du message, en ajoutant chaque valeur à la suite de la première, en utilisant une virgule comme séparateur.
4.3 En tête générale
Certains champs d'en-tête ont une utilité aussi bien dans des requêtes que dans des réponses, en conservant la même signification. Les informations définies dans ces champs concernent le message lui-même, et non l'entité qu'il transporte.
General-Header = Date ; Section 10.6
| Pragma ; Section 10.12
Des nouveaux noms de champs d'en-tête_générale ne peuvent être introduits que dans le cadre d'un changement de version du protocole. Cependant, de nouveaux champs ou champs expérimentaux peuvent utiliser la sémantique de champs d'en-tête_générale, à partir du moment ou les deux extrémités de la communication sont d'accord pour le faire. Tout champ non reconnu sera considéré comme un champ d'en-tête_entité.
Crédits : T. Berners-Lee, MIT/LCS, R. Fielding, UC Irvine, H. Frystyk, MIT/LCS, Traduction : V.G. FREMAUX Edition originale : Mai 1996 / Version FR: Septembre 1997
|