# HTTP-Status-Codes

| Allgemeines zu HTTP-Status-Codes Übersicht der HTTP-Status-Codes

## Allgemeines zu HTTP-Status-Codes

Wenn ein Web-Browser über das HTTP-Protokoll einen URI aufruft, erhält der Webserver, der für die aufgerufene Domain oder IP-Adresse zuständig ist, die Anfrage. Er ermittelt die gewünschten Daten auf dem Server-Rechner und sendet diese - wieder über das HTTP-Protokoll - an den wartenden Web-Browser. Je nachdem wie die Anforderung des Web-Browsers lautete und welches Ergebnis beim Ermitteln der Daten auf dem Server-Rechner herauskam, schickt der Server in den HTTP-Kopfdaten der Antwort eine bestimmte Zahl an den aufrufenden Browser. Diese Zahl stellt einen Status-Code dar und gibt Auskunft darüber, in welchem Verhältnis das, was der Server an Daten ausliefert, zu der gewünschten Anforderung steht. Auf diese Weise werden Fehlermeldungen übermittelt, aber auch Hinweise wie "die angeforderten Daten sind zugangsgeschützt". Der Browser kann diese Status-Codes auswerten, dem Benutzer darstellen und entsprechend reagieren. Der Webserver schreibt den HTTP-Status-Code der Anfrage außerdem bei entsprechender Konfiguration in seine Log-Dateien.

HTTP-Status-Codes sind für Sie als Web-Anbieter an folgenden Stellen interessant:

- In den Log-Dateien des Webservers können Sie sich darüber informieren, welche Fehler und Probleme in letzter Zeit auffällig oft auftauchten. Auch die meisten Statistiken zu Web-Projekten schlüsseln die Gesamtzahlen unter anderem nach HTTP-Status-Codes auf. Dabei ist es hilfreich, die einzelnen Status-Codes, ihre Bedeutung und mögliche Ursachen für ihr Vorkommen zu kennen.
- CGI-Scripts können selbst HTTP-Header erzeugen. Dabei können Sie auch HTTP-Status-Codes notieren, die als Antwort an den aufrufenden Browser gesendet werden sollen. Der Webserver reicht die Angaben dann an den Browser durch. Wie so etwas in einem CGI-Script mit Perl funktioniert, wird im Abschnitt Erweiterte Angaben für HTTP-Header und HTML-Dateikopf (im Zusammenhang mit dem CGI-Modul von Perl) beschrieben.

Die HTTP-Status-Codes gehören zur Spezifikation des HTTP-Protokolls. Zuständig für die Spezifikation ist das W3-Konsortium. Die Spezifikation erfolgt in Form von Requests for Comments (RFCs). Über die folgende Seite des W3-Konsortiums können Sie alle relevanten und aktuellen Informationen rund um die Normierung des HTTP-Protokolls aufrufen:

HTTP - Hypertext Transfer Protocol

## Übersicht der HTTP-Status-Codes

Status-Code | zugehörige Meldung | Bedeutung
--- | --- | ---
`100` | `Continue` | Fortfahren. Wird derzeit noch nicht verwendet.
`101` | `Switching Protocols` | Protokoll wechseln. Wird derzeit noch nicht verwendet.
`200` | `OK` | Der Server kann die angeforderten Daten wie gewünscht versenden. Dies ist der Normalfall, wenn keine Probleme auftauchen. Der größere Anteil aller Anfragen an den Webserver sollte mit diesem Status-Code enden - ansonsten stimmt etwas nicht.
`201` | `Created` | Ein Objekt (z.B. eine Datei oder ein Verzeichnis) wurde auf dem Server erfolgreich angelegt. Das kann vorkommen, wenn die Anfrage des Browsers an den Server mit einer der HTTP-Übertragungsmethoden `post` oder `put` erfolgte und eine Anweisung zum Erstellen des entsprechenden Objekts enthielt.

`202`

`Accepted`

Der Server hat die Anfrage des Browsers akzeptiert, liefert aber keine Daten als Antwort. Der Server schreibt die Daten statt sie zu senden in eine Datei und teilt in der Meldung mit, wo die Daten später zu finden sein werden. Diese Meldung sagt nichts darüber aus, ob der Server die Anfrage erfolgreich behandeln kann. Er hat sie einfach nur akzeptiert und die Abarbeitung auf einen späteren Zeitpunkt verschoben.

`203`

`Non-Authoritative Information`

Dieser Status-Code sollte von einem Server anstelle von `200` zurückgegeben werden, wenn es sich nicht um den Original-Server handelt, sondern beispielsweise um einen Proxy-Server. Der Web-Browser erfährt auf diese Weise, dass die Daten erfolgreich gesendet werden konnten, aber nicht vom Original-Server kommen und daher keine Garantie auf deren Aktualität besteht.

`204` | `No Content` | Der Server hat die Anfrage erhalten, sendet jedoch keine Daten zurück. Gut verwendbar ist dieser Status-Code bei Verwendung in CGI-Scripts, die zwar etwas auf dem Server erledigen, aber keinen neuen HTML-Code an den aufrufenden Browser senden wollen. Aus Sicht des Anwenders bleibt der alte Bildschirminhalt bestehen.
`205` | `Reset Content` | Der Server hat die Anfrage ausgeführt, muss aber keine Daten zurücksenden. Stattdessen sollte der Browser den Bildschirminhalt, der zu der Anfrage geführt hat, zurücksetzen. Das ist vor allem im Zusammenhang mit serverseitigen Skripten sinnvoll, wenn der Benutzer mehrere Eingaben über das gleiche Formular machen soll, und sich dieses zwischenzeitlich nicht ändert.

`206`

`Partial Content`

Der Client hat nur einen Teil der Daten angefordert und der Server versendet diese wie gewüscht. Mit Angaben zu `content-length` (z.B.: `1024`) und `content-range` (z.B.: `bytes 0-1023/1024`) wird angegeben, wie viele Bytes von dem angeforderten Inhalt geliefert werden, und welcher Teil der Gesamtdaten. Das passiert zum Beispiel, wenn ein vorangegangener Download unterbrochen wurde und der Client an der Abbruchstelle erneut mit dem Herunterladen beginnt.

`300` | `Multiple Choices` | Die angeforderten Daten liegen in mehreren verschiedenen Ausführungen vor. Anstelle der Daten werden die verfügbaren URIs und ihre Eigenschaften (zum Beispiel Sprache oder MIME-Typ) als Liste übertragen. Der Web-Browser kann den Anwender anschließend in einem Dialog einen URI auswählen lassen oder die Auswahl automatisch treffen.
`301` | `Moved Permanently` | Die angeforderten Daten befinden sich nicht mehr unter dem URI, sie wurden dauerhaft auf eine andere Adresse verschoben. In der Statusmeldung wird angegeben, unter welchem URI sich die Daten jetzt befinden. Ein Web-Browser, der diese Antwort vom Server erhält, kann beispielsweise gleich die neue Adresse anfordern.
`302` | `Moved Temporarily` | Die angeforderten Daten wurden vorübergehend zu einem anderen URI verschoben. In der Statusmeldung wird angegeben, unter welcher Adresse sich die Daten derzeit befinden. Ein Web-Browser, der diese Antwort erhält, kann beispielsweise gleich die temporär gültige Adresse anfordern.
`303` | `See Other` | Die angeforderten Daten sind unter einem angegebenen URI verfügbar und sollten von dort mit Hilfe der `get`-Methode angefordert werden. Dieser Status-Code ist für CGI-Scripts gedacht, die mit der `post`-Methode aufgerufen wurden und den Browser auf eine andere Ressource lenken wollen, die mit der `get`-Methode angefordert werden soll.

`304`

`Not Modified`

Die angeforderten Daten haben sich seit dem angegebenen Zeitpunkt nicht geändert und werden deshalb nicht gesendet. Dieser Status-Code ist neben dem Code `200` einer der häufigsten in der Praxis. Er tritt auf, wenn ein moderner Webbrowser, der die Daten noch im Cache hat, eine Anfrage an den Server sendet und dabei den Ladezeitpunkt der Daten in seinem Cache übermittelt. Stellt der Server dann fest, dass sich die Daten seit dem angegebenen Zeitpunkt nicht geändert haben, braucht er sie nicht noch einmal zu übermitteln, sondern sendet nur diesen Statuscode und keine Daten. Der Browser holt daraufhin seine alte Version aus dem Cache.

`305` | `Use Proxy` | Die angeforderten Daten sollen statt von diesem Server von dem in der Statusmeldung angegebenen Proxy-Server angefordert werden.
`306` | `[Unused]` | Reserviert. Wird derzeit aber nicht verwendet.
`307` | `Temporary Redirect` | Wie Status-Code `302`. Gedacht für Fehlreaktionen einiger Browser auf `302`.
`400` | `Bad Request` | Die Anfrage enthält Syntaxfehler. Der Server kann die Anfrage deshalb nicht bearbeiten. Das kann beispielsweise vorkommen, wenn der verwendete Browser einen Programmierfehler aufweist und ungültige Anfragen sendet, oder ein Mensch versucht, händisch (also etwa mit telnet) mit dem Server zu kommunizieren und dabei einen Fehler macht.

`401`

`Unauthorized`

Die angeforderten Daten sind zugangsgeschützt. Der Server kann die Daten nur senden, wenn eine gültige Zugangskennung, bestehend aus Benutzername und Passwort, bei der Anfrage mit gesendet wird. Das passiert in der Praxis immer dann, wenn eine Adresse aufgerufen wird, die z.B. durch htaccess zugangsgeschützt ist. Der Web-Browser zeigt dann, nachdem er diesen Status-Code erhalten hat, einen Dialog zum Eingeben von Benutzername und Kennwort an. Mit den eingegebenen Daten startet er dann eine neue Anfrage an den Server.

`402` | `Payment Required` | Die angeforderten Daten sind kostenpflichtig. Der Server kann die Daten nur senden, wenn eine Bestätigung der Zahlung für die Daten bei der Anfrage mitgesendet wird. Derzeit wird dies aufgrund fehlender einheitlicher technischer Grundlagen für Micropayment noch nicht verwendet.

`403`

`Forbidden`

Der Server möchte die angeforderten Daten nicht herausgeben. Das passiert zum Beispiel wenn der Zugriff auf die Ressource von dem IP-Adress-Bereich, aus dem die Anfrage kommt, in der Serverkonfiguration verboten wurde, die Ressource ganz und gar gesperrt wurde oder man versucht, ein Verzeichnislisting zu bekommen, dies jedoch in der Serverkonfiguration abgeschaltet wurde. Dies ist ein anderer Status als 401! Weder die Eingabe eines Passwortes noch das Wiederholen der Anfrage wird etwas bewirken.

`404`

`Not Found`

Der angeforderte URI existiert nicht. Dies ist neben den Status-Codes `200` und `304` einer der häufigsten Fälle in der Praxis. Er tritt immer dann ein, wenn ein Verweis auf eine nicht oder nicht mehr existierende Adresse auf dem Server führt, oder wenn der Anwender versucht hat, eine Adresse auf dem Server durch händisches Eintippen in der Adresszeile des Browsers aufzurufen, diese Adresse aber nicht existiert.

`405` | `Method Not Allowed` | Die angegebene Übertragungsmethode ist auf dem Server nicht erlaubt. Die Daten werden deshalb nicht übertragen. Das kann beispielsweise vorkommen, wenn in der Konfiguration des Webservers außer der `get`-Methode keine weitere Methode erlaubt ist, ein HTML-Formular aber einen CGI-Aufruf mit der `post`-Methode enthält.
`406` | `Not Acceptable` | Die Anfrage ist in dieser Form nicht akzeptabel. Die Daten werden deshalb nicht übertragen.

`407`

`Proxy Authentication Required`

Die Anfrage soll über einen Proxy-Server geleitet werden. Der Proxy-Server ist aber zugangsgeschützt und leitet Anfragen erst nach dem Erhalt einer gültigen Zugangskennung weiter, die in der Regel aus Benutzername und Passwort besteht. Beim Erhalt dieses Status-Codes verhält sich der Client ähnlich wie beim Status-Code 401, mit dem Unterschied, dass die Authentifizierung für den Proxy-Server gilt und nicht für den Zielserver. Das wird in der Praxis zum Beispiel in größeren Installationen wie Firmen oder Universitäten eingesetzt, wo der Zugriff auf das Intranet frei ist, nach aussen gehende Anfragen aber bestimmte Berechtigungen benötigen und zwangsweise durch einen Proxy-Server geleitet werden.

`408` | `Request Timeout` | Der Server hat eine erwartete Anfrage nicht innerhalb des dafür festgelegten Maximalzeitraums erhalten. Die Verbindung zum anfragenden Browser wird deshalb abgebaut. Angeforderte Daten werden nicht übertragen.
`409` | `Conflict` | Der Server kann die angeforderten Daten nicht senden, weil ein Konflikt mit einem anderen Prozess aufgetaucht ist. Das kann beispielsweise passieren, wenn ein anderer Prozess eine angeforderte Datei gerade mit einem exklusiven File-Locking (keinerlei Dateizugriff für andere Prozesse erlaubt) versehen hat.
`410` | `Gone` | Die angeforderten Daten wurden zu einem anderen URI verschoben. Dem Server ist aber nicht bekannt, wohin. Deshalb kann er sie nicht senden - andernfalls würde ein Status-Code `301` oder `302` gesendet worden.
`411` | `Length Required` | Die Daten werden nicht gesendet. Sie können nur gesendet werden, wenn die Anfrage eine Angabe zu `content-length` enthält. Der Browser kann versuchen, die Anfrage neu zu formulieren und dabei die Länge der an den Server gesendeten Anfragedaten mit zu übermitteln.
`412` | `Precondition Failed` | Eine oder mehrere Bedingungen, die bei der Anfrage gestellt wurden, treffen nicht zu. Die angeforderten Daten werden deshalb nicht übertragen.
`413` | `Request Entity Too Large` | Der Server kann die Anfrage nicht bearbeiten, weil diese zu viele Zeichen enthält. Die angeforderten Daten werden deshalb nicht übertragen.
`414` | `Request-URL Too Long` | Der Server kann die Anfrage nicht bearbeiten, weil die angeforderte Adresse zu viele Zeichen enthält. Die angeforderten Daten werden deshalb nicht übertragen.
`415` | `Unsupported Media Type` | Der Server will die Anfrage nicht bearbeiten, weil der MIME-Typ, den der Client in der Anfrage verwendet hat, für diese Anfrage nicht unterstützt wird. Die angeforderten Daten werden deshalb nicht übertragen.

`416`

`Requested Range Not Satisfiable`

Die Anfrage enthält Angaben, welcher Byte-Bereich von dem angeforderten URI übertragen werden soll. Sowohl der Anfangswert als auch der Endwert des angegebenen Bereichs liegen außerhalb des verfügbaren Byte-Bereichs, z.B. wenn ein Byte-Bereich von 1000 bis 2000 angegeben wird, die Ressource aber nur 500 Byte hat. Die angeforderten Daten werden deshalb nicht übertragen.

`417` | `Expectation Failed` | Die Anfrage enthält im `expect`-Feld bestimmte Wünsche, die der Server nicht erfüllen kann. Die angeforderten Daten werden deshalb nicht übertragen.
`500` | `Internal Server Error` | Der Server kann die angeforderten Daten nicht senden, weil auf dem Server ein Fehler aufgetreten ist. Beispielsweise konnte das aufgerufene CGI-Script nicht gestartet werden.
`501` | `Not Implemented` | Die Anfrage enthält Anforderungen, die der Server nicht bearbeiten kann, weil die Voraussetzungen dazu nicht implementiert sind. Die angeforderten Daten können deshalb nicht gesendet werden.
`502` | `Bad Gateway` | Zum Bearbeiten der Anfrage musste der Server einen anderen Server aufrufen, erhielt dabei jedoch eine Fehlermeldung. Die angeforderten Daten können deshalb nicht gesendet werden.
`503` | `Service Unavailable` | Der Server kann die Anfrage wegen Überlastung nicht bearbeiten. Die angeforderten Daten können deshalb nicht gesendet werden. In der Statusmeldung kann stehen, wann die Anfrage frühestens wieder bearbeitet werden kann. Im Gegensatz zum Status-Code `202` verarbeitet der Server die Daten nicht, sobald er wieder Kapazitäten hat.
`504` | `Gateway Timeout` | Zum Bearbeiten der Anfrage musste der Server einen anderen Server aufrufen, erhielt dabei jedoch nach einem festgelegten Maximalzeitraum keine Antwort. Die angeforderten Daten können deshalb nicht gesendet werden.
`505` | `HTTP Version Not Supported` | Der Server unterstützt die im HTTP-Header der Anfrage angegebene HTTP-Version nicht. Die angeforderten Daten werden deshalb nicht gesendet.

| CGI und HTML
| Andere Webserver

© 2007 Impressum