HTTP-Statuscodes

Diese Zwischennachricht zeigt an, dass der Client die Anfrage fortsetzen oder die Antwort ignorieren sollte, wenn die Anfrage bereits abgeschlossen ist.

Dieser Code wird als Antwort auf einen Upgrade-Anfrageheader vom Client gesendet und zeigt das Protokoll an, zu dem der Server wechselt.

Dieser Code wurde in WebDAV-Kontexten verwendet, um anzuzeigen, dass eine Anfrage vom Server empfangen wurde, aber zum Zeitpunkt der Antwort kein Status verfügbar war.

Dieser Statuscode ist hauptsächlich dafür vorgesehen, mit dem Link-Header verwendet zu werden, damit der Benutzeragent Ressourcen vorladen kann, während der Server eine Antwort vorbereitet, oder um zu einer Quelle vorzubereiten, von der die Seite Ressourcen benötigt.

Die Anfrage war erfolgreich. Das Ergebnis und die Bedeutung von "Erfolg" hängen von der HTTP-Methode ab:

• GET: Die Ressource wurde abgerufen und im Nachrichtenrumpf übermittelt.
• HEAD: Repräsentations-Header sind in der Antwort enthalten, ohne Nachrichtenrumpf.
• PUT oder POST: Die Ressource, die das Ergebnis der Aktion beschreibt, wird im Nachrichtenrumpf übermittelt.
• TRACE: Der Nachrichtenrumpf enthält die Anfrage, wie sie vom Server empfangen wurde.

Die Anfrage war erfolgreich und eine neue Ressource wurde als Ergebnis erstellt. Dies ist typischerweise die Antwort, die nach POST-Anfragen gesendet wird, oder einige PUT-Anfragen.

Die Anfrage wurde empfangen, aber noch nicht bearbeitet. Es ist unverbindlich, da es im HTTP-Protokoll keine Möglichkeit gibt, später eine asynchrone Antwort zu senden, die das Ergebnis der Anfrage angibt. Sie ist für Fälle vorgesehen, in denen ein anderer Prozess oder Server die Anfrage verarbeitet, oder für die Stapelverarbeitung.

Dieser Antwortcode bedeutet, dass die zurückgegebenen Metadaten nicht genau die gleichen sind wie diejenigen, die vom Ursprungsserver verfügbar sind, sondern von einer lokalen oder einer Drittanbieter-Kopie gesammelt wurden. Dies wird meist zur Spiegelung oder Sicherung einer anderen Ressource verwendet. Außer in diesem speziellen Fall wird die 200 OK-Antwort diesem Status vorgezogen.

Es gibt keinen Inhalt, der für diese Anfrage gesendet werden könnte, aber die Header sind nützlich. Der Benutzeragent kann seine zwischengespeicherten Header für diese Ressource mit den neuen aktualisieren.

Weist den Benutzeragenten an, das Dokument zurückzusetzen, das diese Anfrage gesendet hat.

Dieser Antwortcode wird als Antwort auf eine Bereichsanfrage verwendet, wenn der Client einen Teil oder Teile einer Ressource angefordert hat.

Übermittelt Informationen zu mehreren Ressourcen, für Situationen, in denen mehrere Statuscodes zutreffend sein könnten.

Wird innerhalb eines <dav:propstat>-Antwortelements verwendet, um zu vermeiden, die internen Mitglieder mehrerer Bindungen zu derselben Sammlung wiederholt aufzuzählen.

Der Server hat eine GET-Anfrage für die Ressource erfüllt und die Antwort ist eine Darstellung des Ergebnisses einer oder mehrerer Instanz-Manipulationen, die auf die aktuelle Instanz angewendet wurden.

Bei der agentengesteuerten Inhaltsverhandlung hat die Anfrage mehr als eine mögliche Antwort und der Benutzeragent oder Benutzer sollte eine davon auswählen. Es gibt keine standardisierte Methode für Clients, automatisch eine der Antworten auszuwählen, daher wird dies selten verwendet.

Die URL der angeforderten Ressource wurde dauerhaft geändert. Die neue URL wird in der Antwort angegeben.

Dieser Antwortcode bedeutet, dass sich die URI der angeforderten Ressource vorübergehend geändert hat. Weitere Änderungen an der URI könnten in der Zukunft vorgenommen werden, daher sollte die gleiche URI vom Client bei zukünftigen Anfragen verwendet werden.

Der Server hat diese Antwort gesendet, um den Client zu veranlassen, die angeforderte Ressource an einer anderen URI mit einer GET-Anfrage abzurufen.

Dies wird für Caching-Zwecke verwendet. Es teilt dem Client mit, dass die Antwort nicht modifiziert wurde, sodass der Client dieselbe zwischengespeicherte Version der Antwort weiter verwenden kann.

In einer früheren Version der HTTP-Spezifikation definiert, um anzuzeigen, dass auf eine angeforderte Antwort über einen Proxy zugegriffen werden muss. Es wurde aufgrund von Sicherheitsbedenken bezüglich der Konfiguration eines Proxy in-band veraltet.

Dieser Antwortcode wird nicht mehr verwendet, ist aber reserviert. Er wurde in einer früheren Version der HTTP/1.1-Spezifikation verwendet.

Der Server sendet diese Antwort, um den Client anzuweisen, die angeforderte Ressource an einer anderen URI mit derselben Methode abzurufen, die in der vorherigen Anfrage verwendet wurde. Dies hat die gleichen Semantik wie der Antwortcode 302 Found, mit der Ausnahme, dass der Benutzeragent die verwendete HTTP-Methode nicht ändern darf: Wenn in der ersten Anfrage eine POST verwendet wurde, muss in der umgeleiteten Anfrage auch eine POST verwendet werden.

Dies bedeutet, dass die Ressource nun dauerhaft an einer anderen URI befindet, die durch den Location-Antwortheader angegeben wird. Dies hat die gleichen Semantik wie der HTTP-Antwortcode 301 Moved Permanently, mit der Ausnahme, dass der Benutzeragent die verwendete HTTP-Methode nicht ändern darf: Wenn in der ersten Anfrage eine POST verwendet wurde, muss in der zweiten Anfrage auch eine POST verwendet werden.

Der Server kann oder wird die Anfrage nicht aufgrund von etwas, das als Client-Fehler angesehen wird (z.B. fehlerhafte Anfragesyntax, ungültige Anfragennachricht-Rahmung oder täuschende Anfragenweiterleitung), verarbeiten.

Obwohl der HTTP-Standard "unauthorized" spezifiziert, bedeutet diese Antwort semantisch "unauthenticated". Das heißt, der Client muss sich authentifizieren, um die angeforderte Antwort zu erhalten.

Der ursprüngliche Zweck dieses Codes war für digitale Zahlungssysteme, jedoch wird dieser Statuscode selten verwendet und es gibt keine Standardkonvention.

Der Client hat keine Zugriffsrechte für den Inhalt; das heißt, dass sie nicht autorisiert sind und der Server daher die angeforderte Ressource nicht bereitstellen wird. Im Gegensatz zu 401 Unauthorized ist die Identität des Clients dem Server bekannt.

Der Server kann die angeforderte Ressource nicht finden. Im Browser bedeutet das, dass die URL nicht erkannt wird. In einer API kann dies auch bedeuten, dass der Endpunkt gültig ist, aber die Ressource selbst nicht existiert. Server können diese Antwort auch anstelle von 403 Forbidden senden, um das Vorhandensein einer Ressource vor einem nicht autorisierten Client zu verbergen. Dieser Antwortcode ist aufgrund seines häufigen Auftretens im Web wahrscheinlich der bekannteste.

Die Anfragemethode ist dem Server bekannt, wird jedoch von der Zielressource nicht unterstützt. Beispielsweise darf eine API DELETE auf einer Ressource nicht erlauben oder die TRACE-Methode insgesamt.

Diese Antwort wird gesendet, wenn der Webserver nach Durchführung der server-gesteuerten Inhaltsverhandlung keinen Inhalt findet, der den vom Benutzeragenten gegebenen Kriterien entspricht.

Dies ist ähnlich wie 401 Unauthorized, jedoch muss die Authentifizierung von einem Proxy durchgeführt werden.

Diese Antwort wird von einigen Servern auf einer inaktiven Verbindung gesendet, selbst ohne vorherige Anfrage durch den Client. Es bedeutet, dass der Server diese ungenutzte Verbindung beenden möchte. Diese Antwort wird viel häufiger verwendet, da einige Browser HTTP-Vorverbindungsmechanismen verwenden, um das Browsen zu beschleunigen. Einige Server können eine Verbindung ohne das Senden dieser Nachricht beenden.

Diese Antwort wird gesendet, wenn eine Anfrage mit dem aktuellen Zustand des Servers in Konflikt steht. Bei WebDAV Remote-Web-Autoren sind 409-Antworten Fehler, die an den Client gesendet werden, damit ein Benutzer möglicherweise einen Konflikt lösen und die Anfrage erneut senden kann.

Diese Antwort wird gesendet, wenn der angeforderte Inhalt dauerhaft vom Server gelöscht wurde, ohne eine Weiterleitungsadresse. Clients sollten ihre Caches und Links zur Ressource entfernen. Die HTTP-Spezifikation sieht vor, dass dieser Statuscode für "zeitlich begrenzte, werbende Dienste" verwendet wird. APIs sollten sich nicht verpflichtet fühlen, Ressourcen, die gelöscht wurden, mit diesem Statuscode anzugeben.

Der Server hat die Anfrage abgelehnt, da das Content-Length-Header-Feld nicht definiert ist und der Server dies erfordert.

Bei bedingten Anfragen hat der Client Vorbedingungen in seinen Headern angegeben, die der Server nicht erfüllt.

Der Anfragerumpf ist größer als die vom Server festgelegten Grenzwerte. Der Server kann die Verbindung schließen oder ein Retry-After-Headerfeld zurückgeben.

Die vom Client angeforderte URI ist länger als der Server bereit ist zu interpretieren.

Das Medienformat der angeforderten Daten wird vom Server nicht unterstützt, sodass der Server die Anfrage ablehnt.

Die Bereiche, die vom Range-Header-Feld in der Anfrage angegeben sind, können nicht erfüllt werden. Es ist möglich, dass der Bereich außerhalb der Größe der Zieldaten der Ressource liegt.

Dieser Antwortcode bedeutet, dass die Erwartung, die durch das Expect-Anfrageheaderfeld angegeben wird, vom Server nicht erfüllt werden kann.

Der Server lehnt den Versuch ab, mit einer Teekanne Kaffee zu brühen.

Die Anfrage wurde an einen Server gerichtet, der nicht in der Lage ist, eine Antwort zu erzeugen. Dies kann von einem Server gesendet werden, der nicht dafür konfiguriert ist, Antworten für die Kombination aus Schema und Autorität zu produzieren, die in der Anforderungs-URI enthalten sind.

Die Anfrage war gut geformt, konnte aber aufgrund semantischer Fehler nicht durchgeführt werden.

Die Ressource, auf die zugegriffen wird, ist gesperrt.

Die Anfrage ist aufgrund des Fehlers einer vorherigen Anfrage fehlgeschlagen.

Zeigt an, dass der Server nicht bereit ist, eine Anfrage zu verarbeiten, die möglicherweise wiederholt wird.

Der Server verweigert die Ausführung der Anfrage mit dem aktuellen Protokoll, ist jedoch möglicherweise bereit, dies nach der Aktualisierung des Clients auf ein anderes Protokoll zu tun. Der Server sendet einen Upgrade-Header in einer 426-Antwort, um das benötigte Protokoll anzuzeigen.

Der Ursprungsserver erfordert, dass die Anfrage bedingungsgebunden ist. Diese Antwort soll das Problem des 'verlorenen Updates' verhindern, bei dem ein Client eine Ressource abfragt, ihren Zustand modifiziert und ihn dann zurück zum Server schickt, während mittlerweile eine dritte Partei den Zustand auf dem Server geändert hat, was zu einem Konflikt führt.

Der Benutzer hat zu viele Anfragen in einer bestimmten Zeitspanne gesendet (Ratenbegrenzung).

Der Server ist nicht bereit, die Anfrage zu bearbeiten, da die Header-Felder zu groß sind. Die Anfrage kann nach der Reduzierung der Größe der Anfragen-Header-Felder erneut gesendet werden.

Der Benutzeragent hat eine Ressource angefordert, die gesetzlich nicht bereitgestellt werden kann, wie z.B. eine von einer Regierung zensierte Webseite.

Der Server ist auf eine Situation gestoßen, mit der er nicht umgehen kann. Dieser Fehler ist allgemein und zeigt an, dass der Server keinen passenderen 5XX-Statuscode finden kann, um zu antworten.

Die Anfragemethode wird vom Server nicht unterstützt und kann nicht bearbeitet werden. Die einzigen Methoden, die Server unterstützen müssen (und daher diesen Code nicht zurückgeben dürfen), sind GET und HEAD.

Diese Fehlerantwort bedeutet, dass der Server, obwohl er als Gateway fungiert und versucht, eine erforderliche Antwort zu erhalten, eine ungültige Antwort erhalten hat.

Der Server ist nicht bereit, die Anfrage zu bearbeiten. Häufige Ursachen sind ein Server, der aufgrund von Wartungsarbeiten nicht betriebsbereit ist oder überlastet ist. Beachten Sie, dass zusammen mit dieser Antwort eine benutzerfreundliche Seite gesendet werden sollte, die das Problem erklärt. Diese Antwort sollte für vorübergehende Bedingungen verwendet werden und der Retry-After-HTTP-Header sollte, wenn möglich, die geschätzte Zeit bis zur Wiederherstellung des Dienstes enthalten. Der Webmaster muss auch auf die gesendeten Cache-bezogenen Header achten, da diese temporären Bedingungsantworten in der Regel nicht zwischengespeichert werden sollten.

Diese Fehlerantwort wird gegeben, wenn der Server als Gateway fungiert und keine rechtzeitige Antwort erhalten kann.

Die in der Anfrage verwendete HTTP-Version wird vom Server nicht unterstützt.

Der Server hat einen internen Konfigurationsfehler: Während der Inhaltsverhandlung ist die gewählte Variante so konfiguriert, dass sie selbst an der Inhaltsverhandlung teilnimmt, was zu zirkulären Referenzen bei der Erstellung von Antworten führt.

Die Methode konnte nicht auf der Ressource ausgeführt werden, weil der Server nicht in der Lage ist, die zur vollständigen Bearbeitung der Anfrage benötigte Darstellung zu speichern.

Der Server hat eine Endlosschleife während der Verarbeitung der Anfrage entdeckt.

Die Client-Anfrage deklariert eine HTTP-Erweiterung (RFC 2774), die verwendet werden sollte, um die Anfrage zu verarbeiten, aber die Erweiterung wird nicht unterstützt.

Zeigt an, dass der Client sich authentifizieren muss, um Netzwerkzugriff zu erhalten.