| Http-Statuscode | Status Code Bedeutung |
|---|
| 100 | Der Client sollte weiterhin Anfragen senden. Diese temporäre Antwort wird verwendet, um den Client darüber zu informieren, dass ein Teil seiner Anfrage vom Server empfangen und nicht abgelehnt wurde. Der Client sollte weiterhin den Rest der Anfrage senden oder diese Antwort ignorieren, wenn die Anfrage vollständig ist. Der Server muss eine letzte Antwort an den Client senden, wenn die Anfrage vollständig ist. |
| 101 | Der Server hat die Anfrage des Clients verstanden und teilt dem Client über den Header der Upgrade-Nachricht mit, dass er ein anderes Protokoll verwenden soll, um die Anfrage abzuschließen. Nach dem Senden der letzten Leerzeile dieser Antwort wechselt der Server zu den im Upgrade-Message-Header definierten Protokollen. Dies sollte nur dann geschehen, wenn es vorteilhafter ist, auf ein neues Protokoll zu wechseln. Zum Beispiel ist der Wechsel zu einer neuen Version von HTTP vorteilhafter als zu einer älteren Version oder der Wechsel zu einem Echtzeit- und Synchronprotokoll, um Ressourcen zu liefern, die solche Funktionen nutzen. |
| 102 | Statuscodes, die durch WebDAV (RFC 2518) erweitert wurden, zeigen an, dass die Verarbeitung fortgesetzt wird. |
| 200 | Die Anfrage war erfolgreich und der von der Anfrage gewünschte Antwort-Header oder Datenkörper wird mit dieser Antwort zurückgegeben. |
| 201 | Die Anforderung wurde erfüllt, und eine neue Ressource wurde gemäß den Anforderungen der Anforderung erstellt und ihr URI wurde mit dem Location-Header zurückgegeben. Wenn die erforderliche Ressource nicht rechtzeitig erstellt werden kann, sollte "202 Accepted" zurückgegeben werden. |
| 202 | Der Server hat die Anfrage angenommen, aber noch nicht verarbeitet. Genauso wie sie abgelehnt werden kann, kann die Anfrage letztendlich ausgeführt werden oder auch nicht. Im Zusammenhang mit asynchronen Operationen gibt es nichts Bequemeres als diesen Statuscode zu senden. Der Zweck der Rückgabe einer Antwort mit dem Statuscode 202 besteht darin, dem Server die Möglichkeit zu geben, Anfragen von anderen Prozessen anzunehmen (z. B. eine Batch-Operation, die nur einmal am Tag ausgeführt wird), ohne dass der Client mit dem Server verbunden bleiben muss, bis die Batch-Operation vollständig abgeschlossen ist. Eine Antwort, die eine Anfrage zur Verarbeitung annimmt und einen 202-Statuscode zurückgibt, SOLLTE in der zurückgegebenen Entität einige Informationen enthalten, die den aktuellen Status des Prozesses angeben, sowie einen Zeiger auf einen Verarbeitungsstatusmonitor oder eine Statusvorhersage, so dass der Benutzer abschätzen kann, ob der Vorgang abgeschlossen ist. |
| 203 | Der Server hat die Anfrage erfolgreich bearbeitet, aber die zurückgegebene Entity-Header-Meta-Information ist kein endgültiger, auf dem ursprünglichen Server gültiger Satz, sondern eine Kopie von einem lokalen oder dritten Anbieter. Bei den aktuellen Informationen kann es sich um eine Teilmenge oder Obermenge der ursprünglichen Version handeln. Beispielsweise können Metadaten, die Ressourcen enthalten, dazu führen, dass der ursprüngliche Server die Super-Meta-Information kennt. Die Verwendung dieses Statuscodes ist nicht erforderlich und nur dann sinnvoll, wenn die Antwort ohne ihn 200 OK zurückgegeben hätte. |
| 204 | Der Server hat die Anfrage erfolgreich bearbeitet, muss aber keine physischen Inhalte zurückgeben, sondern möchte aktualisierte Metainformationen zurückgeben. Die Antwort kann neue oder aktualisierte Metainformationen in Form von Entity-Headern zurückgeben. Wenn solche Kopfzeilen vorhanden sind, sollten sie den angeforderten Variablen entsprechen. Handelt es sich bei dem Client um einen Browser, so SOLLTE der Browser des Benutzers die Seite, auf der die Anfrage gesendet wurde, ohne Änderungen der Dokumentenansicht beibehalten, auch wenn die neuen oder aktualisierten Metainformationen gemäß der Spezifikation auf das Dokument in der aktiven Ansicht des Browsers des Benutzers angewendet werden SOLLTEN. Da die Antwort 204 keinen Nachrichtentext enthalten darf, endet sie immer mit der ersten Leerzeile nach dem Nachrichtenkopf. |
| 205 | Der Server hat die Anfrage erfolgreich bearbeitet und nichts zurückgegeben. Im Gegensatz zur Antwort 204 fordert die Antwort mit diesem Statuscode den Anfragenden jedoch auf, die Dokumentenansicht zurückzusetzen. Diese Antwort wird in erster Linie verwendet, um das Formular unmittelbar nach der Annahme von Benutzereingaben zurückzusetzen, damit der Benutzer problemlos eine weitere Eingabe starten kann. Wie die Antwort 204 darf auch diese Antwort keinen Nachrichtentext enthalten und endet mit der ersten Leerzeile nach dem Nachrichtenkopf. |
| 206 | Der Server hat einen Teil der GET-Anfrage erfolgreich verarbeitet. HTTP-Download-Tools wie FlashGet oder Thunderbolt verwenden diese Art von Antwort, um intermittierende Downloads durchzuführen oder ein großes Dokument in mehrere Download-Segmente auf einmal aufzuteilen. Die Anfrage muss einen Range-Header enthalten, um den Bereich des Inhalts anzugeben, den der Client erhalten möchte, und kann einen If-Range als Anfragebedingung enthalten. Die Antwort muss die folgenden Header-Felder enthalten: Content-Range zur Angabe des Umfangs des in dieser Antwort zurückgegebenen Inhalts; im Falle eines mehrteiligen Downloads mit einem Content-Type von multipart/byteranges sollte jedes mehrteilige Segment ein Content-Range-Feld enthalten, das den Umfang des Inhalts in diesem Segment angibt. Wenn die Antwort eine Content-Length enthält, muss ihr Wert mit der tatsächlichen Anzahl von Bytes in dem zurückgegebenen Inhaltsbereich übereinstimmen. date ETag und/oder Content-Location, wenn dieselbe Anfrage eine 200er-Antwort hätte zurückgeben sollen. Expires, Cache-Control und/oder Vary, wenn sich ihre Werte von anderen Antworten mit denselben Variablen unterscheiden können. Expires, Cache-Control und/oder Vary, wenn sich ihre Werte von den Werten anderer früherer Antworten für dieselben Variablen unterscheiden. Diese Antwort SOLLTE KEINE anderen Entity-Header enthalten, wenn die Anfrage eine starke If-Range-Cache-Validierung verwendet, und SOLLTE KEINE anderen Entity-Header enthalten, wenn die Anfrage eine schwache If-Range-Cache-Validierung verwendet; dadurch werden Inkonsistenzen zwischen gecacheten Entity-Inhalten und aktualisierten Entity-Header-Informationen vermieden. Andernfalls SOLLTE diese Antwort alle Entity-Header-Felder enthalten, die in allen 200er-Antworten hätten zurückgegeben werden müssen. Wenn die ETag- oder Last-Modified-Header nicht genau übereinstimmen, SOLLTE der clientseitige Cache die Kombination des in Antwort 206 zurückgegebenen Inhalts mit zuvor zwischengespeicherten Inhalten verbieten. Jeder Cache, der die Range- und Content-Range-Header nicht unterstützt, darf den von der 206-Antwort zurückgegebenen Inhalt nicht zwischenspeichern. |
| 207 | Der von WebDAV (RFC 2518) erweiterte Statuscode bedeutet, dass der nachfolgende Nachrichtentext eine XML-Nachricht ist und je nach Anzahl der vorherigen Unterabfragen eine Reihe separater Antwortcodes enthalten kann. |
| 300 | Die angeforderte Ressource verfügt über eine Reihe von alternativen Rückmeldungen, jede mit ihrer eigenen spezifischen Adresse und browsergesteuerten Verhandlungsinformationen. Der Benutzer oder Browser kann selbst eine bevorzugte Adresse für die Weiterleitung auswählen. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte die Antwort eine Entität enthalten, bei der es sich um eine Liste von Ressourceneigenschaften und -adressen handelt, aus der der Benutzer oder Browser die am besten geeignete Umleitungsadresse auswählen kann. Das Format dieser Entität wird durch das Format der Content-Type-Definition bestimmt. Der Browser kann auf der Grundlage des Formats der Antwort und seiner eigenen Fähigkeiten automatisch die am besten geeignete Auswahl treffen. Natürlich ist in der RFC 2616-Spezifikation nicht festgelegt, wie eine solche automatische Auswahl zu erfolgen hat. Wenn der Server selbst bereits eine bevorzugte Wahl der Rückgabe hat, dann sollte die URI dieser Rückgabe in Location angegeben werden; der Browser kann diesen Location-Wert als Adresse für die automatische Umleitung verwenden. Darüber hinaus ist diese Antwort auch cachefähig, sofern nicht anders angegeben. |
| 301 | Die angeforderte Ressource wurde dauerhaft an den neuen Speicherort verschoben, und alle künftigen Verweise auf sie sollten einen der verschiedenen in dieser Antwort zurückgegebenen URIs verwenden. Wenn möglich, sollten Clients mit Linkbearbeitungsfunktionen die angeforderte Adresse automatisch in die vom Server zurückgegebene Adresse ändern. Diese Antwort ist ebenfalls cachefähig, sofern nicht anders angegeben. Die neue permanente URI sollte im Feld Location der Antwort zurückgegeben werden. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte die Antwortentität einen Hyperlink zum neuen URI und eine kurze Beschreibung enthalten. Handelt es sich nicht um eine GET- oder HEAD-Anfrage, ist es dem Browser daher untersagt, automatisch umzuleiten, es sei denn, der Benutzer bestätigt dies, da sich die Bedingungen der Anfrage dadurch ändern können. Hinweis: Bei einigen Browsern, die das HTTP/1.0-Protokoll verwenden, wird, wenn sie eine POST-Anfrage senden und eine 301-Antwort erhalten, die nächste Umleitungsanfrage eine GET-Anfrage sein. |
| 302 | Die angeforderte Ressource antwortet nun vorübergehend auf die Anfrage von einem anderen URI. Da diese Umleitung nur vorübergehend ist, sollte der Client zukünftige Anfragen weiterhin an die ursprüngliche Adresse senden. Diese Antwort ist nur dann cachefähig, wenn sie in Cache-Control oder Expires angegeben ist. Die neue temporäre URI sollte im Feld Location der Antwort zurückgegeben werden. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte die Antwortentität einen Hyperlink zum neuen URI und eine kurze Beschreibung enthalten. Handelt es sich nicht um eine GET- oder HEAD-Anfrage, so darf der Browser keine automatische Umleitung vornehmen, es sei denn, der Benutzer bestätigt dies, da sich die Bedingungen der Anfrage dadurch ändern können. Hinweis: Obwohl die RFC 1945- und RFC 2068-Spezifikationen dem Client nicht erlauben, die Methode der Anfrage bei der Umleitung zu ändern, behandeln viele bestehende Browser die 302-Antwort als 303-Antwort und verwenden GET, um auf den in der Location angegebenen URI zuzugreifen, wobei die Methode der ursprünglichen Anfrage ignoriert wird. Die Statuscodes 303 und 307 wurden hinzugefügt, um klarzustellen, welche Antwort der Server vom Client erwartet. |
| 303 | Die Antwort auf die aktuelle Anfrage kann unter einer anderen URI gefunden werden und der Client sollte auf diese Ressource mit GET zugreifen. Diese Methode dient in erster Linie dazu, die Ausgabe von skriptaktivierten POST-Anfragen an eine neue Ressource umzuleiten. Diese neue URI ist kein alternativer Verweis auf die ursprüngliche Ressource. Außerdem darf die 303-Antwort nicht zwischengespeichert werden. Natürlich kann die zweite Anfrage (Umleitung) in den Cache gestellt werden. Die neue URI sollte im Feld Location der Antwort zurückgegeben werden. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte die Antwort-Entität einen Hyperlink zum neuen URI und eine kurze Beschreibung enthalten. Hinweis: Viele Browser vor den HTTP/1.1-Versionen verstehen den 303-Status nicht richtig. Wenn eine Interaktion mit diesen Browsern in Betracht gezogen werden muss, sollte der 302-Statuscode ausreichen, da die meisten Browser die 302-Antwort genau so behandeln, wie es die obige Spezifikation vom Client für die 303-Antwort verlangt. |
| 304 | Der Server SOLLTE diesen Statuscode zurückgeben, wenn der Client eine bedingte GET-Anfrage sendet, die zugelassen wurde und sich der Inhalt des Dokuments (entweder seit dem letzten Besuch oder gemäß den Bedingungen der Anfrage) nicht geändert hat.304-Antworten dürfen keine Nachrichtenteile enthalten und enden daher immer mit der ersten Leerzeile nach dem Nachrichtenkopf. Die Antwort MUSS die folgenden Kopfzeilen enthalten: Datum, es sei denn, der Server hat keine Uhr. Wenn ein Server ohne Uhr diese Regeln befolgt, können der Proxy-Server und der Client das Datumsfeld selbst in den Header der eingehenden Antwort einfügen (wie in RFC 2068 beschrieben), und der Caching-Mechanismus funktioniert korrekt.ETag und/oder Content-Location, wenn die gleiche Anfrage eine 200er-Antwort zurückgegeben hätte.Expires Expires, Cache-Control und/oder Vary, wenn sich der Wert möglicherweise von dem Wert unterscheidet, der anderen früheren Antworten für dieselbe Variable entspricht. Wenn diese Antwortanfrage eine starke Cache-Validierung verwendet, sollte diese Antwort keine anderen Entity-Header enthalten; andernfalls (z. B. wenn eine bedingte GET-Anfrage eine schwache Cache-Validierung verwendet) darf diese Antwort keine anderen Entity-Header enthalten; dadurch werden Inkonsistenzen zwischen zwischengespeicherten Entity-Inhalten und aktualisierten Entity-Header-Informationen vermieden. Wenn eine 304-Antwort anzeigt, dass eine Entität derzeit nicht im Cache gespeichert ist, muss das Caching-System die Antwort ignorieren und die Anfrage ohne die Einschränkung wiederholen. Wird eine 304-Antwort mit der Aufforderung empfangen, einen Cache-Eintrag zu aktualisieren, MUSS das Caching-System den gesamten Eintrag aktualisieren, um die Werte aller in der Antwort aktualisierten Felder wiederzugeben. |
| 305 | Auf die angeforderte Ressource muss über den angegebenen Proxy zugegriffen werden. Das Feld Location gibt Auskunft über den URI, in dem sich der angegebene Proxy befindet. Der Empfänger muss wiederholt eine separate Anfrage senden, um über diesen Proxy auf die Ressource zuzugreifen. Nur der ursprüngliche Server kann eine 305-Antwort erstellen. Hinweis: Aus RFC 2068 geht nicht eindeutig hervor, dass eine 305-Antwort für die Umleitung einer einzelnen Anfrage gedacht ist und nur vom ursprünglichen Server erstellt werden kann. Das Ignorieren dieser Beschränkungen könnte schwerwiegende Sicherheitsfolgen nach sich ziehen. |
| 306 | In der neuesten Version der Spezifikation wird der Statuscode 306 nicht mehr verwendet. |
| 307 | Die angeforderte Ressource antwortet nun vorübergehend auf die Anfrage von einem anderen URI aus. Da solche Umleitungen nur vorübergehend sind, sollten Clients künftige Anfragen weiterhin an die ursprüngliche Adresse senden. Diese Antwort ist nur dann cachefähig, wenn in Cache-Control oder Expires angegeben. Die neue temporäre URI sollte im Feld Location der Antwort zurückgegeben werden. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte die Antwortentität einen Hyperlink zur neuen URI und eine kurze Beschreibung enthalten. Da einige Browser die 307-Antwort nicht erkennen, müssen die oben genannten Informationen hinzugefügt werden, damit der Benutzer die neue URI verstehen und den Zugang zu ihr anfordern kann. Wenn es sich nicht um eine GET- oder HEAD-Anfrage handelt, verbietet der Browser die automatische Weiterleitung, es sei denn, der Benutzer bestätigt sie, da sich die Bedingungen der Anfrage ändern können. |
| 400 | 1. ein semantischer Fehler vorliegt und die aktuelle Anfrage vom Server nicht verstanden wird. Sofern nicht geändert, sollte der Client diese Anfrage nicht wiederholt übermitteln. 2, die Anfrageparameter sind falsch. |
| 401 | Die aktuelle Anfrage erfordert eine Benutzerauthentifizierung. Die Antwort muss einen WWW-Authenticate-Header für die angeforderte Ressource enthalten, um die Benutzerinformationen abzufragen. Der Client kann wiederholt eine Anfrage stellen, die die entsprechenden Autorisierungs-Header-Informationen enthält. Wenn die aktuelle Anfrage bereits Autorisierungsdaten enthält, bedeutet die 401-Antwort, dass der Server überprüft, dass diese Daten abgelehnt wurden. Wenn die 401-Antwort dieselbe Authentifizierungsanfrage wie die vorherige Antwort enthält und der Browser bereits mindestens einen Authentifizierungsversuch unternommen hat, dann SOLLTE der Browser dem Benutzer die in der Antwort enthaltenen Entitätsinformationen anzeigen, da diese Entitätsinformationen relevante Diagnoseinformationen enthalten können. Siehe RFC 2617. |
| 402 | Dieser Statuscode ist für mögliche zukünftige Anforderungen reserviert. |
| 403 | Der Server hat die Anfrage verstanden, weigert sich aber, sie auszuführen. Im Gegensatz zu einer 401-Antwort bietet die Authentifizierung keine Hilfe, und diese Anfrage sollte nicht erneut gesendet werden. Wenn es sich nicht um eine HEAD-Anfrage handelt und der Server klar sagen möchte, warum die Anfrage nicht ausgeführt werden kann, dann sollte der Grund für die Ablehnung innerhalb der Entität beschrieben werden. Natürlich kann der Server auch eine 404-Antwort zurückgeben, wenn er dem Client keine Informationen geben möchte. |
| 404 | Die Anfrage ist fehlgeschlagen, die angeforderte Ressource wurde auf dem Server nicht gefunden. Es gibt keine Informationen, die dem Benutzer sagen, ob die Situation vorübergehend oder dauerhaft ist. Wenn dem Server die Situation bekannt ist, sollte er den Statuscode 410 verwenden, um dem Benutzer mitzuteilen, dass die alte Ressource aufgrund eines internen Konfigurationsmechanismus dauerhaft nicht verfügbar ist und dass keine Umleitung möglich ist. 404 wird häufig verwendet, wenn der Server nicht mitteilen möchte, warum die Anfrage abgelehnt wurde oder wenn keine andere geeignete Antwort verfügbar ist. |
| 405 | Die in der Anforderungszeile angegebene Anforderungsmethode kann nicht verwendet werden, um die entsprechende Ressource anzufordern. Die Antwort muss einen Allow-Header zurückgeben, der die Liste der für die aktuelle Ressource zulässigen Anforderungsmethoden angibt. Da die PUT- und DELETE-Methoden in die Ressource auf dem Server schreiben, unterstützen die meisten Webserver diese Anforderungsmethoden nicht oder lassen sie standardmäßig nicht zu und geben für solche Anforderungen einen 405-Fehler zurück. |
| 406 | Die inhaltlichen Eigenschaften der angeforderten Ressource erfüllen nicht die Bedingungen im Request-Header, und eine Response Entity kann nicht erzeugt werden. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte die Antwort eine Entität zurückgeben, die eine Liste von Entitätsmerkmalen und Adressen enthält, aus der der Benutzer oder Browser die am besten geeignete auswählen kann. Das Format der Entität wird durch den im Content-Type-Header definierten Medientyp bestimmt. Die Browser können auf der Grundlage des Formats und ihrer eigenen Fähigkeiten die beste Wahl treffen. Die Spezifikation legt jedoch keine Kriterien für eine solche automatische Auswahl fest. |
| 407 | Ähnlich wie die 401-Antwort, mit dem Unterschied, dass sich der Client beim Proxy-Server authentifizieren MUSS. Der Proxy-Server MUSS ein Proxy-Authenticate zur Identitätsabfrage zurücksenden. Der Client KANN einen Proxy-Authorization-Header für die Authentifizierung zurückgeben. Siehe RFC 2617. |
| 408 | Anfrage-Zeitüberschreitung. Der Client hat das Senden einer Anfrage nicht innerhalb der Zeit abgeschlossen, die der Server bereit war zu warten. Der Client kann die Anfrage jederzeit erneut senden, ohne Änderungen vorzunehmen. |
| 409 | Die Anfrage konnte aufgrund eines Konflikts mit dem aktuellen Zustand der angeforderten Ressource nicht abgeschlossen werden. Dieser Code darf nur verwendet werden, wenn der Benutzer in der Lage ist, den Konflikt zu lösen und eine neue Anfrage zu stellen. Die Antwort sollte genügend Informationen enthalten, damit der Benutzer die Ursache des Konflikts ermitteln kann. Konflikte treten typischerweise bei der Verarbeitung von PUT-Anfragen auf. Wenn z. B. in einer Umgebung mit Versionskontrolle die Versionsinformationen, die einer PUT-Anfrage zur Änderung einer bestimmten Ressource beigefügt sind, mit einer früheren (fremden) Anfrage in Konflikt stehen, sollte der Server einen 409-Fehler zurückgeben, der den Benutzer darüber informiert, dass die Anfrage nicht abgeschlossen werden konnte. In diesem Fall wird die Antwort-Entität wahrscheinlich einen Vergleich der Unterschiede zwischen den beiden kollidierenden Versionen enthalten, so dass der Benutzer die neue Version nach der Zusammenführung erneut übermitteln kann. |
| 410 | Die angeforderte Ressource ist auf dem Server nicht mehr verfügbar und hat keine bekannte Weiterleitungsadresse. Ein solcher Zustand sollte als dauerhaft angesehen werden. Wenn möglich, sollten Clients mit Linkbearbeitungsfunktionen alle Verweise auf diese Adresse mit Erlaubnis des Benutzers entfernen. Wenn der Server nicht weiß oder nicht feststellen kann, ob diese Bedingung dauerhaft ist, sollte ein 404-Statuscode verwendet werden. Sofern nicht anders angegeben, ist diese Antwort zwischenspeicherbar.410 Der Zweck dieser Antwort besteht in erster Linie darin, den Webmaster bei der Pflege der Website zu unterstützen, indem er den Benutzer darüber informiert, dass die Ressource nicht mehr verfügbar ist und dass der Servereigentümer wünscht, dass alle Fernverbindungen zu dieser Ressource ebenfalls entfernt werden. Diese Art von Ereignissen ist bei zeitlich begrenzten Diensten mit Mehrwert üblich. In ähnlicher Weise wird die 410-Antwort verwendet, um Clients zu benachrichtigen, dass eine Ressource, die ursprünglich zu einer Person auf der aktuellen Server-Site gehörte, nicht mehr verfügbar ist. Natürlich bleibt es dem Eigentümer des Servers überlassen, ob alle dauerhaft nicht verfügbaren Ressourcen als "410 Gone" gekennzeichnet werden müssen und wie lange diese Kennzeichnung beibehalten werden muss. |
| 411 | Der Server weigert sich, Anfragen ohne den Content-Length-Header zu akzeptieren. Nach dem Hinzufügen eines gültigen Content-Length-Headers, der die Länge des Nachrichtentextes der Anfrage angibt, kann der Client die Anfrage erneut übermitteln. |
| 412 | Der Server konnte eine oder mehrere Voraussetzungen nicht erfüllen, als er prüfte, ob sie im Header-Feld der Anfrage angegeben wurden. Dieser Statuscode ermöglicht es dem Client, in der Metameldung der Anfrage (Daten des Anfrage-Header-Feldes) Vorbedingungen zu setzen, wenn er eine Ressource abruft, und so zu verhindern, dass die Anfragemethode auf andere Ressourcen als den gewünschten Inhalt angewendet wird. |
| 413 | Der Server weigert sich, die aktuelle Anfrage zu bearbeiten, weil sie Entitätsdaten enthält, die größer sind als der Server bereit oder in der Lage ist, sie zu verarbeiten. In diesem Fall kann der Server die Verbindung schließen, um den Client daran zu hindern, diese Anfrage weiter zu senden. Wenn dieser Zustand vorübergehend ist, sollte der Server einen Retry-After-Antwort-Header zurücksenden, um dem Client mitzuteilen, nach wie viel Zeit er es erneut versuchen kann. |
| 414 | Die Länge des URI der Anfrage übersteigt die Länge, die der Server interpretieren kann, so dass der Server sich weigert, die Anfrage zu bedienen. Dies kommt selten vor und ist oft der Fall, wenn ein Formular, das mit der POST-Methode übermittelt werden sollte, zur GET-Methode wird, was zu einem langen Query-String führt. Schwarze Löcher" in der URI-Umleitung, z. B. die Verwendung der alten URI als Teil der neuen URI bei jeder Umleitung, was nach mehreren Umleitungen zu einer langen URI führt. Clients versuchen, Server anzugreifen, indem sie Sicherheitslücken ausnutzen, die bei einigen Servern bestehen. Solche Server verwenden einen Puffer mit fester Länge, um den URI einer Anfrage zu lesen oder zu manipulieren. Wenn die Parameter nach einem GET einen bestimmten Wert überschreiten, kann es zu einem Pufferüberlauf kommen, der zur Ausführung von beliebigem Code führt [1]. Server ohne solche Schwachstellen sollten einen Statuscode 414 zurückgeben. |
| 415 | Für die aktuell angeforderte Methode und die angeforderte Ressource liegt die in der Anforderung übermittelte Entität nicht in einem vom Server unterstützten Format vor, so dass die Anforderung zurückgewiesen wird. |
| 416 | Wenn die Anforderung einen Range-Anforderungsheader enthält und alle im Range angegebenen Datenbereiche sich nicht mit den für die aktuelle Ressource verfügbaren Bereichen überschneiden und der If-Range-Anforderungsheader in der Anforderung nicht definiert ist, sollte der Server einen Statuscode 416 zurückgeben. Wenn Range Byte-Bereiche verwendet, ist dies der Fall, wenn die erste Byte-Position aller in der Anfrage angegebenen Datenbereiche die Länge der aktuellen Ressource überschreitet. Der Server sollte auch einen Content-Range-Entity-Header einfügen, der die Länge der aktuellen Ressource zusammen mit dem 416-Statuscode angibt. Diese Antwort darf auch nicht multipart/byteranges als Content-Type verwenden. |
| 417 | Der erwartete Inhalt, der im Request-Header Expect angegeben ist, kann vom Server nicht erfüllt werden, oder dieser Server ist ein Proxy-Server, der eindeutige Hinweise darauf hat, dass der Inhalt von Expect am nächsten Knoten in der aktuellen Route nicht erfüllt werden kann. |
| 421 | Die Anzahl der Verbindungen zum Server von der IP-Adresse, an der sich der aktuelle Client befindet, übersteigt die vom Server erlaubte Höchstzahl. Normalerweise bezieht sich die IP-Adresse hier auf die Adresse des Clients, wie sie vom Server aus gesehen wird (z. B. die Gateway- oder Proxy-Server-Adresse des Benutzers). In diesem Fall kann die Anzahl der Verbindungen mehr als einen Endbenutzer betreffen. |
| 422 | Die Anzahl der Verbindungen zum Server von der IP-Adresse des aktuellen Clients aus überschreitet die vom Server erlaubte Höchstzahl. Normalerweise bezieht sich die IP-Adresse hier auf die Adresse des Clients, wie sie vom Server aus gesehen wird (z. B. die Gateway- oder Proxy-Server-Adresse des Benutzers). In diesem Fall kann die Anzahl der Verbindungen mehr als einen Endbenutzer betreffen. |
| 422 | Die Anfrage war korrekt formatiert, konnte aber nicht beantwortet werden, da sie semantische Fehler enthielt. (RFC 4918 WebDAV) 423 Gesperrt Die aktuelle Ressource ist gesperrt. (RFC 4918 WebDAV) |
| 424 | Die aktuelle Anfrage ist aufgrund eines Fehlers bei einer früheren Anfrage, z. B. PROPPATCH, fehlgeschlagen (RFC 4918 WebDAV). |
| 425 | Definiert im WebDav Advanced Collections Draft, erscheint aber nicht im WebDAV Sequential Collections Protocol (RFC 3658). |
| 426 | Clients sollten zu TLS/1.0 wechseln.(RFC 2817) |
| 449 | Von Microsoft erweitert, um darzustellen, dass Anfragen erneut versucht werden sollten, nachdem die entsprechende Aktion durchgeführt wurde. |
| 500 | Der Server ist auf eine unvorhergesehene Bedingung gestoßen, die ihn daran hindert, die Verarbeitung der Anfrage abzuschließen. Typischerweise tritt dieses Problem auf, wenn ein Fehler im Programmcode des Servers vorliegt. |
| 501 | Der Server unterstützt eine bestimmte Funktion nicht, die für die aktuelle Anfrage erforderlich ist. Wenn der Server die angeforderte Methode nicht erkennen kann und nicht in der Lage ist, die Anfrage nach einer Ressource zu unterstützen. |
| 502 | Ein Server, der als Gateway oder Proxy arbeitet, erhält eine ungültige Antwort von einem vorgeschalteten Server, wenn er versucht, eine Anfrage auszuführen. |
| 503 | Der Server kann die Anfrage aufgrund einer vorübergehenden Serverwartung oder Überlastung derzeit nicht bearbeiten. Dieser Zustand ist vorübergehend und wird nach einiger Zeit wiederhergestellt. Wenn eine Verzögerung zu erwarten ist, kann die Antwort einen Retry-After-Header enthalten, um die Verzögerung anzuzeigen. Wenn diese Retry-After-Information nicht angegeben wird, sollte der Client sie wie eine 500er-Antwort behandeln. Hinweis: Das Vorhandensein des Statuscodes 503 bedeutet nicht, dass der Server ihn verwenden muss, wenn er überlastet ist. Manche Server wollen dem Client einfach die Verbindung verweigern. |
| 504 | Ein Server, der als Gateway oder Proxy arbeitet und versucht, eine Anfrage auszuführen, erhält keine rechtzeitige Antwort von einem vorgelagerten Server (ein Server, der durch einen URI identifiziert wird, wie HTTP, FTP, LDAP) oder einem sekundären Server (wie DNS). Hinweis: Einige Proxy-Server geben einen 400- oder 500-Fehler zurück, wenn die DNS-Suche fehlschlägt. |
| 505 | Der Server unterstützt die in der Anfrage verwendete HTTP-Version nicht oder weigert sich, sie zu unterstützen. Dies bedeutet, dass der Server nicht in der Lage oder nicht willens ist, die gleiche Version wie der Client zu verwenden. Die Antwort sollte eine Entität enthalten, die beschreibt, warum die Version nicht unterstützt wird und welche Protokolle der Server unterstützt. |
| 506 | Erweitert durch das Transparent Content Negotiation Protocol (RFC 2295), um eine interne Fehlkonfiguration auf Seiten des Servers darzustellen: Die angeforderte Negotiation Variant-Ressource ist so konfiguriert, dass sie sich selbst in der transparenten Inhaltsverhandlung verwendet und daher kein geeigneter Fokus in einem Verhandlungsprozess ist. |
| 507 | Der Server ist nicht in der Lage, den für die Bearbeitung der Anfrage erforderlichen Inhalt zu speichern. Dieser Zustand wird als vorübergehend betrachtet.WebDAV (RFC 4918) |
| 509 | Der Server hat sein Bandbreitenlimit erreicht. Dies ist kein offizieller Statuscode, wird aber dennoch häufig verwendet. |
| 510 | Die für den Erhalt der Ressource erforderliche Richtlinie wurde nicht nicht erfüllt. (RFC 2774) |