Ein HTTP-Statuscode wird von einem Server auf jede HTTP-Anfrage als Antwort geliefert. Auf der anfragenden Seite steht dabei ein Client wie beispielsweise ein Webbrowser. Der Server teilt durch den HTTP-Statuscode dem Client mit, ob die Anfrage erfolgreich bearbeitet wurde. Im Fehlerfall gibt der Statuscode Auskunft darüber, wo (beispielsweise über eine Umleitung) oder wie (zum Beispiel mit Authentifizierung) er die gewünschten Informationen erhalten kann. Am bekanntesten sind dabei die Codes 404: „Nicht gefunden“, 403: „Fehlende Zugriffsberechtigung“ und 400: „Fehlerhafte Anfrage“.
Die erste Ziffer eines Statuscodes stellt die Statusklasse dar. Sie sind in RFC 9110[1] (ersetzt RFC 2616[2]), sowie RFC 2518,[3] RFC 2817,[4] RFC 2295,[5] RFC 2774[6] und RFC 4918[7] spezifiziert. Einige gehören zum Distributed Authoring (WebDAV).
Neben den in RFC standardisierten Statuscodes verwenden manche Softwarehersteller auch proprietäre Codes für eigens definierte Status- und Fehlermeldungen. Andere Software kann dem Benutzer diese Codes nur als allgemeinen unbekannten Fehler anzeigen; nicht aber eine Übersetzung und Hinweise zum weiteren Vorgehen. Teilweise können die Server den Begleitumständen der Anfrage bereits entnehmen, dass es sich um die zugehörige Spezialsoftware handelt, und geben nur dann die proprietären Codes zurück. In diesem Artikel sind einige proprietäre Codes aufgeführt und entsprechend gekennzeichnet.
Die Bearbeitung der Anfrage dauert noch an.
Die Anfrage war erfolgreich, die Antwort kann verwertet werden.
Um eine erfolgreiche Bearbeitung der Anfrage sicherzustellen, sind weitere Schritte seitens des Clients erforderlich.
Die Ursache des Scheiterns der Anfrage liegt (eher) im Verantwortungsbereich des Clients.
Er wurde im Juni 2012 von Google-Mitarbeiter Tim Bray bei der IETF eingereicht[21] und gilt seit dem 17. Dezember 2015 als angenommen.[22] Bray schlug die Nummer 451 in Anspielung auf Ray Bradburys Roman Fahrenheit 451 vor und fügte einen Dank an den Autor an.[23]
Nicht klar von den so genannten Client-Fehlern abzugrenzen. Die Ursache des Scheiterns der Anfrage liegt jedoch eher im Verantwortungsbereich des Servers.
Manche Softwarehersteller verwenden den Bereich ab 900 für proprietäre Statuscodes.[30] Dieser Zahlenbereich wurde in den RFC-Dokumenten nie erwähnt und liegt offensichtlich jenseits der standardisierten Codes. Dadurch ist er leicht als Sonderfall erkennbar.
Die folgenden Caching-Warncodes wurden in RFC 7234 festgelegt. Im Gegensatz zu den anderen oben genannten Statuscodes wurden diese nicht als Antwortstatus im HTTP-Protokoll gesendet, sondern als Teil des HTTP-Headers Warning.[31][32]
Warning
Da dieser "Warning"-Header häufig weder von den Servern gesendet noch von den Clients bestätigt wird, wurden dieser Header und seine Codes von der HTTP-Arbeitsgruppe im Jahr 2022 mit RFC 9111 überflüssig gemacht.[33]
Der Webserver Internet Information Services (IIS) von Microsoft erweitert den 4xx-Fehlerbereich, um Fehler bei der Anfrage des Clients zu signalisieren.
IIS verwendet manchmal zusätzliche dezimale Sub-Codes für spezifischere Informationen. Diese Sub-Codes erscheinen jedoch nur in der Nutzlast der Antwort und in der Dokumentation, nicht anstelle eines eigentlichen HTTP-Status-Codes.
Der Reverse-Proxy-Dienst von Cloudflare erweitert den 5xx-Fehlerbereich, um Probleme mit dem Ursprungsserver zu signalisieren.
curl
curl -kI https://www.linkedin.com/company/linkedin/