HTTP-Statuscode

Grundlagen und Einteilung

Ein HTTP-Statuscode ist eine Antwort, die ein Server auf jede HTTP-Anfrage eines Clients, etwa eines Webbrowsers, liefert. Er teilt mit, ob die Anfrage erfolgreich bearbeitet wurde. Bei einem Fehler kann der Statuscode außerdem angeben, wo oder wie die gewünschten Informationen erreichbar sind, beispielsweise durch eine Umleitung oder nach einer Authentifizierung. Besonders bekannt sind 400 „Bad Request“ beziehungsweise „Fehlerhafte Anfrage“, 403 „Forbidden“ beziehungsweise „Fehlende Zugriffsberechtigung“ und 404 „Not Found“ beziehungsweise „Nicht gefunden“.

Die erste Ziffer bezeichnet die Statusklasse:

• 1xx: Informationen; die Bearbeitung dauert noch an.
• 2xx: Erfolgreiche Operation; die Antwort kann verwertet werden.
• 3xx: Umleitung; der Client muss weitere Schritte ausführen.
• 4xx: Client-Fehler; die Ursache liegt eher im Verantwortungsbereich des Clients.
• 5xx: Server-Fehler; die Ursache liegt eher im Verantwortungsbereich des Servers.
• 9xx: proprietäre, also von einzelnen Softwareherstellern definierte Fehler.

Die standardisierten Statuscodes sind unter anderem in RFC 9110, das RFC 2616 ersetzt, sowie in RFC 2518, RFC 2817, RFC 2295, RFC 2774 und RFC 4918 festgelegt. Einige Codes gehören zu WebDAV, einer Erweiterung für verteiltes Arbeiten an Webressourcen. Zusätzlich verwenden manche Hersteller eigene Codes. Andere Software kann solche Codes möglicherweise nur als unbekannten Fehler anzeigen. Server geben proprietäre Codes teilweise nur dann zurück, wenn sie anhand der Anfrage die zugehörige Spezialsoftware erkennen.

Informationen und erfolgreiche Operationen

Die Informationscodes 1xx zeigen an, dass die Anfrage noch bearbeitet wird:

• 100 Continue: Die Anfrage wurde noch nicht zurückgewiesen. Zusammen mit dem Header-Feld „Expect 100-continue“ kann der Client anschließend mit einer möglicherweise sehr großen Anfrage fortfahren.
• 101 Switching Protocols: Der Server stimmt einem im „Upgrade“-Header-Feld verlangten Wechsel des Protokolls zu, beispielsweise von HTTP zu WebSocket.
• 102 Processing: Diese Zwischenantwort verhindert bei einer zeitintensiven Anfrage ein Timeout. Auf derselben Verbindung muss ohne weitere Client-Anfrage noch eine endgültige Antwort folgen.
• 103 Early Hints: Zusammen mit dem „Link“-Header ermöglicht der Code das Vorladen von Ressourcen, während die endgültige Antwort vorbereitet wird.

Die 2xx-Codes bedeuten, dass die Anfrage erfolgreich war:

• 200 OK: Die Anfrage wurde erfolgreich bearbeitet; ihr Ergebnis wird übertragen.
• 201 Created: Die angeforderte Ressource wurde erstellt. Das „Location“-Header-Feld kann ihre Adresse enthalten.
• 202 Accepted: Die Anfrage wurde angenommen, wird aber später ausgeführt; ihr Erfolg ist nicht garantiert.
• 203 Non-Authoritative Information: Ein „Transforming Proxy“ übermittelt ein gegenüber der Quelle verändertes Dokument, nachdem er von ihr eine 200-OK-Antwort erhalten hat.
• 204 No Content: Die Anfrage war erfolgreich, die Antwort enthält absichtlich keine Daten.
• 205 Reset Content: Der Client soll das Dokument neu aufbauen und Formulareingaben zurücksetzen.
• 206 Partial Content: Ein angeforderter Teil wurde übertragen. Der Code steht im Zusammenhang mit „Content-Range“ oder „multipart/byteranges“ und kann Teil-Downloads, etwa bei Wget, anzeigen.
• 207 Multi-Status: Bei WebDAV enthält die Antwort ein XML-Dokument mit mehreren Statuscodes für unabhängig ausgeführte Operationen.
• 208 Already Reported: Bei WebDAV wurden die Mitglieder einer Bindung bereits aufgezählt und sind in der aktuellen Anfrage nicht erneut enthalten. Der Code ist in RFC 5842 definiert.
• 226 IM Used: Nach RFC 3229 wurde eine GET-Anforderung erfüllt; die Antwort ist das Ergebnis einer oder mehrerer Instanz-Manipulationen bezogen auf die aktuelle Instanz.

Umleitungen und weitere notwendige Schritte

Bei 3xx ist die Anfrage nicht einfach fehlgeschlagen. Der Client muss weitere Schritte ausführen, damit sie erfolgreich abgeschlossen oder die Ressource genutzt werden kann:

• 300 Multiple Choices: Die Ressource liegt in verschiedenen Darstellungen vor. Eine Liste ist enthalten; „Location“ kann die bevorzugte Darstellung nennen.
• 301 Moved Permanently: Die Ressource befindet sich dauerhaft unter der im „Location“-Header-Feld angegebenen Adresse; die alte Adresse ist nicht mehr gültig.
• 302 Found (Moved Temporarily): Die Ressource ist vorübergehend unter der angegebenen Adresse erreichbar, die alte bleibt gültig. Browser folgen meist mit GET, selbst wenn die ursprüngliche Anfrage POST war. Je nach Anwendungsfall wird 302 in HTTP/1.1 durch 303 oder 307 ersetzt. Die 302-Weiterleitung ist wegen Suchmaschinen-Fehlern und URL-Hijacking in Kritik geraten.
• 303 See Other: Die Antwort ist unter der „Location“-Adresse mit GET abrufbar, auch wenn die ursprüngliche Anfrage POST war.
• 304 Not Modified: Die Ressource hat sich seit der letzten Abfrage nicht verändert und wird deshalb nicht erneut übertragen; dies betrifft den Browser-Cache-Versionsvergleich.
• 305 Use Proxy: Die Ressource ist nur über einen Proxy erreichbar; „Location“ enthält dessen Adresse.
• 306 ist reserviert und wird nicht mehr verwendet. Der Code wurde für „Switch Proxy“ eingesetzt.
• 307 Temporary Redirect: Die Ressource ist vorübergehend unter einer neuen Adresse verfügbar. Der Client soll dieselbe Methode wie beim ursprünglichen Request verwenden, also beispielsweise POST mit POST fortsetzen. Dies unterscheidet 307 von 302/303.
• 308 Permanent Redirect: Die Ressource ist dauerhaft unter der neuen Adresse verfügbar; die alte ist nicht mehr gültig. Auch hier bleibt die ursprüngliche Methode erhalten. Das ist der wesentliche Unterschied zu 301.

Client-Fehler und nicht standardisierte Codes

4xx-Codes weisen auf fehlerhafte, unzulässige oder unvollständige Anfragen hin:

• 400 Bad Request: Die Anfragenachricht ist fehlerhaft aufgebaut.
• 401 Unauthorized: Eine gültige Authentifizierung ist erforderlich. Das „WWW-Authenticate“-Header-Feld erklärt das Verfahren.
• 402 Payment Required: Bezahlung ist erforderlich; der Status ist für zukünftige HTTP-Protokolle reserviert.
• 403 Forbidden: Die Anfrage wird wegen fehlender Berechtigung abgewiesen, etwa weil ein authentifizierter Benutzer nicht berechtigt ist oder eine als HTTPS konfigurierte URL mit HTTP aufgerufen wurde.
• 404 Not Found: Die Ressource wurde nicht gefunden; der Code kann auch ohne nähere Begründung zum Abweisen einer Anfrage verwendet werden. Verweise auf solche Fehlerseiten heißen tote Links.
• 405 Method Not Allowed: Die Ressource darf nur mit anderen HTTP-Methoden angesprochen werden, etwa GET statt POST. Zulässige Methoden stehen im „Allow“-Header.
• 406 Not Acceptable: Die Ressource ist nicht in der gewünschten Form verfügbar; mögliche „Content-Type“-Werte können angegeben werden.
• 407 Proxy Authentication Required: Vor dem Zugriff muss sich der Client beim Proxy authentifizieren; die Anleitung steht im „Proxy-Authenticate“-Header.
• 408 Request Timeout: Innerhalb der erlaubten Zeit wurde keine vollständige Anfrage empfangen.
• 409 Conflict: Die Anfrage beruht auf falschen Annahmen, etwa weil eine Ressource bei PUT inzwischen durch Dritte verändert wurde.
• 410 Gone: Die Ressource wurde dauerhaft entfernt.
• 411 Length Required: Das „Content-Length“-Header-Feld fehlt.
• 412 Precondition Failed: Eine übertragene Voraussetzung, etwa „If-Match“, ist nicht erfüllt.
• 413 Payload Too Large: Die Anfrage ist zu groß; „Retry-After“ kann auf eine spätere mögliche Verarbeitung hinweisen.
• 414 URI Too Long: Die URI beziehungsweise URL ist zu lang, oft wegen einer Endlosschleife aus Redirects.
• 415 Unsupported Media Type: Der Inhalt besitzt einen ungültigen oder nicht erlaubten Medientyp.
• 416 Range Not Satisfiable: Der angeforderte Teil einer Ressource ist ungültig oder nicht verfügbar.
• 417 Expectation Failed: Eine im „Expect“-Header verlangte Serverreaktion kann nicht erfüllt werden.
• 421 Misdirected Request: Die Anfrage wurde an einen Server gesendet, der nicht antworten kann; der Code wurde mit HTTP/2 eingeführt.
• 422 Unprocessable Entity: Die Anfrage ist nicht wegen 415 oder 400 abzulehnen, kann aber beispielsweise wegen semantischer Fehler nicht verarbeitet werden.
• 423 Locked: Die Ressource ist gesperrt.
• 424 Failed Dependency: Die Anfrage hängt vom Erfolg einer anderen Anfrage ab, die nicht erfolgreich war.
• 425 Too Early: Der Client soll die Anfrage erneut senden, weil die TLS-Verbindung noch nicht vollständig hergestellt ist; dies soll Replay-Angriffe verhindern.
• 426 Upgrade Required: Die Anfrage muss mit einem anderen Protokoll wiederholt werden, etwa mit HTTP mit Transport Layer Security.
• 428 Precondition Required: Erforderliche Vorbedingungen fehlen. Der Code soll Probleme durch Race Conditions verhindern, indem eine Änderung oder Löschung nur auf Basis einer aktuellen Ressource erfolgt, beispielsweise mit einem aktuellen ETag.
• 429 Too Many Requests: Der Client hat in einem bestimmten Zeitraum zu viele Anfragen gesendet.
• 431 Request Header Fields Too Large: Die Maximallänge eines Header-Felds oder des gesamten Headers wurde überschritten.
• 451 Unavailable For Legal Reasons: Die Ressource ist wegen gesetzlicher Bestimmungen, etwa Copyright-Einschränkungen oder Zensur, möglicherweise nur in einem bestimmten Land nicht verfügbar. Der Code wurde im Juni 2012 von Tim Bray bei der IETF eingereicht und gilt seit dem 17. Dezember 2015 als angenommen; die Zahl 451 spielt auf Ray Bradburys Roman Fahrenheit 451 an.

Weitere, nicht in der HTTP Status Code Registry aufgeführte Codes sind 418 „I’m a teapot“ aus einem scherzhaften RFC zum Hyper Text Coffee Pot Control Protocol, 420 „Policy Not Fulfilled“ aus einem W3C-PEP-Entwurf vom 21. November 1997, 444 „No Response“ aus nginx-Logs, 449 „The request should be retried after doing the appropriate action“ aus Antworten des Microsoft Exchange Servers sowie 499 „Client Closed Request“ für den Fall, dass ein Client während der Verarbeitung durch nginx die Verbindung schließt. 418 ist in der Registry als „Unused“ reserviert.

Server-Fehler und proprietärer Bereich

Bei 5xx liegt die Ursache eher beim Server, wobei die Grenze zu Client-Fehlern nicht eindeutig ist:

• 500 Internal Server Error: Sammelcode für unerwartete Serverfehler.
• 501 Not Implemented: Der Server stellt die für die Anfrage nötige Funktionalität nicht bereit, etwa eine unbekannte oder nicht unterstützte HTTP-Methode.
• 502 Bad Gateway: Ein Server als Gateway oder Proxy erhielt seinerseits eine ungültige Antwort.
• 503 Service Unavailable: Der Server ist vorübergehend nicht verfügbar, beispielsweise wegen Überlastung oder Wartung. „Retry-After“ kann einen möglichen späteren Zeitpunkt nennen.
• 504 Gateway Timeout: Ein Gateway oder Proxy erhielt innerhalb der festgelegten Zeit keine Antwort von benutzten Servern oder Diensten.
• 505 HTTP Version not supported: Die verwendete HTTP-Version, also die Zahl vor dem Punkt, wird nicht unterstützt oder abgelehnt.
• 506 Variant Also Negotiates: Die Inhaltsvereinbarung führt zu einem Zirkelbezug.
• 507 Insufficient Storage: Der Speicherplatz des Servers reicht derzeit nicht aus.
• 508 Loop Detected: Die Operation würde in eine Endlosschleife geraten. Der Code ist in der WebDAV-Binding-Erweiterung nach RFC 5842 definiert.
• 509 Bandwidth Limit Exceeded: Die Anfrage wurde verworfen, weil sonst die verfügbare Bandbreite überschritten würde. Dies ist eine inoffizielle Erweiterung mancher Server.
• 510 Not Extended: Die Anfrage enthält nicht alle Informationen, die eine angeforderte Server-Extension zwingend erwartet.
• 511 Network Authentication Required: Der Client muss sich zuerst authentifizieren, um Zugang zum Netzwerk zu erhalten.

Einige Hersteller verwenden außerdem den Bereich ab 900 für proprietäre Statuscodes. Dieser Zahlenbereich wird in den RFC-Dokumenten nicht erwähnt und liegt außerhalb der standardisierten Codes, sodass er leicht als Sonderfall erkennbar ist.