| ## HTTP-Statuscodes
| Allgemeines zu HTTP-Statuscodes Übersicht der HTTP-Statuscodes

## Allgemeines zu HTTP-Statuscodes

Wenn ein Web-Browser über das HTTP-Protokoll einen URI aufruft, erhält der Web-Server, 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 herauskommt, übermittelt der Server in den HTTP-Kopfdaten der Antwort an den Browser eine Zahl. 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 beispielsweise Fehlermeldungen übermittelt, aber auch Hinweise wie "die angeforderten Daten sind zugangsgeschützt". Der Browser kann den Statuscodes auswerten und entsprechend reagieren. Der Web-Server schreibt den HTTP-Statuscode der Anfrage außerdem in seine Log-Dateien.

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

- In den Log-Dateien des Web-Servers können Sie sich einen Eindruck davon machen, 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-Statuscodes auf. Dabei ist es hilfreich, die einzelnen Statuscodes, ihre Bedeutung und mögliche Ursachen für ihr Vorkommen zu kennen.
- CGI-Scripts können selber HTTP-Header erzeugen. Dabei können Sie auch HTTP-Statuscodes notieren, die als Antwort an den aufrufenden Browser gesendet werden sollen. Der Web-Server 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-Statuscodes 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 aktuelle Informationen rund um die Normierung des HTTP-Protokolls aufrufen:

HTTP - Hypertext Transfer Protocol

## Übersicht der HTTP-Statuscodes

Statuscode | 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 Web-Server sollte mit diesem Statuscode 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 Statuscode 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 Statuscode 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 angegebene Server existiert nicht bzw. der Server, der diese Antwort gibt, ist nicht der angefragte Server und kann den angefragten Server nicht finden. Die angeforderten Daten können deshalb nicht versendet werden.
`206` | `Partial Content` | Die angeforderten Daten werden in mehreren Portionen versendet (das hat aber nichts mit TCP/IP-Paketen zu tun, sondern passiert auf HTTP-Protokollebene). 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.
`300` | `Multiple Choices` | Die angeforderten Daten sind unter mehreren verschiedenen URIs vorhanden (Mirror). Anstelle der Daten werden die verfügbaren URIs als Liste übertragen. Der Web-Browser kann den Anwender anschließend in einem Dialog einen URI auswählen lassen.
`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 Temporarialy` | 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 sollte von dort mit Hilfe der `get`-Methode angefordert werden. Dieser Statuscode 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 Statuscode ist neben dem Code `200` einer der häufigsten in der Praxis. Er wird verursacht durch Web-Browser, die aufgrund ihrer Cache-Einstellungen Daten erst wieder nach einer bestimmten Zeit vom Original-Server laden. Davor fragen sie nur mit dem Zeitpunkt, zu dem die Daten zuletzt geladen wurden, an, ob die Daten auf dem Server seitdem geändert wurden.
`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 Statuscode `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 die Anfrage dadurch zustande kam, dass ein Anwender versuchte, einen URI händisch in die Adresszeile des Browsers einzugeben und dabei ungültige Zeichen verwendete.
`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 htacess zugangsgeschützt ist. Der Web-Browser zeigt dann, nachdem er diesen Statuscode 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` | Die angeforderten Daten sind zugangsgeschützt. Die angegebenen Daten, mit denen der Zugang erlaubt werden soll, sind ungültig. Das kann z.B. vorkommen, wenn zuvor der Statuscode `401` zurückgeliefert worden war und der Browser nun die nächste Anfrage mit den Zugangsdaten gestartet hat, die er vom Anwender im Dialog abgefragt hat, und diese Daten aber ungültig sind. Manche Web-Browser wiederholen den Dialog zum Eingeben der Zugangsdaten dann noch zwei mal, und nach der dritten Falscheingabe wird dem Anwender die Fehlermeldung "Forbidden" ausgegeben.
`404` | `Not Found` | Der angeforderte URI existiert nicht. Dies ist neben den Statuscodes `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, und 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 Web-Servers 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` | Der anfragende Client ist ein Proxy-Server. Die Daten werden an diesen Server nur übertragen, wenn er sich als gültiger Proxy-Server ausweist. Dieser Statuscode findet derzeit noch keine Verwendung. Damit soll auf die Dauer ein ähnliches Handling wie mit dem Statuscode `401` etabliert werden, jedoch nicht für anfragende Browser, sondern für anfragende Proxy-Server. Auf diese Weise könnte es Web-Anbietern möglich werden, in der Serverkonfiguration unerwünschte Proxy-Server vom Zwischenspeichern der eigenen Daten auszusperren.
`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 nicht 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 Statuscode `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 kann die Anfrage nicht bearbeiten, weil er keinen Mime-Type für den angeforderten Datentyp kennt. 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 Bytebereichs, z.B. wenn ein Bytebereich 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 Voraussetzunen 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 Statuscode `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.

| Mime-Typen
| Rechtliche Aspekte von Web-Projekten

© 2001 selfhtml@teamone.de