Aller au contenu principal

6. Response (Réponse)

Après avoir reçu et interprété un message de requête, un serveur répond avec un message de réponse HTTP.

Response      = Status-Line               ; Section 6.1
                *(( general-header        ; Section 4.5
                 | response-header        ; Section 6.2
                 | entity-header ) CRLF)  ; Section 7.1
                CRLF
                [ message-body ]          ; Section 7.2

6.1 Status-Line (Ligne d'État)​

La première ligne d'un message de réponse est la Status-Line, composée de la version du protocole suivie d'un code d'état numérique et de sa phrase de raison associée, chaque élément étant séparé par des caractères SP. Aucun CR ou LF n'est autorisé, sauf dans la séquence CRLF finale.

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

6.1.1 Status Code and Reason Phrase (Code d'État et Phrase de Raison)​

L'élément Status-Code est un code de résultat entier à 3 chiffres de la tentative de comprendre et de satisfaire la requête. Ces codes sont entièrement définis dans la section 10. La Reason-Phrase est destinée à fournir une brève description textuelle du Status-Code. Le Status-Code est destiné à être utilisé par des automates, et la Reason-Phrase est destinée à l'utilisateur humain. Le client n'est pas tenu d'examiner ou d'afficher la Reason-Phrase.

Le premier chiffre du Status-Code définit la classe de la réponse. Les deux derniers chiffres n'ont aucun rôle de catégorisation. Il existe 5 valeurs pour le premier chiffre :

  • 1xx: Informational (Informationnel) - La requête a été reçue, le traitement continue

  • 2xx: Success (Succès) - L'action a été reçue, comprise et acceptée avec succès

  • 3xx: Redirection (Redirection) - Une action supplémentaire doit être entreprise pour compléter la requête

  • 4xx: Client Error (Erreur Client) - La requête contient une syntaxe incorrecte ou ne peut être complétée

  • 5xx: Server Error (Erreur Serveur) - Le serveur n'a pas réussi à compléter une requête apparemment valide

Les valeurs individuelles des codes d'état numériques définis pour HTTP/1.1, ainsi qu'un ensemble d'exemples correspondants de Reason-Phrase, sont présentés ci-dessous. Les phrases de raison énumérées ici ne sont que des recommandations - elles peuvent (MAY) être remplacées par des équivalents locaux sans affecter le protocole.

Status-Code    =
         "100"  ; Section 10.1.1: Continue
       | "101"  ; Section 10.1.2: Switching Protocols
       | "200"  ; Section 10.2.1: OK
       | "201"  ; Section 10.2.2: Created
       | "202"  ; Section 10.2.3: Accepted
       | "203"  ; Section 10.2.4: Non-Authoritative Information
       | "204"  ; Section 10.2.5: No Content
       | "205"  ; Section 10.2.6: Reset Content
       | "206"  ; Section 10.2.7: Partial Content
       | "300"  ; Section 10.3.1: Multiple Choices
       | "301"  ; Section 10.3.2: Moved Permanently
       | "302"  ; Section 10.3.3: Found
       | "303"  ; Section 10.3.4: See Other
       | "304"  ; Section 10.3.5: Not Modified
       | "305"  ; Section 10.3.6: Use Proxy
       | "307"  ; Section 10.3.8: Temporary Redirect
       | "400"  ; Section 10.4.1: Bad Request
       | "401"  ; Section 10.4.2: Unauthorized
       | "402"  ; Section 10.4.3: Payment Required
       | "403"  ; Section 10.4.4: Forbidden
       | "404"  ; Section 10.4.5: Not Found
       | "405"  ; Section 10.4.6: Method Not Allowed
       | "406"  ; Section 10.4.7: Not Acceptable
       | "407"  ; Section 10.4.8: Proxy Authentication Required
       | "408"  ; Section 10.4.9: Request Time-out
       | "409"  ; Section 10.4.10: Conflict
       | "410"  ; Section 10.4.11: Gone
       | "411"  ; Section 10.4.12: Length Required
       | "412"  ; Section 10.4.13: Precondition Failed
       | "413"  ; Section 10.4.14: Request Entity Too Large
       | "414"  ; Section 10.4.15: Request-URI Too Large
       | "415"  ; Section 10.4.16: Unsupported Media Type
       | "416"  ; Section 10.4.17: Requested range not satisfiable
       | "417"  ; Section 10.4.18: Expectation Failed
       | "500"  ; Section 10.5.1: Internal Server Error
       | "501"  ; Section 10.5.2: Not Implemented
       | "502"  ; Section 10.5.3: Bad Gateway
       | "503"  ; Section 10.5.4: Service Unavailable
       | "504"  ; Section 10.5.5: Gateway Time-out
       | "505"  ; Section 10.5.6: HTTP Version not supported
       | extension-code

extension-code = 3DIGIT
Reason-Phrase  = *<TEXT, excluding CR, LF>

Les codes d'état HTTP sont extensibles. Les applications HTTP ne sont pas tenues de comprendre la signification de tous les codes d'état enregistrés, bien qu'une telle compréhension soit évidemment souhaitable. Cependant, les applications doivent (MUST) comprendre la classe de n'importe quel code d'état, comme indiqué par le premier chiffre, et traiter toute réponse non reconnue comme équivalente au code d'état x00 de cette classe, sauf qu'une réponse non reconnue ne doit pas (MUST NOT) être mise en cache. Par exemple, si un client reçoit un code d'état 431 non reconnu, il peut supposer en toute sécurité qu'il y a un problème avec sa requête et traiter la réponse comme s'il avait reçu un code d'état 400. Dans de tels cas, l'agent utilisateur devrait (SHOULD) présenter à l'utilisateur l'entité incluse dans la réponse, car cette entité est susceptible d'inclure des informations lisibles par l'homme expliquant le statut inhabituel.

6.2 Response Header Fields (Champs d'En-tête de Réponse)​

Les champs d'en-tête de réponse permettent au serveur de transmettre des informations supplémentaires sur la réponse qui ne peuvent pas être placées dans la Status-Line. Ces champs d'en-tête fournissent des informations sur le serveur et sur l'accès ultérieur à la ressource identifiée par le Request-URI.

response-header = Accept-Ranges           ; Section 14.5
                | Age                     ; Section 14.6
                | ETag                    ; Section 14.19
                | Location                ; Section 14.30
                | Proxy-Authenticate      ; Section 14.33
                | Retry-After             ; Section 14.37
                | Server                  ; Section 14.38
                | Vary                    ; Section 14.44
                | WWW-Authenticate        ; Section 14.47

Les noms de champs d'en-tête de réponse ne peuvent être étendus de manière fiable qu'en changeant la version du protocole. Cependant, de nouveaux champs d'en-tête ou expérimentaux peuvent être attribués aux valeurs de champ sans changer la version du protocole. Les champs d'en-tête non reconnus devraient (SHOULD) être traités comme des champs d'en-tête d'entité par le destinataire.

Dernière mise à jour le