RFC: 1945
Statut : Information
Retour à l'index des normes : INDEX FRANCAIS
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.
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.
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.
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é.