HTTP-Antwortstatuscodes

Diese vorläufige Antwort weist darauf hin, 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-Anforderungs-Header vom Client gesendet und zeigt an, zu welchem Protokoll 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, um dem User Agent das Preloading von Ressourcen zu ermöglichen, während der Server eine Antwort vorbereitet oder eine Preconnect zu einer Quelle herstellt, 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 Nachrichtenkörper übertragen.
• HEAD: Repräsentations-Header sind in der Antwort enthalten, jedoch ohne Nachrichtenkörper.
• PUT oder POST: Die Ressource, die das Ergebnis der Aktion beschreibt, wird im Nachrichtenkörper übertragen.
• TRACE: Der Nachrichtenkörper enthält die Anfrage, so 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 oder einigen PUT-Anfragen gesendet wird.

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

Dieser Antwortcode bedeutet, dass die zurückgegebenen Metadaten nicht genau dieselben sind, wie sie vom Ursprungsserver verfügbar sind, sondern aus einer lokalen oder einer Drittanbieterkopie stammen. Dies wird hauptsächlich für Spiegel- oder Backup-Ressourcen verwendet. Mit Ausnahme dieses spezifischen Falls wird die 200 OK-Antwort gegenüber diesem Status bevorzugt.

Es gibt keinen Inhalt zum Senden für diese Anfrage, aber die Header sind nützlich. Der User Agent kann die zwischengespeicherten Header für diese Ressource mit den neuen aktualisieren.

Weist den User Agent 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 über mehrere Ressourcen für Situationen, in denen mehrere Statuscodes angemessen sein könnten.

Wird innerhalb eines <dav:propstat>-Antwort-Elements verwendet, um zu vermeiden, dass die internen Mitglieder mehrerer Bindungen zu derselben Sammlung wiederholt aufgezählt werden.

Der Server hat eine GET-Anfrage für die Ressource erfüllt, und die Antwort ist eine Repräsentation 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 User-Agent oder der Nutzer sollte eine davon auswählen. Es gibt keinen standardisierten Weg 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 in zukünftigen Anfragen verwendet werden.

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

Dies wird für Caching-Zwecke verwendet. Es teilt dem Client mit, dass die Antwort nicht modifiziert wurde, sodass der Client weiterhin die gleiche zwischengespeicherte Version der Antwort 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 In-Band-Konfiguration eines Proxys veraltet.

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

Der Server sendet diese Antwort, um den Client zu einer anderen URI mit der gleichen Methode zu leiten, die in der vorherigen Anfrage verwendet wurde. Dies hat die gleichen Semantiken wie der 302 Found-Antwortcode, mit der Ausnahme, dass der User Agent die verwendete HTTP-Methode nicht ändern darf: Wenn eine POST in der ersten Anfrage verwendet wurde, muss eine POST auch in der weitergeleiteten Anfrage verwendet werden.

Dies bedeutet, dass die Ressource jetzt dauerhaft unter einer anderen URI lokalisiert ist, die im Location-Antwort-Header angegeben ist. Dies hat die gleichen Semantiken wie der 301 Moved Permanently HTTP-Antwortcode, mit der Ausnahme, dass der User Agent die verwendete HTTP-Methode nicht ändern darf: Wenn eine POST in der ersten Anfrage verwendet wurde, muss eine POST in der zweiten Anfrage verwendet werden.

Der Server kann oder wird die Anfrage aufgrund eines wahrgenommenen Client-Fehlers (z. B. fehlerhafte Anfragesyntax, ungültige Anforderungsnachricht-Rahmenstruktur oder täuschende Anforderungsleitung) nicht verarbeiten.

Obwohl der HTTP-Standard "unauthorized" angibt, 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, dieser Statuscode wird jedoch selten verwendet und es gibt keine standardisierte Konvention.

Der Client hat keine Zugriffsrechte auf den Inhalt; das heißt, es ist unberechtigt, sodass der Server die angeforderte Ressource verweigert. 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 dies, dass die URL nicht erkannt wird. In einer API kann dies auch bedeuten, dass der Endpunkt gültig ist, die Ressource selbst jedoch nicht existiert. Server können diese Antwort auch anstelle von 403 Forbidden senden, um die Existenz einer Ressource vor einem unberechtigten Client zu verbergen. Dieser Antwortcode ist wahrscheinlich der bekannteste, da er im Web häufig auftritt.

Die Anfragemethode ist dem Server bekannt, wird jedoch von der Zielressource nicht unterstützt. Zum Beispiel darf eine API kein DELETE für eine Ressource zulassen oder die TRACE-Methode insgesamt.

Diese Antwort wird gesendet, wenn der Webserver nach der Durchführung einer servergesteuerten Inhaltsverhandlung keinen Inhalt findet, der den vom User Agent angegebenen Kriterien entspricht.

Dies ist ähnlich wie 401 Unauthorized, aber die Authentifizierung muss über einen Proxy erfolgen.

Diese Antwort wird von einigen Servern über eine inaktive Verbindung gesendet, auch ohne dass eine vorherige Anfrage des Clients erfolgt. Es bedeutet, dass der Server diese unbenutzte Verbindung schließen möchte. Diese Antwort wird viel mehr verwendet, seit einige Browser HTTP-Vorverbindungen verwenden, um das Surfen zu beschleunigen. Einige Server können eine Verbindung schließen, ohne diese Nachricht zu senden.

Diese Antwort wird gesendet, wenn eine Anfrage mit dem aktuellen Zustand des Servers in Konflikt steht. Im WebDAV Remote-Web-Authoring sind 409-Antworten Fehler, die an den Client gesendet werden, damit ein Benutzer 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 Weiterleitungsadresse. Die Clients sollten ihre Caches und Links zur Ressource entfernen. Die HTTP-Spezifikation beabsichtigt, dass dieser Statuscode für "zeitlich begrenzte, Werbedienste" verwendet wird. APIs sollten sich nicht verpflichtet fühlen, Ressourcen, die gelöscht wurden, mit diesem Statuscode anzugeben.

Der Server hat die Anfrage abgelehnt, weil das Content-Length-Headerfeld nicht definiert ist und der Server es benötigt.

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

Der Anfragetext ist größer als die vom Server definierten Grenzen. Der Server könnte die Verbindung schließen oder ein Retry-After-Headerfeld zurückgeben.

Die vom Client angeforderte URI ist länger, als der Server interpretieren möchte.

Das Medienformat der angeforderten Daten wird vom Server nicht unterstützt, daher lehnt der Server die Anfrage ab.

Die durch das Range-Headerfeld in der Anfrage spezifizierten Bereiche können nicht erfüllt werden. Es ist möglich, dass der Bereich außerhalb der Datengröße der Zielressource liegt.

Dieser Antwortcode bedeutet, dass die durch das Expect-Anforderungs-Headerfeld angegebene Erwartung vom Server nicht erfüllt werden kann.

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

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

Die Anfrage war gut geformt, konnte jedoch aufgrund semantischer Fehler nicht bearbeitet werden.

Die Ressource, auf die zugegriffen wird, ist gesperrt.

Die Anfrage schlug aufgrund eines Fehlers einer vorherigen Anfrage fehl.

Gibt an, dass der Server nicht bereit ist, das Risiko der Ausführung einer Anfrage einzugehen, die möglicherweise wiederholt wird.

Der Server weigert sich, die Anfrage mit dem aktuellen Protokoll durchzuführen, könnte dies jedoch tun, nachdem der Client zu einem anderen Protokoll wechselt. Der Server sendet in einer 426-Antwort einen Upgrade-Header, um das erforderliche Protokoll anzuzeigen.

Der Ursprungsserver verlangt, dass die Anfrage bedingt ist. Diese Antwort soll das 'Lost Update'-Problem verhindern, bei dem ein Client den Zustand einer Ressource holt, ihn modifiziert und ihn zurück zum Server stellt, währenddessen 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 (Rate Limiting).

Der Server ist nicht bereit, die Anfrage zu verarbeiten, da deren Headerfelder zu groß sind. Die Anfrage kann nach Reduzierung der Größe der Anforderungs-Headerfelder erneut gesendet werden.

Der User Agent hat eine Ressource angefordert, die aus rechtlichen Gründen nicht bereitgestellt werden kann, wie z. B. eine von einer Regierung zensierte Webseite.

Der Server hat eine Situation festgestellt, mit der er nicht umgehen kann. Dieser Fehler ist generisch und zeigt an, dass der Server keinen passenderen 5XX-Statuscode hat, 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, während er als Gateway arbeitet, eine ungültige Antwort erhalten hat, die zur Bearbeitung der Anfrage benötigt wird.

Der Server ist nicht bereit, die Anfrage zu bearbeiten. Häufige Ursachen sind ein Server, der für Wartungsarbeiten ausgefallen 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 temporäre Bedingungen verwendet werden, und der Retry-After HTTP-Header sollte, falls möglich, die geschätzte Zeit vor der Wiederherstellung des Dienstes enthalten. Der Webmaster muss auch auf die Caching-bezogenen Header achten, die zusammen mit dieser Antwort gesendet werden, da diese Antworten auf temporäre Bedingungen normalerweise nicht zwischengespeichert werden sollten.

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

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

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

Die Methode konnte nicht für die Ressource durchgeführt werden, da der Server nicht in der Lage ist, die zur erfolgreichen Durchführung der Anfrage benötigte Repräsentation zu speichern.

Der Server hat eine Endlosschleife beim Verarbeiten der Anfrage erkannt.

Die Anfrage des Clients gibt eine HTTP-Erweiterung (RFC 2774) an, die zur Bearbeitung der Anfrage verwendet werden soll, aber die Erweiterung wird nicht unterstützt.

Gibt an, dass der Client authentifizieren muss, um Netzwerkzugang zu erlangen.