RFC: 1945
Statut : Information
Retour à l'index des normes : INDEX FRANCAIS

HYPERTEXT TRANSFER PROTOCOL - HTTP/1.0

SPECIFICATION



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

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é.


Précédent - Suivant - Retour au sommaire