Status Codes beim HTTP-Response
Der in der Status-Zeile des HTTP-Response stehende dreistellige Status-Code gibt Auskunft über die Reaktion des WWW-Servers auf den vorhergehenden Request. Der hinter dem Status-Code stehende Text ist optional und wird bei der Auswertung des Status-Codes nicht beachtet. Dieser Text kann also wegfallen oder geändert werden, ohne die Reaktion des WWW-Client auf den vorhergehenden Request zu beeinträchtigen.
Die folgende Aufzählung gibt Auskunft über die Nummerierungslogik und über bereits standardisierte bzw. noch unbelegte Status-Codes:
Die erste Stelle des dreistelligen Status-Codes definiert die Art des Response:
1xx : | Informational | Momentan unbenutzt, aber reserviert für zukünftige Anwendungsfälle. |
2xx : | Success | Der Request wurde vollständig empfangen, verstanden und bearbeitet. |
3xx : | Redirection | Der Request kann noch nicht vollständig abgearbeitet werden, weitere Aktionen sind nötig. |
4xx : | Client Error | Der Request beinhaltet einen Syntax-Fehler oder kann nicht bearbeitet werden. |
5xx : | Server Error | Beim Bearbeiten des letzten gültigen Requests ist ein Server-Fehler aufgetreten. |
Die letzten beiden Stellen des Status-Codes beinhalten keinerlei Klassifizierungen. Im, zum Zeitpunkt der Entstehung dieser Arbeit, gültigen HTTP-Standard (HTTP/1.0 V5 – gültig bis 19. August 1996) sind folgende Status-Codes definiert:
Informational 1xx
In HTTP 1.0 sind keine 1xx-Status-Codes definiert. Sie sind lediglich provisorischer Art und für zukünftige Anwendungsfälle gedacht oder können bei experimentellen Anwendungen außerhalb des HTTP-Standards verwendet werden.
Successful 2xx
Ein 2xx-Status-Code bedeutet, daß der vorhergehende Request des Clients erfolgreich empfangen, verstanden und akzeptiert wurde.
200 OK
Der Request hatte Erfolg.
201 Created
Der Request wurde erfolgreich ausgeführt und die neue Ressource erzeugt. Diese kann mit dem/den im HTTP-Response angegebenen URL(s) referenziert werden. Die Ressource sollte allerdings vor Benutzung dieses Status-Codes erzeugt werden. Falls die zu erzeugende Ressource noch nicht erreichbar ist, muss der WWW-Server im Response-Body mitteilen, ab wann diese erreichbar ist; ansonsten sollte der 202-Status-Code verwendet werden.
Bei den in HTTP/1.0 spezifizierten Methoden kann nur POST eine Ressource erzeugen.
202 Accepted
Der Request wurde akzeptiert und bearbeitet, ist allerdings noch nicht fertig. Vorgesehen wurde dieser Status-Code für den Fall, daß ein Server einen Request annehmen kann, ohne ihn gleich vollständig abzuarbeiten (z.B. im Falle eines Batch-Betriebs, der nur einmal am Tag läuft). Der WWW-Client kann also den Erfolg seines Requests nicht sofort überprüfen (Anzeige im Client bei GET oder Existenz einer neuen Ressource bei POST), sondern erhält im Response-Body lediglich eine Meldung über den aktuellen Zustand der Bearbeitung und entweder einen Hinweis auf einen Status-Monitor oder eine Abschätzung, wann der Benutzer seinen Request als erfüllt betrachten kann.
204 No Content
Der Request wurde vollständig abgearbeitet, aber es gibt keine Informationen, die zurückgeschickt werden könnten. Bei einem Request durch einen Hyperlink von einer HTML-Seite aus würde sich die im WWW-Client dargestellte Seite (mit dem entsprechenden Hyperlink) also nicht ändern. Lediglich neue Metainformationen in Form von Response-Header-Feldern könnten zusammen mit dem Response übertragen werden. Diese sind dann zusammen mit den aktuell im WWW-Client abrufbaren Header-Informationen gültig.
Redirection 3xx
Ein Status-Code mit einer ‚3‘ an erster Stelle deutet darauf hin, daß zum Erfüllen des Requests weitere Aktionen des WWW-Clients erforderlich sind. Wenn die Methode des vorausgehenden Requests GET oder HEAD war, können die weiteren erforderlichen Aktionen des WWW-Clients ohne weitere Interaktion mit dem Benutzer durchgeführt werden. Um eine unendliche Schleife zu verhindern, darf ein WWW-Client eine solche, quasi automatische Weiterleitung (Redirection) nur maximal fünfmal durchführen.
300 Multiple Choices
Die im Request angesprochene Ressource ist mehrmals vorhanden. Außer bei einem vorhergehenden HEAD-Request, sollte der Response-Body eine Liste mit Beschreibungen und Adressen der vorhandenen Ressourcen beinhalten. Bei einer bevorzugten Alternative sollte der URL der entsprechenden Ressource-Alternative im „Location“-Feld des Response angegeben werden (für eine automatische Weiterleitung der Anfrage durch den WWW-Client).
301 Moved Permanently
Die im Request angeforderte Ressource ist permanent unter einem neuen URL zu finden. Der neue URL steht im Location-Feld. Außer bei einem HEAD-Request sollte im Response-Body eine kurze Mitteilung mit einem Hyperlink zum neuen URL stehen.
Bei einem vorangehenden POST-Request darf der WWW-Client keine automatische Weiterleitung durchführen (es sei denn, der Benutzer kann dieses bestätigen).
302 Moved Temporarily
Die im Request angeforderte Ressource ist vorübergehend unter einem neuen URL zu finden. Der neue URL steht im ‚Location‘-Feld. Da sich die Umadressierung wieder ändern kann, sollte der WWW-Client auch bei weiteren Requests den ‚alten‘ (Request ) URL benutzen. Außer bei einem HEAD-Request sollte im Response-Body eine kurze Mitteilung mit einem Hyperlink zum neuen URL stehen.
Bei einem vorangehenden POST-Request darf der WWW-Client keine automatische Weiterleitung durchführen (es sei denn, der Benutzer kann dieses bestätigen).
304 Not Modified
Bei einen GET-Request mit Datumsangabe im ‚If-Modified-Since‘-Request-Header antwortet der Server mit einem Response mit Status-Code 304 und ohne Response-Body, wenn das im Request referenzierte Dokument seit der entsprechenden Datumsangabe nicht geändert wurde.
Client Error 4xx
Diese Gruppe von Response-Status-Codes ist auf alle Request-Methoden anwendbar und wurde für Fälle vorgesehen, in denen der WWW-Client einen Fehler verursacht. Wenn der Client einen 4xx-Response empfängt, bevor er seinen Request vollständig abgeschickt hat, muss er sofort aufhören, Daten an den Server zu senden. Außer bei einem Head-Request sollte der Server im Response-Body eine Erklärung der Fehlersituation liefern.
400 Bad Request
Der vorangegangene Request konnte vom Server nicht verstanden werden – im allgemeinen wegen Syntax-Fehlern. Der WWW-Client sollte den Request nicht ohne Änderungen wiederholen.
401 Unauthorized
Der Request bedarf der Benutzer-Authentifizierung. Im ‚WWW-Authenticate‘-Header-Feld teilt der Server dem Client mit, welche Authentifizierung erforderlich ist. Der Client kann dann den Request mit der entsprechend zugehörenden Authentifizierung wiederholen.
403 Forbidden
Der Server hat den Request verstanden, kann ihn aber nicht ausführen. Die Authentifizierung hat nicht funktioniert, und der Request sollte nicht wiederholt werden. Wenn es kein Head-Request war und der Server bekannt geben möchte, warum der Request nicht ausgeführt werden konnte, kann er den Grund im Response-Body vermerken.
Normalerweise wird dieser Status-Code benutzt, wenn der Server den wahren Grund für die Ablehnung des Requests nicht bekannt geben will oder wenn alle anderen Response-Codes unzutreffend sind.
404 Not Found
Unter dem im Request angegebenen URL konnte nichts gefunden werden. Es gibt auch keinen Hinweis darauf, ob dieser Zustand dauerhaft oder temporär ist. Wenn der Server diese Information nicht publik machen möchte, kann statt dessen der Status-Code 403 (Forbidden) verwendet werden.
Server Error 5xx
Response-Status-Codes, die mit der Nummer ‚5‘ beginnen, bedeuten, daß der Server einen Fehler bemerkt hat oder unfähig ist, einen Request zu bearbeiten. Wenn der Client einen 5xx-Respond empfängt, bevor er seinen Request vollständig abgeschickt hat, dann muss er sofort aufhören, Daten an den Server zu senden. Außer bei einem Head-Request sollte der Server im Response-Body eine Erklärung der Fehlersituation liefern.
Diese Art von Response-Codes sind für alle Request-Methoden anwendbar und benötigen keinerlei Response-Header-Felder.
500 Internal Server Error
Ein unbekannter Fehler ist aufgetreten, der den Server daran hindert, den Request auszuführen.
501 Not Implemented
Der Server besitzt nicht die für die Erfüllung des Requests erforderliche Funktionalität. Dieser Response-Code wird immer dann benutzt, wenn der Server die verwendete Request-Methode nicht erkennt und nicht fähig ist, diese Methode bezüglich irgendeiner Ressource anzuwenden.
502 Bad Gateway
Wenn ein Server als Gateway oder Proxy konfiguriert ist und einen ungültigen Response eines vorgelagerten Servers erhält, setzt er diesen Response-Code, um den Request trotzdem behandeln zu können.
503 Service Unavailable
Diesen Response-Code sendet ein Server, der z.B. aufgrund zu hoher Auslastung oder Installationsarbeiten momentan nicht in der Lage ist, einen Request zu erfüllen. Dieser Status-Code ist für kurzfristige Zustände vorgesehen, die sich nach einiger Zeit wieder bereinigen.