Zum Hauptinhalt springen

6. Response (Antwort)

Nach dem Empfang und der Interpretation einer Anfragenachricht antwortet ein Server mit einer HTTP-Antwortnachricht.

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 (Statuszeile)​

Die erste Zeile einer Antwortnachricht ist die Status-Line, bestehend aus der Protokollversion, gefolgt von einem numerischen Statuscode und der zugehörigen Textphrase, wobei jedes Element durch SP-Zeichen getrennt ist. Außer in der finalen CRLF-Sequenz sind keine CR oder LF erlaubt.

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

6.1.1 Status Code and Reason Phrase (Statuscode und Begründungsphrase)​

Das Status-Code-Element ist ein dreistelliger ganzzahliger Ergebniscode des Versuchs, die Anfrage zu verstehen und zu erfüllen. Diese Codes sind in Abschnitt 10 vollständig definiert. Die Reason-Phrase soll eine kurze Textbeschreibung des Status-Code liefern. Der Status-Code ist für die Verwendung durch Automaten gedacht, und die Reason-Phrase ist für den menschlichen Benutzer gedacht. Der Client ist nicht verpflichtet, die Reason-Phrase zu untersuchen oder anzuzeigen.

Die erste Ziffer des Status-Code definiert die Klasse der Antwort. Die letzten beiden Ziffern haben keine Kategorisierungsfunktion. Es gibt 5 Werte für die erste Ziffer:

  • 1xx: Informational (Informativ) - Die Anfrage wurde empfangen, die Verarbeitung wird fortgesetzt

  • 2xx: Success (Erfolg) - Die Aktion wurde erfolgreich empfangen, verstanden und akzeptiert

  • 3xx: Redirection (Umleitung) - Weitere Maßnahmen müssen ergriffen werden, um die Anfrage abzuschließen

  • 4xx: Client Error (Client-Fehler) - Die Anfrage enthält fehlerhafte Syntax oder kann nicht abgeschlossen werden

  • 5xx: Server Error (Server-Fehler) - Der Server konnte eine offensichtlich gültige Anfrage nicht erfüllen

Die einzelnen Werte der für HTTP/1.1 definierten numerischen Statuscodes sowie ein Satz entsprechender Beispiele für Reason-Phrase werden nachfolgend dargestellt. Die hier aufgeführten Begründungsphrasen sind nur Empfehlungen - sie können (MAY) ohne Beeinträchtigung des Protokolls durch lokale Äquivalente ersetzt werden.

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>

HTTP-Statuscodes sind erweiterbar. HTTP-Anwendungen müssen die Bedeutung aller registrierten Statuscodes nicht verstehen, obwohl ein solches Verständnis offensichtlich wünschenswert ist. Anwendungen müssen (MUST) jedoch die Klasse jedes Statuscodes verstehen, wie durch die erste Ziffer angegeben, und jede nicht erkannte Antwort als äquivalent zum x00-Statuscode dieser Klasse behandeln, außer dass eine nicht erkannte Antwort nicht (MUST NOT) gecacht werden darf. Wenn ein Client beispielsweise einen nicht erkannten Statuscode 431 empfängt, kann er sicher annehmen, dass ein Problem mit seiner Anfrage vorliegt, und die Antwort so behandeln, als hätte er einen Statuscode 400 erhalten. In solchen Fällen sollte (SHOULD) der Benutzeragent dem Benutzer die in der Antwort enthaltene Entität präsentieren, da diese Entität wahrscheinlich menschenlesbare Informationen enthält, die den ungewöhnlichen Status erklären.

6.2 Response Header Fields (Antwort-Header-Felder)​

Antwort-Header-Felder ermöglichen es dem Server, zusätzliche Informationen über die Antwort zu übermitteln, die nicht in die Status-Line aufgenommen werden können. Diese Header-Felder liefern Informationen über den Server und über den weiteren Zugriff auf die durch den Request-URI identifizierte Ressource.

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

Antwort-Header-Feldnamen können nur durch Ändern der Protokollversion zuverlässig erweitert werden. Neue oder experimentelle Header-Felder können jedoch Feldwerten zugewiesen werden, ohne die Protokollversion zu ändern. Nicht erkannte Header-Felder sollten (SHOULD) vom Empfänger als Entitäts-Header-Felder behandelt werden.

Letztes Update am