HTTP-Antwortstatuscodes

Diese vorläufige Antwort 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-Anfrage-Header vom Client gesendet und zeigt an, auf welches 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 und dem User-Agent zu ermöglichen, Ressourcen vorzuladen, während der Server eine Antwort vorbereitet, oder eine Vorverbindung zu einem Ursprung aufzubauen, von dem 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 Nachrichtentext übertragen.
• HEAD: Repräsentationsheader sind in der Antwort enthalten, jedoch ohne Nachrichtentext.
• PUT oder POST: Die Ressource, die das Ergebnis der Aktion beschreibt, wird im Nachrichtentext übertragen.
• TRACE: Der Nachrichtentext enthält die Anfrage, wie sie vom Server empfangen wurde.

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

Die Anfrage wurde empfangen, aber noch nicht bearbeitet. Sie ist unverbindlich, da es keinen Weg in HTTP gibt, später eine asynchrone Antwort über das Ergebnis der Anfrage zu senden. Sie ist für Fälle gedacht, in denen ein anderer Prozess oder Server die Anfrage bearbeitet oder für die Stapelverarbeitung.

Dieser Antwortcode bedeutet, dass die zurückgegebenen Metadaten nicht genau dieselben sind, wie sie vom Ursprungsserver verfügbar sind, sondern von einer lokalen oder einer Drittpartei-Kopie gesammelt wurden. Dies wird hauptsächlich für Spiegelung oder Sicherung einer anderen Ressource verwendet. Abgesehen von diesem spezifischen Fall wird die 200 OK-Antwort gegenüber diesem Status bevorzugt.

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

Teilt dem User-Agent mit, 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>-Antwortelements verwendet, um zu vermeiden, die internen Mitglieder mehrerer Bindungen an dieselbe 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 Instanzen-Manipulationen, die auf die aktuelle Instanz angewendet wurden.

Bei agentengesteuerter Inhaltsaushandlung hat die Anfrage mehr als eine mögliche Antwort und der User-Agent oder Benutzer sollte eine davon wä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 die URI der angeforderten Ressource vorübergehend geändert wurde. Weitere Änderungen der URI könnten in der Zukunft vorgenommen werden, sodass der Client dieselbe URI in zukünftigen Anfragen verwenden sollte.

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

Dies wird zu Caching-Zwecken verwendet. Es teilt dem Client mit, dass die Antwort nicht geändert wurde, sodass der Client weiterhin dieselbe zwischengespeicherte Version der Antwort verwenden kann.

Definiert in einer früheren Version der HTTP-Spezifikation, um anzuzeigen, dass eine angeforderte Antwort über einen Proxy aufgerufen werden muss. Es wurde aufgrund von Sicherheitsbedenken bezüglich der in-band Konfiguration eines Proxys verworfen.

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 aufzufordern, die angeforderte Ressource an einer anderen URI mit derselben Methode abzurufen, die in der vorherigen Anfrage verwendet wurde. Dies hat dieselbe Semantik wie der 302 Found-Antwortcode, mit der Ausnahme, dass der User-Agent die HTTP-Methode nicht ändern darf: Wenn in der ersten Anfrage eine POST verwendet wurde, muss auch in der umgeleiteten Anfrage eine POST verwendet werden.

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

Der Server kann die Anfrage aufgrund eines wahrgenommenen Client-Fehlers nicht verarbeiten oder lehnt diese ab (z.B. fehlerhafte Anfragesyntax, ungültige Nachrichtenumrandung oder täuschende Anforderungsweiterleitung).

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 auf den Inhalt; das heißt, er ist nicht autorisiert, daher verweigert der Server die Bereitstellung der angeforderten Ressource. 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, aber die Ressource selbst nicht existiert. Server können diese Antwort auch anstelle von 403 Forbidden senden, um die Existenz einer Ressource vor einem nicht autorisierten Client zu verbergen. Dieser Antwortcode ist wahrscheinlich der bekannteste aufgrund seines häufigen Auftretens im Web.

Die Anfragemethode ist dem Server bekannt, wird jedoch von der Zielressource nicht unterstützt. Zum Beispiel darf eine API möglicherweise DELETE auf einer Ressource oder die TRACE-Methode überhaupt nicht zulassen.

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

Dies ist ähnlich zu 401 Unauthorized, jedoch muss eine Authentifizierung durch einen Proxy erfolgen.

Diese Antwort wird bei einer Leerlaufverbindung von einigen Servern gesendet, selbst ohne vorherige Anfrage des Clients. Dies bedeutet, dass der Server diese unbenutzte Verbindung schließen möchte. Diese Antwort wird viel häufiger verwendet, da einige Browser HTTP-Vorverbindungsmechanismen nutzen, um das Surfen zu beschleunigen. Einige Server können eine Verbindung ohne dieses Nachricht schließen.

Diese Antwort wird gesendet, wenn eine Anfrage mit dem aktuellen Zustand des Servers in Konflikt steht. In der WebDAV Remote-Web-Autorität sind 409-Antworten Fehler, die an den Client gesendet werden, damit ein Benutzer einen Konflikt lösen und die Anfrage erneut einreichen kann.

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

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

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

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

Die von dem Client angeforderte URI ist länger, als der Server zu interpretieren bereit ist.

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

Die Bereiche, die im Range-Headerfeld der Anfrage angegeben sind, können nicht erfüllt werden. Es ist möglich, dass der Bereich außerhalb der Größe der Datensätze der Zielressource liegt.

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

Der Server lehnt den Versuch ab, Kaffee mit einer Teekanne zu brauen.

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 in der Anfrage-URI enthaltene Kombination aus Schema und Autorität zu erzeugen.

Die Anfrage war wohlgeformt, konnte jedoch aufgrund semantischer Fehler nicht befolgt werden.

Die Ressource, auf die zugegriffen wird, ist gesperrt.

Die Anfrage ist aufgrund eines Fehlers einer früheren Anfrage fehlgeschlagen.

Gibt an, dass der Server nicht bereit ist, das Risiko einzugehen, eine Anfrage zu verarbeiten, die wiederholt werden könnte.

Der Server verweigert die Durchfü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 die erforderlichen Protokoll(e) anzuzeigen.

Der Ursprungserver erfordert, dass die Anfrage bedingt ist. Diese Antwort soll das "verlorene Aktualisierungs"-Problem verhindern, bei dem ein Client eine Ressourcenzustand über GET abruft, ihn modifiziert und über PUT zurück an den Server sendet, 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 einem bestimmten Zeitraum gesendet (Ratenbegrenzung).

Der Server ist nicht bereit, die Anfrage zu verarbeiten, weil die Header-Felder zu groß sind. Die Anfrage kann nach Verkleinerung der Größe der Header-Felder erneut eingereicht werden.

Der User-Agent hat eine Ressource angefordert, die rechtlich nicht bereitgestellt werden kann, wie z.B. eine Webseite, die von einer Regierung zensiert wurde.

Der Server hat eine Situation festgestellt, die er nicht handhaben kann. Dieser Fehler ist generisch 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, während er als Gateway arbeitete, um eine Antwort zu erhalten, die zur Bearbeitung der Anfrage benötigt wurde, eine ungültige Antwort erhalten hat.

Der Server ist nicht bereit, die Anfrage zu bearbeiten. Häufige Ursachen sind ein aufgrund von Wartungsarbeiten oder Überlastung nicht erreichbarer Server. 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, wenn möglich, die geschätzte Zeit bis zur Wiederherstellung des Dienstes enthalten. Der Webmaster muss auch auf die zusammen mit dieser Antwort gesendeten cachingbezogenen Header achten, da diese temporäre Zustandsantworten normalerweise nicht zwischengespeichert werden sollten.

Diese Fehlerantwort wird gegeben, wenn der Server als Gateway arbeitet und in der vorgegebenen Zeit keine Antwort erhält.

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 zu zirkulären Referenzen bei der Erstellung der Antworten führt.

Die Methode konnte nicht auf der Ressource ausgeführt werden, da der Server nicht in der Lage ist, die zur erfolgreichen Erfüllung der Anfrage benötigte Darstellung zu speichern.

Der Server hat eine Endlosschleife beim Verarbeiten der Anfrage festgestellt.

Die Clientanfrage erklärt eine HTTP-Erweiterung (RFC 2774), die zur Verarbeitung der Anfrage verwendet werden soll, aber die Erweiterung wird nicht unterstützt.

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