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