HTTP-Antwortstatuscodes

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

Dieser Code wird als Antwort auf einen Upgrade-Anforderungsheader 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 soll hauptsächlich mit dem Link-Header verwendet werden, um dem Benutzeragenten das Vorladen von Ressourcen zu ermöglichen, während der Server eine Antwort vorbereitet oder eine Vorabverbindung mit einer Herkunftsquelle 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 Nachrichtentext übertragen.
• HEAD: Repräsentationsheader sind in der Antwort ohne Nachrichtentext enthalten.
• 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 eine neue Ressource wurde dadurch 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 keine Möglichkeit in HTTP gibt, später eine asynchrone Antwort zu senden, die das Ergebnis der Anfrage angibt. 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 mit denen vom Ursprungsserver übereinstimmen, sondern von einer lokalen oder einer dritten Kopie gesammelt wurden. Dies wird hauptsächlich für Spiegel oder Backups einer anderen Ressource verwendet. Außer in diesem spezifischen Fall ist die 200 OK-Antwort dieser Status vorzuziehen.

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

Fordert den Benutzeragenten auf, 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 geeignet sein könnten.

Wird innerhalb eines <dav:propstat>-Antwortelements verwendet, um zu vermeiden, dass die internen Mitglieder mehrfacher Bindungen an dieselbe Sammlung wiederholt aufgezählt werden.

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 von ihnen auswählen. Es gibt keinen standardisierten Weg für Clients, automatisch eine der Antworten auszuwählen, weshalb dies selten verwendet wird.

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 Zukunft vorgenommen werden, daher sollte dieselbe URI vom Client in zukünftigen Anfragen verwendet werden.

Der Server hat diese Antwort gesendet, um den Client dazu 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 geändert wurde, sodass der Client weiterhin dieselbe zwischengespeicherte Version der Antwort verwenden kann.

In einer früheren Version der HTTP-Spezifikation definiert, um anzuzeigen, dass eine angeforderte Antwort über einen Proxy erreicht werden muss. Es wurde aus Sicherheitsgründen bezüglich der In-Band-Konfiguration eines Proxys abgeschafft.

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 zur gleichen Methode wie in der vorherigen Anfrage zu veranlassen, um die angeforderte Ressource an einer anderen URI abzurufen. Dies hat dieselben Semantiken wie der 302 Found-Antwortcode, mit der Ausnahme, dass der Benutzeragent nicht die HTTP-Methode ändern darf: Wenn eine POST-Anfrage in der ersten Anfrage verwendet wurde, muss eine POST-Anfrage in der umgeleiteten Anfrage verwendet werden.

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

Der Server kann die Anfrage nicht verarbeiten oder wird sie nicht verarbeiten aufgrund von etwas, das als Clientfehler wahrgenommen wird (z. B. fehlerhafte Anfrage-Syntax, ungültige Anforderungs-Nachrichtenrahmen oder täuschende Anfrage-Routing).

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 vorgesehen, jedoch wird dieser Statuscode selten verwendet und es gibt keine standardisierte Konvention.

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 Unterschied 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 auch diese Antwort anstelle von 403 Forbidden senden, um die Existenz einer Ressource vor einem nicht autorisierten Client zu verbergen. Dieser Antwortcode ist wahrscheinlich am bekanntesten, da er häufig im Web auftritt.

Die Anfragemethode ist dem Server bekannt, wird jedoch von der Zielressource nicht unterstützt. Zum Beispiel könnte eine API DELETE auf eine Ressource oder die TRACE-Methode generell nicht erlauben.

Diese Antwort wird gesendet, wenn der Webserver nach einer servergesteuerten Inhaltsverhandlung keinen Inhalt findet, der den vom Benutzeragenten vorgelegten Kriterien entspricht.

Dies ist ähnlich wie 401 Unauthorized, jedoch muss die Authentifizierung durch einen Proxy erfolgen.

Diese Antwort wird auf einer ruhenden Verbindung von einigen Servern gesendet, auch ohne vorherige Anfrage vom Client. Sie bedeutet, dass der Server diese unbenutzte Verbindung schließen möchte. Diese Antwort wird häufiger verwendet, da einige Browser HTTP-Vorverbindungsmechanismen 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-Fernweb-Autorensystem sind 409-Antworten Fehler, die an den Client gesendet werden, damit der 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. Clients sollen ihre Caches und Links zur Ressource entfernen. Die HTTP-Spezifikation sieht vor, dass dieser Statuscode für "begrenzte Werbedienstleistungen" verwendet wird. APIs sollten sich nicht verpflichtet fühlen, Ressourcen, die gelöscht wurden, mit diesem Statuscode anzuzeigen.

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

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

Der Nachrichtenkörper der Anfrage ist größer als die vom Server festgelegten 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 zu interpretieren bereit ist.

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 angegebenen Bereiche 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 durch das Expect-Headerfeld der Anfrage angegebene Erwartung nicht vom Server erfüllt werden kann.

Der Server verweigert den Versuch, Kaffee mit einer Teekanne zu machen.

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

Die Anfrage war gut geformt, konnte aber nicht befolgt werden due to semantische Fehler.

Die Ressource, auf die zugegriffen wird, ist gesperrt.

Die Anfrage ist aufgrund des Fehlschlags einer vorherigen Anfrage fehlgeschlagen.

Gibt an, dass der Server nicht bereit ist, das Risiko einzugehen, eine Anfrage zu verarbeiten, die möglicherweise wiederholt wird.

Der Server weigert sich, die Anfrage mit dem aktuellen Protokoll auszuführen, könnte jedoch bereit sein, dies nach einem Upgrade des Clients auf ein anderes Protokoll zu tun. Der Server sendet einen Upgrade-Header in einer 426-Antwort, um das erforderliche Protokoll bzw. die erforderlichen Protokolle anzugeben.

Der Ursprungsserver erfordert, dass die Anfrage bedingt ist. Diese Antwort ist vorgesehen, um das Problem der 'verlorenen Aktualisierung' zu verhindern, bei dem ein Client den Zustand einer Ressource GET, ihn ändert und ihn PUT an den Server zurücksendet, während ein Dritter 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 seine Headerfelder zu groß sind. Die Anfrage kann erneut gesendet werden, nachdem die Größe der Headerfelder der Anfrage reduziert wurde.

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

Der Server ist auf eine Situation gestoßen, die er nicht bewältigen kann. Dieser Fehler ist allgemein gehalten und zeigt an, dass der Server keinen geeigneteren 5XX-Statuscode finden kann, um zu antworten.

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

Diese Fehlerantwort bedeutet, dass der Server, während er als Gateway funktionierte, eine ungültige Antwort erhalten hat, die benötigt wurde, um die Anfrage zu bearbeiten.

Der Server ist nicht bereit, die Anfrage zu bearbeiten. Häufige Ursachen sind ein Server, der wegen Wartungsarbeiten außer Betrieb 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 nach Möglichkeit die geschätzte Zeit bis zur Wiederherstellung des Dienstes enthalten. Der Webmaster muss auch auf die caching-bezogenen Header achten, die zusammen mit dieser Antwort gesendet werden, da diese temporären Zustandsantworten in der Regel 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 Inhaltsverhandlung ist die gewählte Variante so konfiguriert, dass sie sich selbst an der Inhaltsverhandlung beteiligt, was zu zirkulären Verweisen bei der Erstellung von Antworten führt.

Die Methode konnte nicht auf die Ressource angewendet werden, da der Server nicht in der Lage ist, die Darstellung zu speichern, die zum erfolgreichen Abschluss der Anfrage benötigt wird.

Der Server hat eine Endlosschleife bei der Verarbeitung der Anfrage erkannt.

Der Client-Anforderung wird eine HTTP-Erweiterung (RFC 2774) deklariert, die zum Verarbeiten der Anfrage verwendet werden soll, aber die Erweiterung wird nicht unterstützt.

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