RFC du protocole HTTP : Réponse

Une fois la requête reçue et interprétée, un serveur répond par un message HTTP de réponse.

Réponse             = Réponse_simple | Réponse_complète

Réponse_simple      = [ Corps_entité ]

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 

Une réponse_simple ne peut être envoyé qu'en réponse d'une requête_simple HTTP/0.9 ou si le serveur ne supporte que la version limitée de protocole HTTP/0.9. Si un client émet une requête_complète HTTP/1.0 et reçoit une réponse ne commençant pas par une ligne_état, il devra conclure qu'il s'agit d'une réponse_simple et l'interprétera en conséquence. Notez qu'une réponse ne contient que le corps_entité, et se termine par la fermeture de la connexion par le serveur.

6.1 Ligne d'état

La première ligne d'un message de réponse_complète est la ligne d'état, constituée d'une indication du numéro de version du protocole, suivi du code numérique de la réponse, suivi enfin d'une explicitation textuelle de cette réponse, chaque élément étant séparé par un espace. Aucun CR ni LF ne peuvent y apparaître à l'exception de la séquence CRLF finale.

Ligne_état        = Version_HTTP SP Code_état SP Raison CRLF

La ligne d'état débutant toujours par ce numéro de version et le code de réponse:

(ex., "HTTP/1.0 200 "), la seule présence de cette expression est suffisante pour différentier une réponse_simple d'une réponse_complète émise en retour d'une requête sousle protocole HTTP/1.0. Le format de réponse_simple n'interdit cependant pas qu'une telle expression soit placée en tête du corps d'entité, provoquant ainsi une erreur d'interprétation de la part du récepteur. Dans la pratique, la plupart des serveurs HTTP/0.9 ne peuvent générer que des réponses de type "text/html", ce qui en principe, élimine le risque d'une telle confusion.

6.1.1 Code d'état et raison explicite

L'élément code_état est un nombre entier à 3 chiffres indiquant le succès ou la cause d'erreur de la transaction. L'élément "raison" est un commentaire textuel destiné à identifier explicitement la cause d'erreur. Le code d'état sera en général exploité par des automates. La raison est à destination de notre intellect humain. Celle-ci n'est pas obligatoirement traitée ni reportée par le client.

Le premier chiffre du code d'état indique la classe générale de la réponse. Les deux derniers n'ont pas de rôle de classification particulier. Le premier chiffre peut prendre 5 valeurs:

Code	Classe	Usage
1xx	Information	Non utilisé, pour usage futur
2xx	Succès	L'action a été correctement reçue, interprétée, et exécutée.
3xx	Redirection	Une décision supplémentaire doit être prise pour terminer la requête
4xx	Erreur Client	La requête présente une erreur de forme et ne peut être satisfaite
5xx	Erreur Serveur	La requête est valide, mais le serveur ne peut la satisfaire

Les valeurs actuellement reconnues sous HTTP/1.0, et les phrases types d'explicitation associées, sont présentées ci-dessous. Ces phrases ne sont que recommandées -- elles peuvent être remplacées par des variations locales sans affecter le protocole. Ces codes sont intégralement listés en section 9.

Code_état   = "200"   ; OK                      OK
            | "201"   ; Created                 Créé
            | "202"   ; Accepted                Accepté
            | "204"   ; No Content              Pas de contenu
            | "301"   ; Moved Permanently       Changement d'adresse définitif
            | "302"   ; Moved Temporarily       Changement temporaire
            | "304"   ; Not Modified            Non modifié
            | "400"   ; Bad Request             Requête incorrecte
            | "401"   ; Unauthorized            Non autorisé
            | "403"   ; Forbidden               Interdit
            | "404"   ; Not Found               Non trouvé
            | "500"   ; Internal Server Error   Erreur interne serveur
            | "501"   ; Not Implemented         Non implémenté
            | "502"   ; Bad Gateway             Erreur de routeur
            | "503"   ; Service Unavailable     Indisponible
            | autres_codes

autres_codes = 3DIGIT

Raison  = *[TEXT, sauf CR, LF]

La liste des codes HTTP est extensible, mais seuls les codes ci-dessus sont utilisés dans la pratique courante. Les applications HTTP n'ont pas nécessairement à connaître la signification de tous les codes enregistrés, bien que ce soit souhaitable pour des raisons évidentes. Au minimum, les applications devront pouvoir comprendre le premier chiffre de ce code, et comprendre tout numéro de réponse non identifié comme le numéro x00 de la classe, indiquant ainsi la définition générique de la classe. Aucune réponse non identifiée ne peut être enregistrée en cache.

Par exemple, si un code "inconnu" 431 est reçu par le client, celui-ci peut interpréter sans doute possible qu'un problème est survenu, et peut réagir comme s'il avait reçu le code 400. Dans de tels cas, il est fortement conseillé que l'application reporte le corps de l'entité de réponse, dans la mesure où il y a de fortes chances que celui-ci contienne des informations "en clair" sur la nature de l'erreur.

6.2 En-tête de réponse

Les champs d'en-tête de réponse véhiculent certaines informations complémentaires concernant cette réponse, et qui ne peuvent être mentionnées dans la ligne d'état. Ces champs donnent des informations sur le serveur lui-même, et sur les actions à mener par la suite pour accéder à la ressource demandée.

Response-Header    = Location            ; Section 10.11
                   | Server              ; Section 10.14
                   | WWW-Authentificate  ; Section 10.16 

Des nouveaux noms de champs d'en-tête_réponse 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_réponse, à 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é.