Liste der HTTP-Statuscodes

Der Client sollte mit seiner Anfrage fortfahren. Diese vorläufige Antwort zeigt an, dass bisher alles in Ordnung ist und der Client mit der Anfrage fortfahren oder sie ignorieren soll, wenn sie bereits abgeschlossen ist.

Der Server wechselt die Protokolle, wie vom Client über einen Upgrade-Anfrageheader angefordert.

WebDAV; Der Server hat die Anfrage empfangen und verarbeitet sie, aber es ist noch keine Antwort verfügbar. Dies verhindert, dass der Client ein Timeout erhält und annimmt, die Anfrage sei verloren gegangen.

Der Server sendet einige Header vor der endgültigen HTTP-Nachricht. Dies wird verwendet, um dem Client zu ermöglichen, mit dem Vorladen von Ressourcen zu beginnen, während der Server noch die Hauptantwort vorbereitet.

Die Anfrage war erfolgreich. Die Bedeutung von 'Erfolg' hängt von der HTTP-Methode ab: GET: Die Ressource wurde abgerufen und im Nachrichtentext übertragen. HEAD: Die Entitätsheader befinden sich im Nachrichtentext. POST oder PUT: Die Ressource, die das Ergebnis der Aktion beschreibt, wird im Nachrichtentext übertragen. TRACE: Der Nachrichtentext enthält die Anforderungsnachricht, wie sie vom Server empfangen wurde.

Die Anfrage wurde erfüllt und hat zur Erstellung einer neuen Ressource geführt. Die neue Ressource wird effektiv erstellt, bevor diese Antwort zurückgesendet wird, und die neue Ressource wird im Körper der Nachricht zurückgegeben, wobei ihr Speicherort entweder die URL der Anfrage oder der Inhalt des Location-Headers ist.

Die Anfrage wurde zur Verarbeitung angenommen, aber die Verarbeitung ist noch nicht abgeschlossen. Die Anfrage kann möglicherweise irgendwann bearbeitet werden oder auch nicht, da sie bei der tatsächlichen Verarbeitung möglicherweise nicht zulässig ist.

Die zurückgegebenen Metainformationen stammen von einer lokalen Kopie oder einer Drittanbieterkopie, nicht vom Ursprungsserver, und könnten falsch sein. Außer in diesem speziellen Fall ist die 200 OK-Antwort diesem Status vorzuziehen.

Der Server hat die Anfrage erfolgreich verarbeitet und gibt keinen Inhalt zurück. Nützlich für Aktionen, die keinen Antwortkörper erfordern, wie z. B. eine DELETE-Anfrage.

Der Server hat die Anfrage erfolgreich verarbeitet, fordert den Anforderer auf, seine Dokumentansicht zurückzusetzen, und gibt keinen Inhalt zurück. Dies wird oft nach dem Absenden eines Formulars verwendet, um die Formularfelder für eine neue Eingabe zu löschen.

Der Server liefert nur einen Teil der Ressource (Byte-Serving) aufgrund eines vom Client gesendeten Range-Headers. Der Range-Header wird von Tools wie wget verwendet, um die Wiederaufnahme unterbrochener Downloads zu ermöglichen oder einen Download in mehrere gleichzeitige Streams aufzuteilen.

WebDAV; Übermittelt Informationen über mehrere Ressourcen für Situationen, in denen mehrere Statuscodes angemessen sein könnten. Der Körper ist eine XML-Nachricht.

WebDAV; Wird innerhalb eines <dav:propstat>-Antwortelements verwendet, um die wiederholte Aufzählung der internen Mitglieder mehrerer Bindungen an dieselbe Sammlung zu vermeiden. Die Mitglieder einer Bindung wurden bereits in einer früheren Antwort aufgezählt.

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

Zeigt mehrere Optionen für die Ressource an, aus denen der Client wählen kann (z.B. verschiedene Videoformate, Liste von Dateien mit verschiedenen Erweiterungen). Der Server kann einen Location-Header mit einer bevorzugten Wahl enthalten.

Diese und alle zukünftigen Anfragen sollten an die angegebene URI weitergeleitet werden. Suchmaschinen aktualisieren ihre Links zur Ressource (im 'SEO-Jargon' wird gesagt, dass der 'Link-Juice' an die neue URL gesendet wird).

Dieser Antwortcode bedeutet, dass die URI der angeforderten Ressource vorübergehend geändert wurde. Zukünftige Änderungen der URI könnten vorgenommen werden. Daher sollte diese URI vom Client in zukünftigen Anfragen verwendet werden.

Der Server hat diese Antwort gesendet, um den Client anzuweisen, die angeforderte Ressource unter einer anderen URI mit einer GET-Anfrage abzurufen. Typischerweise nach einer POST/PUT-Operation verwendet, um zu verhindern, dass das Aktualisieren der Seite das Formular erneut sendet.

Zeigt an, dass die Ressource seit der in den Anfrageheadern If-Modified-Since oder If-None-Match angegebenen Version nicht geändert wurde. In einem solchen Fall ist es nicht erforderlich, die Ressource erneut zu übertragen, da der Client noch über eine zuvor heruntergeladene Kopie verfügt.

Veraltet. Die angeforderte Ressource ist nur über einen Proxy verfügbar, dessen Adresse in der Antwort angegeben ist. Viele HTTP-Clients (wie Mozilla Firefox und Internet Explorer) behandeln Antworten mit diesem Statuscode nicht korrekt, hauptsächlich aus Sicherheitsgründen.

Der Server sendet diese Antwort, um den Client anzuweisen, die angeforderte Ressource unter einer anderen URI mit derselben Methode abzurufen, die in der vorherigen Anfrage verwendet wurde. Dies hat dieselbe Semantik wie der HTTP-Antwortcode 302 Found, mit der Ausnahme, dass der User-Agent die verwendete HTTP-Methode nicht ändern darf.

Die Ressource befindet sich nun dauerhaft unter einer anderen URI, die durch den HTTP-Antwortheader Location: angegeben wird. Dies hat dieselbe Semantik wie der HTTP-Antwortcode 301 Moved Permanently, mit der Ausnahme, dass der User-Agent die verwendete HTTP-Methode nicht ändern darf: Wenn in der ersten Anfrage ein POST verwendet wurde, muss in der zweiten Anfrage ein POST verwendet werden.

Der Server kann oder wird die Anfrage aufgrund eines offensichtlichen Client-Fehlers nicht verarbeiten (z.B. fehlerhafte Anfragesyntax, ungültiges Anforderungsnachrichten-Framing oder irreführendes Anforderungsrouting).

Authentifizierung ist erforderlich und fehlgeschlagen oder wurde noch nicht bereitgestellt. Die Antwort muss ein WWW-Authenticate-Headerfeld enthalten, das eine für die angeforderte Ressource geltende Aufforderung enthält. Manchmal für 'Autorisierung fehlgeschlagen' verwendet, aber 403 ist angemessener.

Für zukünftige Verwendung reserviert. Die ursprüngliche Absicht war, dass dieser Code als Teil einer Form von digitalem Bargeld oder Mikrozahlungsschema verwendet werden könnte, was aber bisher nicht geschehen ist, und dieser Code wird nicht häufig verwendet.

Die Anfrage war gültig, aber der Server verweigert die Aktion. Der Benutzer hat möglicherweise nicht die erforderlichen Berechtigungen für eine Ressource oder benötigt möglicherweise eine Art Konto.

Die angeforderte Ressource konnte nicht gefunden werden, könnte aber in Zukunft verfügbar sein. Nachfolgende Anfragen des Clients sind zulässig. Oft verwendet, wenn ein Server nicht genau preisgeben möchte, warum eine Anfrage abgelehnt wurde, oder wenn keine andere Antwort anwendbar ist.

Eine Anfragemethode wird für die angeforderte Ressource nicht unterstützt; zum Beispiel eine GET-Anfrage an ein Formular, das Daten per POST erfordert, oder eine PUT-Anfrage an eine schreibgeschützte Ressource.

Die angeforderte Ressource kann nur Inhalte generieren, die gemäß den in der Anfrage gesendeten Accept-Headern nicht akzeptabel sind. Zum Beispiel forderte der Client XML an, aber der Server kann nur JSON bereitstellen.

Der Client muss sich zuerst beim Proxy authentifizieren. Der Proxy muss ein Proxy-Authenticate-Headerfeld senden, das eine für den Proxy geltende Aufforderung für die angeforderte Ressource enthält.

Der Server hat beim Warten auf die Anfrage ein Timeout erreicht. Gemäß HTTP-Spezifikationen: 'Der Client hat innerhalb der Zeit, die der Server zu warten bereit war, keine Anfrage erstellt. Der Client KANN die Anfrage jederzeit später ohne Änderungen wiederholen.'

Zeigt an, dass die Anfrage aufgrund eines Konflikts im aktuellen Zustand der Ressource nicht verarbeitet werden konnte, z. B. ein Bearbeitungskonflikt zwischen mehreren gleichzeitigen Aktualisierungen.

Zeigt an, dass die angeforderte Ressource nicht mehr verfügbar ist und auch nicht wieder verfügbar sein wird. Dies sollte verwendet werden, wenn eine Ressource absichtlich entfernt wurde und die Ressource gelöscht werden soll. Nach Erhalt eines 410-Statuscodes sollte der Client die Ressource in Zukunft nicht mehr anfordern.

Die Anfrage hat die Länge ihres Inhalts nicht angegeben, was von der angeforderten Ressource erforderlich ist. Der Server akzeptiert die Anfrage nicht ohne einen gültigen Content-Length-Header.

Der Server erfüllt eine der Vorbedingungen nicht, die der Anforderer an die Anfrageheaderfelder gestellt hat. Dies wird oft bei bedingten GET-Anfragen verwendet (unter Verwendung von If-Match- oder If-Unmodified-Since-Headern).

Die Anfrage ist größer, als der Server zu verarbeiten bereit oder in der Lage ist. Früher 'Request Entity Too Large' genannt.

Die angegebene URI war zu lang für die Verarbeitung durch den Server. Oft das Ergebnis von zu vielen Daten, die als Abfragezeichenfolge einer GET-Anfrage codiert wurden, in welchem Fall sie in eine POST-Anfrage umgewandelt werden sollte. Früher 'Request-URI Too Long' genannt.

Die Anforderungsentität hat einen Medientyp, den der Server oder die Ressource nicht unterstützt. Zum Beispiel lädt der Client ein Bild als image/svg+xml hoch, aber der Server verlangt, dass Bilder ein anderes Format verwenden.

Der Client hat einen Teil der Datei angefordert (Byte-Serving), aber der Server kann diesen Teil nicht liefern. Zum Beispiel, wenn der Client einen Teil der Datei angefordert hat, der über das Ende der Datei hinausgeht. Früher 'Requested Range Not Satisfiable' genannt.

Der Server kann die Anforderungen des Expect-Anfrageheaderfelds nicht erfüllen. Der Client hat einen Expect-Header gesendet (z.B. Expect: 100-continue), den der Server nicht erfüllen kann.

Dieser Code wurde 1998 als Aprilscherz in RFC 2324, Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0), definiert und wird voraussichtlich nicht von tatsächlichen HTTP-Servern implementiert. Er wird jedoch manchmal als Easter Egg verwendet.

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 erzeugen, die in der Anfrage-URI enthalten sind.

WebDAV; Die Anfrage war wohlgeformt, konnte aber aufgrund semantischer Fehler nicht befolgt werden. Zum Beispiel enthält ein XML-Anfragekörper wohlgeformte (d.h. syntaktisch korrekte), aber semantisch fehlerhafte XML-Anweisungen.

WebDAV; Die Ressource, auf die zugegriffen wird, ist gesperrt. Dies bedeutet, dass die Quell- oder Zielressource einer Methode gesperrt ist.

WebDAV; Die Anfrage ist fehlgeschlagen, weil sie von einer anderen Anfrage abhing und diese Anfrage fehlgeschlagen ist (z.B. ein PROPPATCH mit einem fehlgeschlagenen PROPFIND).

Der Client sollte auf ein anderes Protokoll wie TLS/1.0 wechseln, das im Upgrade-Headerfeld angegeben ist. Der Server sendet mit dieser Antwort einen Upgrade-Header, um das/die erforderliche(n) Protokoll(e) anzugeben.

Der Ursprungsserver erfordert, dass die Anfrage bedingt ist. Soll das Problem des 'verlorenen Updates' verhindern, bei dem ein Client den Zustand einer Ressource abruft, ändert und 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 in einem bestimmten Zeitraum zu viele Anfragen gesendet ('Ratenbegrenzung'). Die Antwortdarstellungen SOLLTEN Details enthalten, die die Bedingung erklären, und KÖNNEN einen Retry-After-Header enthalten, der angibt, wie lange gewartet werden soll, bevor eine neue Anfrage gestellt wird.

Der Server ist nicht bereit, die Anfrage zu verarbeiten, da ihre Headerfelder zu groß sind. Die Anfrage KANN nach Reduzierung der Größe der Anfrageheaderfelder erneut gesendet werden.

Der Server verweigert den Zugriff auf die Ressource aufgrund einer rechtlichen Forderung. Dies könnte eine staatliche Zensur oder eine gerichtliche Anordnung sein.

Eine generische Fehlermeldung, die ausgegeben wird, wenn eine unerwartete Bedingung aufgetreten ist und keine spezifischere Meldung geeignet ist. Dies ist ein serverseitiger 'Catch-all'-Fehler.

Der Server erkennt entweder die Anfragemethode nicht oder ihm fehlt die Fähigkeit, die Anfrage zu erfüllen. Normalerweise impliziert dies zukünftige Verfügbarkeit (z.B. eine neue Funktion einer Webdienst-API).

Der Server fungierte als Gateway oder Proxy und erhielt eine ungültige Antwort vom Upstream-Server, auf den er bei dem Versuch, die Anfrage zu erfüllen, zugegriffen hat.

Der Server ist derzeit nicht verfügbar (weil er überlastet oder wegen Wartungsarbeiten ausgefallen ist). Im Allgemeinen ist dies ein vorübergehender Zustand. Ein Retry-After-Header könnte enthalten sein, um eine Verzögerung vorzuschlagen.

Der Server fungierte als Gateway oder Proxy und erhielt keine rechtzeitige Antwort vom Upstream-Server oder einem anderen Hilfsserver, auf den er zugreifen musste, um die Anfrage abzuschließen.

Der Server unterstützt die in der Anfrage verwendete HTTP-Protokollversion nicht. Die Antwort sollte eine Entität enthalten, die beschreibt, warum diese Version nicht unterstützt wird und welche anderen Protokolle von diesem Server unterstützt werden.

Die transparente Inhaltsaushandlung für die Anfrage führt zu einer zirkulären Referenz. Die gewählte Variantenressource ist so konfiguriert, dass sie selbst an der transparenten Inhaltsaushandlung teilnimmt und daher kein geeigneter Endpunkt im Aushandlungsprozess ist.

WebDAV; Der Server kann die zur Vervollständigung der Anfrage erforderliche Darstellung nicht speichern. Dieser Zustand wird als vorübergehend betrachtet.

WebDAV; Der Server hat während der Verarbeitung der Anfrage eine Endlosschleife erkannt (anstelle von 208 Bereits gemeldet gesendet). Dies zeigt an, dass die gesamte Operation fehlgeschlagen ist.

Weitere Erweiterungen der Anfrage sind erforderlich, damit der Server sie erfüllen kann. Die Anfrage erfordert eine obligatorische Erweiterung, die vom Server nicht unterstützt wird.

Der Client muss sich authentifizieren, um Netzwerkzugriff zu erhalten. Vorgesehen für die Verwendung durch abfangende Proxys, die zur Kontrolle des Netzwerkzugriffs verwendet werden (z.B. 'Captive Portals', die die Zustimmung zu den Nutzungsbedingungen erfordern, bevor der volle Internetzugang über einen Wi-Fi-Hotspot gewährt wird).