Tipps: Strg F schnell finden| HTTP-Status code | Bedeutung des Status codes |
|---|---|
| 100 | Der Client sollte die Anfrage weiterhin senden. Diese temporäre Antwort wird verwendet, um den Client darüber zu informieren, dass ein Teil seiner Anforderungen vom Server empfangen und nicht abgelehnt wurde. Der Client sollte weiterhin den Rest der Anfrage senden oder die Antwort ignorieren, wenn die Anfrage abgeschlossen wurde. Der Server muss nach Abschluss der Anforderung eine endgültige Antwort an den Client senden. |
| 101 | Der Server hat die Anfrage des Clients verstanden und wird dem Client über den Upgrade-Header mitteilen, dass er ein anderes Protokoll verwenden wird, um die Anfrage abzuschließen. Nach dem Senden des letzten leeren Zeilens in dieser Antwort wechselt der Server zu den im Upgrade-Header definierten Protokollen. Solche Maßnahmen sollten nur ergriffen werden, wenn die Umstellung auf ein neues Protokoll vorteilhafter ist. Beispielsweise kann der Wechsel zu einer neuen HTTP-Version vorteilhafter sein als die Verwendung der älteren Version, oder es kann sinnvoll sein, auf ein Echtzeit- und synchrones Protokoll umzusteigen, um Ressourcen zu übertragen, die solche Funktionen nutzen. |
| 102 | Der durch WebDAV(RFC 2518) erweiterte Status code bedeutet, dass die Verarbeitung fortgesetzt wird. |
| 200 | Die Anforderung ist erfolgreich und der gewünschte Antwort header oder Daten körper der Anforderung wird mit dieser Antwort zurück gegeben. |
| 201 | Die Anforderung wurde implementiert und eine neue Ressource wurde entsprechend den Anforderungen der Anforderung eingerichtet, und der URI wurde mit den Informationen des Location-Header zurück gegeben. Wenn die benötigten Ressourcen nicht rechtzeitig eingerichtet werden können, sollten sie an '202 Accepted' zurück gegeben werden. |
| 202 | Der Server hat die Anfrage angenommen, aber noch nicht verarbeitet. So wie es abgelehnt werden kann, kann die Anfrage letztendlich ausgeführt werden oder nicht. Bei asynchronen Vorgängen gibt es keinen bequemeren Weg als das Senden dieses Status codes. Der Zweck der Rückgabe der Antwort auf den Status code 202 besteht darin, dem Server zu ermöglichen, Anforderungen für andere Prozesse zu akzeptieren (z. B. einen Batch-basierten Vorgang, der nur einmal täglich ausgeführt wird), ohne dass der Client mit dem Server verbunden bleibt, bis der Batch vorgang abgeschlossen ist. Die Antwort, die die Verarbeitung der Anforderung akzeptiert und den Status code 202 zurückgibt, sollte einige Informationen enthalten, die den aktuellen Status der Verarbeitung in der zurück gegebenen Entität anzeigen, sowie einen Zeiger auf den Status monitor oder die Status vorhersage der Verarbeitung, damit der Benutzer abschätzen kann, ob der Vorgang abgeschlossen wurde. |
| 203 | Der Server hat die Anforderung erfolgreich verarbeitet, aber die zurück gegebenen Entität header-Meta informationen sind keine gültige Sammlung auf dem ursprünglichen Server, sondern eine Kopie von einem lokalen oder Dritten. Die aktuellen Informationen können Teilmengen oder Obermengen der Original version sein. Beispiels weise können Metadaten, die Ressourcen enthalten, dazu führen, dass der ursprüngliche Server die Meta informationen super kennt. Es ist nicht erforderlich, diesen Status code zu verwenden, und es ist nur geeignet, wenn die Antwort 200 OK zurückgibt, ohne diesen Status code zu verwenden. |
| 204 | Der Server hat die Anforderung erfolgreich verarbeitet, muss jedoch keinen Entität inhalt zurückgeben und möchte die aktualisierten Meta informationen zurückgeben. Die Antwort kann die Form des Entität kopfes durchlaufen, um neue oder aktualisierte Meta informationen zurück zugeben. Wenn diese Header informationen vorhanden sind, sollten sie mit der angeforderten Variablen übereinstimmen. Wenn der Client ein Browser ist, sollte der Benutzer browser die Seite behalten, auf der die Anforderung gesendet wurde, ohne Änderungen in der Dokument ansicht zu verursachen, selbst wenn die neuen oder aktualisierten Meta informationen gemäß der Spezifikation auf den Benutzer browser angewendet werden sollten. Das Dokument in der aktiven Ansicht. Da die Antwort 204 keinen Nachrichten körper enthalten darf, endet sie immer mit der ersten leeren Zeile hinter dem Nachrichten kopf. |
| 205 | Der Server hat die Anforderung erfolgreich verarbeitet und nichts zurück gegeben. Im Gegensatz zur Antwort 204 fordert die Antwort, die diesen Status code zurückgibt, den Request auf, die Dokument ansicht zurück zusetzen. Die Antwort wird haupt sächlich verwendet, um das Formular unmittelbar nach dem Akzeptieren der Benutzer eingabe zurück zusetzen, so dass der Benutzer leicht eine weitere Eingabe starten kann. Wie die Antwort 204 darf auch die Antwort keinen Nachrichten körper enthalten und endet mit der ersten Leerzeile hinter dem Nachrichten header. |
| 206 | Der Server hat einige GET-Anfragen erfolgreich verarbeitet. HTTP-Download-Tools wie FlashGet oder Xunlei nutzen solche Antworten, um das Weiterführen von unterbrochenen Downloads zu ermöglichen oder eine große Datei in mehrere Download-Abschnitte aufzuteilen, die gleichzeitig heruntergeladen werden. Die Anfrage muss den Range-Header enthalten, um den vom Client gewünschten Inhaltsbereich anzugeben, und kann gegebenenfalls den If-Range-Header als Anfragebedingung enthalten. Die Antwort muss die folgenden Kopffelder enthalten: Content-Range, um den Bereich der in dieser Antwort zurückgegebenen Inhalte anzugeben; bei einem mehrteiligen Download mit dem Inhaltstyp multipart/byteranges muss jedes Multipart-Teil das Feld Content-Range enthalten, um den Inhaltsbereich dieses Teils anzugeben. Wenn die Antwort den Header „Content-Length“ enthält, muss der angegebene Wert mit der tatsächlichen Anzahl der Bytes des zurückgegebenen Inhaltsbereichs übereinstimmen. Datum ETag und/oder Content-Location, falls dieselbe Anfrage eigentlich eine 200-Antwort zurückgeben sollte. Ablaufdatum, Cache-Control und/oder Vary, falls ihre Werte sich von den Werten anderer Antworten für dieselben Variablen unterscheiden könnten.Wenn diese Antwort anforderung die Validierung des starken If-Range-Caches verwendet, sollte dieser Ring keine anderen Entität header enthalten. Wenn die Anforderung dieser Antwort die Validierung des schwachen If-Range-Caches verwendet, darf diese Antwort keine anderen Entität header enthalten. Dies vermeidet Inkonsistenzen zwischen zwischen gespeicherten Entität inhalten und aktualisierten Entität header informationen. Andernfalls sollte diese Antwort alle Entity-Header-Domänen enthalten, die in der 200-Antwort zurück gegeben werden sollten. Wenn der ETag-oder Last-Modified-Kopf nicht genau übereinstimmen kann, sollte der Client-Cache verhindern, dass der in der Antwort 206 zurück gegebene Inhalt mit dem zuvor zwischen gespeicherten Inhalt kombiniert wird. Jeder Cache, der Range-und Content-Range-Header nicht unterstützt, verbietet das Caching von Inhalten, die von der Antwort 206 zurück gegeben werden. |
| 207 | Der durch WebDAV(RFC 2518) erweiterte Status code stellt dar, dass der nachfolgende Nachrichten körper eine XML-Nachricht ist und je nach Anzahl der vorherigen Unter anforderungen eine Reihe unabhängiger Antwort codes enthalten kann. |
| 300 | Die angeforderte Ressource verfügt über eine Reihe von Feedback-Informationen zur Auswahl, von denen jede über ihre eigene spezifische Adresse und browser gesteuerte Verhandlungs informationen verfügt. Benutzer oder Browser können selbst eine bevorzugte Adresse für die Umleitung auswählen. Sofern es sich nicht um eine HEAD-Anforderung handelt, sollte die Antwort eine Entität einer Liste von Ressourcen merkmalen und-adressen enthalten, damit der Benutzer oder der Browser die am besten geeignete Umleitung adresse auswählen kann. Das Format dieser Entität wird durch das von Content-Type definierte Format bestimmt. Der Browser kann automatisch die am besten geeignete Auswahl treffen, die auf dem Format der Antwort und den eigenen Fähigkeiten des Browsers basiert. Natürlich regelt die RFC 2616-Spezifikation nicht, wie eine solche automatische Auswahl erfolgen soll. Wenn der Server selbst bereits über die bevorzugte Rückkopplung option verfügt, sollte der URI des Rückkopplung im Standort angegeben werden. Der Browser verwendet diesen Standort wert möglicher weise als Adresse für die automatische Umleitung. Darüber hinaus ist diese Antwort auch zwischen gespeichert, sofern nicht zusätzlich angegeben. |
| 301 | Die angeforderte Ressource wurde dauerhaft an einen neuen Speicherort verschoben, und jeder zukünftige Verweis auf diese Ressource sollte einen der mehreren URIs verwenden, die von dieser Antwort zurück gegeben werden. Wenn möglich, sollte ein Client mit einer Link bearbeitungs funktion die angeforderte Adresse automatisch in eine vom Server zurück gegebene Adresse ändern. Diese Antwort kann auch zwischen gespeichert werden, sofern nicht zusätzlich angegeben. Der neue permanente URI sollte in der Antwort domäne zurück gegeben werden. Sofern es sich nicht um eine HEAD-Anforderung handelt, sollte die antworten den Entitäten einen Hyperlink und eine kurze Beschreibung zum neuen URI enthalten. Wenn dies keine GET-oder HEAD-Anforderung ist, verbietet der Browser die automatische Weiter leitung, es sei denn, sie wird vom Benutzer bestätigt, da sich die Anforderung bedingungen ändern können. Hinweis: Bei einigen Browsern, die das HTTP/1.0-Protokoll verwenden, wird die nächste Weiter leitungs anfrage in eine GET-Methode geändert, wenn die von ihnen gesendete POST-Anfrage eine 301-Antwort erhält. |
| 302 | Die angeforderte Ressource reagiert nun vorübergehend auf die Anforderung von einem anderen URI. Da eine solche Umleitung vorübergehend ist, sollte der Client weiterhin zukünftige Anfragen an die ursprüngliche Adresse senden. Diese Antwort kann nur zwischen gespeichert werden, wenn sie in Cache-Control oder Expires angegeben wurde. Der neue temporäre URI sollte in der Antwort domäne zurück gegeben werden. Sofern es sich nicht um eine HEAD-Anforderung handelt, sollte die antworten den Entitäten einen Hyperlink und eine kurze Beschreibung zum neuen URI enthalten. Wenn dies keine GET-oder HEAD-Anforderung ist, verbietet der Browser die automatische Umleitung, es sei denn, sie wird vom Benutzer bestätigt, da sich die Anforderung bedingungen ändern können. Hinweis: Obwohl die Spezifikationen von RFC 1945 und RFC 2068 es Clients nicht ermöglichen, die angeforderte Methode während der Umleitung zu ändern, betrachten viele vorhandene Browser die 302-Antwort als 303-Antwort und verwenden die GET-Methode, um auf den im Ort angegebenen URI zuzugreifen, wobei das Original ignoriert wird Die angeforderte Methode. Die Status codes 303 und 307 wurden hinzugefügt, um zu klären, welche Art von Reaktion der Server vom Client erwartet. |
| 303 | Die Antwort, die der aktuellen Anforderung entspricht, kann auf einem anderen URI gefunden werden, und der Client sollte GET verwenden, um auf diese Ressource zuzugreifen. Diese Methode ist in erster Linie vorhanden, um die Ausgabe einer POST-Anforderung, die durch ein Skript aktiviert wird, auf eine neue Ressource umzuleiten. Dieser neue URI ist kein alternativer Verweis auf die ursprüngliche Ressource. Gleichzeitig darf die 303-Antwort nicht zwischen gespeichert werden. Natürlich kann die zweite Anforderung (Umleitung) zwischen gespeichert werden. Der neue URI sollte in der Heimat domäne der Antwort zurück gegeben werden. Sofern es sich nicht um eine HEAD-Anforderung handelt, sollte die antworten den Entitäten einen Hyperlink und eine kurze Beschreibung zum neuen URI enthalten. Hinweis: Viele frühere Browser von HTTP/Version 1.1 verstehen den Status 303 nicht richtig. Wenn Sie die Interaktion mit diesen Browsern berücksichtigen müssen, sollte der Status code 302 kompetent sein, da die meisten Browser 302 Antworten verarbeiten, wenn die obige Spezifikation erfordert, dass der Client 303 Antworten verarbeitet. |
| 304 | Wenn der Client eine bedingte GET-Anforderung sendet und die Anforderung zulässig ist und sich der Inhalt des Dokuments (seit dem letzten Zugriff oder gemäß den angeforderten Bedingungen) nicht geändert hat, sollte der Server diesen Status code zurückgeben. Die 304-Antwort verbietet das Einschließen des Nachrichten körpers und endet daher immer mit der ersten leeren Zeile hinter dem Nachrichten kopf. Die Antwort muss die folgenden Header-Informationen enthalten: Datum, es sei denn, dieser Server hat keine Uhr. Wenn ein Server ohne Uhr diese Regeln ebenfalls einhält, können der Proxy server und der Client das Datum-Feld dem empfangenen Antwort header hinzufügen (wie in RFC 2068 angegeben), und der Cache-Mechanismus funktioniert normal. ETag und/oder Content-Location, wenn dieselbe Anfrage 200 Antworten zurückgeben sollte. Expires,Cache-Control und/oder Vary, wenn ihr Wert von dem Wert abweicht, der anderen Antworten derselben Variablen zuvor entspricht.Wenn in dieser Antwort anforderung eine starke Cache-Überprüfung verwendet wird, sollte dieser Ring keine anderen Entität header enthalten. Andernfalls (z. B. verwendet eine bestimmte bedingte GET-Anforderung eine schwache Cache-Überprüfung) verbietet diese Antwort die Aufnahme anderer Entität header. Dies vermeidet Inkonsistenzen zwischen zwischen gespeicherten Entität inhalten und aktualisierten Entität header informationen. Wenn eine 304-Antwort angibt, dass eine Entität derzeit keinen Cache hat, muss das Cache-System diese Antwort ignorieren und wiederholt Anfragen senden, die keine Einschränkungen enthalten. Wenn Sie eine 304-Antwort erhalten, die eine Aktualisierung eines Cache-Eintrags erfordert, muss das Cache-System den gesamten Eintrag aktualisieren, um die Werte aller in der Antwort aktualisierten Felder wider zu spiegeln. |
| 305 | Auf die angeforderte Ressource muss über den angegebenen Proxy zugegriffen werden. Die Standort domäne gibt die URI-Informationen an, in denen sich der angegebene Agent befindet. Der Empfänger muss wiederholt eine separate Anforderung senden, über die auf die entsprechende Ressource zugegriffen werden kann. Nur der ursprüngliche Server kann eine 305-Antwort erstellen. Hinweis: In RFC 2068 gibt es keine eindeutige 305-Antwort, um eine separate Anforderung umzuleiten, und sie kann nur vom ursprünglichen Server erstellt werden. Das Ignorieren dieser Einschränkungen kann zu schwer wiegenden Sicherheits folgen führen. |
| 306 | In der neuesten Version der Spezifikation wird der 306-Status code nicht mehr verwendet. |
| 307 | Die angeforderte Ressource reagiert nun vorübergehend auf die Anforderung von einem anderen URI. Da eine solche Umleitung vorübergehend ist, sollte der Client weiterhin zukünftige Anfragen an die ursprüngliche Adresse senden. Diese Antwort kann nur zwischen gespeichert werden, wenn sie in Cache-Control oder Expires angegeben wurde. Der neue temporäre URI sollte in der Antwort domäne zurück gegeben werden. Sofern es sich nicht um eine HEAD-Anforderung handelt, sollte die antworten den Entitäten einen Hyperlink und eine kurze Beschreibung zum neuen URI enthalten. Da einige Browser die 307-Antwort nicht erkennen können, müssen die oben genannten erforderlichen Informationen hinzugefügt werden, damit der Benutzer die Zugriffs anforderung an den neuen URI verstehen und senden kann. Wenn dies keine GET-oder HEAD-Anforderung ist, verbietet der Browser die automatische Umleitung, es sei denn, sie wird vom Benutzer bestätigt, da sich die Anforderung bedingungen ändern können. |
| 400 | 1. Die Semantik ist falsch und die aktuelle Anforderung kann vom Server nicht verstanden werden. Sofern keine Änderungen vorgenommen werden, sollte der Client diese Anforderung nicht wiederholt einreichen. 2. Die Anforderung parameter sind falsch. |
| 401 | Die aktuelle Anforderung erfordert eine Benutzer authentifizierung. Die Antwort muss einen WWW-Authenticate-Informations kopf enthalten, der für die angeforderte Ressource gilt, um Benutzerin formationen abzufragen. Der Client kann wiederholt eine Anfrage einreichen, die die entsprechenden Informationen zum Authorization-Header enthält. Wenn die aktuelle Anforderung bereits ein Authorization-Zertifikat enthält, bedeutet die Antwort 401, dass der Server überprüft, dass diese Zertifikate abgelehnt wurden. Wenn die 401-Antwort dieselbe Authentifizierungs anfrage wie die vorherige Antwort enthält und der Browser mindestens eine Überprüfung versucht hat, sollte der Browser dem Benutzer die in der Antwort enthaltenen Entität informationen anzeigen, da diese Entität informationen möglicher weise verwandte Diagnose informationen enthalten. Siehe RFC 2617. |
| 402 | Der Status code ist für mögliche zukünftige Bedürfnisse reserviert. |
| 403 | Der Server hat die Anforderung verstanden, weigert sich jedoch, sie auszuführen. Im Gegensatz zur 401-Antwort bietet die Authentifizierung keine Hilfe, und diese Anfrage sollte nicht wiederholt gesendet werden. Wenn dies keine HEAD-Anforderung ist und der Server klarstellen möchte, warum die Anforderung nicht ausgeführt werden kann, 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 der Client keine Informationen erhalten soll. |
| 404 | Die Anforderung schlägt fehl und die gewünschte Ressource wurde nicht auf dem Server gefunden. Es gibt keine Informationen, die den Benutzern mitteilen können, ob diese Situation vorübergehend oder dauerhaft ist. Wenn der Server die Situation kennt, sollte er den Status code 410 verwenden, um die alte Ressource darüber zu informieren, dass sie aufgrund einiger interner Konfiguration mechanismus probleme dauerhaft nicht verfügbar ist und keine Adresse hat, die umgeleitet werden kann. Der Status code 404 wird häufig verwendet, wenn der Server nicht offenlegen möchte, warum die Anforderung abgelehnt wurde oder keine andere geeignete Antwort verfügbar ist. |
| 405 | Die in der Anforderung zeile angegebene Anforderung methode kann nicht verwendet werden, um die entsprechende Ressource anzufordern. Die Antwort muss eine Allow-Header-Information zurückgeben, die eine Liste der Anforderung methoden darstellt, die die aktuelle Ressource akzeptieren kann. In Anbetracht der PUT schreibt die DELETE-Methode die Ressourcen auf dem Server, sodass die meisten Webserver die oben genannten Anforderung methoden unter der Standard konfiguration nicht unterstützen oder zulassen und 405-Fehler für solche Anfragen zurück gegeben werden. |
| 406 | Die Inhalts eigenschaften der angeforderten Ressource können die Bedingungen im Anforderung header nicht erfüllen, sodass keine Antwort entitäten generiert werden können. Sofern es sich nicht um eine HEAD-Anforderung handelt, sollte die Antwort eine Entität zurückgeben, die eine Liste der am besten geeigneten Entität merkmale und Adressen enthält, aus denen Benutzer oder Browser auswählen können. Das Format einer Entität wird durch den im Content-Type-Header definierten Medien typ bestimmt. Der Browser kann die beste Wahl basierend auf dem Format und seinen eigenen Fähigkeiten treffen. Die Spezifikation definiert jedoch keine Kriterien für eine solche automatische Auswahl. |
| 407 | Ähnlich wie die 401-Antwort, außer dass der Client auf dem Proxy server authentifi ziert werden muss. Der Proxy server muss ein Proxy-Authenticate für die Identitäts anfrage zurückgeben. Der Client kann einen Proxy-Authorization-Informations kopf zur Überprüfung zurückgeben. Siehe RFC 2617. |
| 408 | Timeout der Anfrage. Der Client hat das Senden einer Anfrage nicht innerhalb der Wartezeit des Servers abgeschlossen. Der Client kann diese Anforderung jederzeit erneut senden, ohne Änderungen vorzunehmen. |
| 409 | Die Anforderung kann aufgrund eines Konflikts mit dem aktuellen Status der angeforderten Ressource nicht abgeschlossen werden. Dieser Code darf nur unter solchen Umständen verwendet werden: Der Benutzer wird als in der Lage angesehen, den Konflikt zu lösen, und eine neue Anforderung wird erneut gesendet. Die Antwort sollte genügend Informationen enthalten, damit der Benutzer die Quelle des Konflikts erkennen kann. Konflikte treten normaler weise bei der Verarbeitung von PUT-Anfragen auf. In einer Umgebung, in der die Versions prüfung verwendet wird, stehen beispiels weise die Versions informationen, die mit der von PUT übermittelten Änderungs anforderung für eine bestimmte Ressource verbunden sind, in Konflikt mit der vorherigen Anforderung eines bestimmten (Dritt anbieters). Dann sollte der Server einen 409-Fehler zurückgeben. Informieren Sie den Benutzer, dass die Anforderung nicht abgeschlossen werden kann. Zu diesem Zeitpunkt wird die Antwort entität höchst wahr schein lich einen Vergleich der Unterschiede zwischen zwei wider sprüch lichen Versionen enthalten, damit der Benutzer eine neue Version erneut einreichen kann, die zusammen geführt wurde. |
| 410 | Die angeforderte Ressource ist auf dem Server nicht mehr verfügbar, und es ist keine bekannte Weiterleitungsadresse vorhanden. Ein solcher Zustand sollte als dauerhaft angesehen werden. Wenn möglich, sollte ein Client mit Linkbearbeitungsfunktion nach Erteilung der Nutzereinwilligung alle Verweise auf diese Adresse löschen. Wenn der Server nicht weiß oder nicht feststellen kann, ob dieser Zustand dauerhaft ist, sollte der Statuscode 404 verwendet werden. Sofern nicht zusätzlich angegeben, ist diese Antwort cachebar. Der Hauptzweck der 410-Antwort besteht darin, Website-Administratoren bei der Wartung der Website zu unterstützen, Benutzer darüber zu informieren, dass die Ressource nicht mehr verfügbar ist, und dem Serverbesitzer zu ermöglichen, zu veranlassen, dass alle Remote-Verbindungen zu dieser Ressource ebenfalls gelöscht werden. Solche Vorfälle sind in zeitlich begrenzten Zusatzdiensten sehr häufig. Ebenso wird die 410-Antwort verwendet, um den Client darüber zu informieren, dass eine Ressource, die ursprünglich einer bestimmten Person auf der aktuellen Serverseite gehörte, nicht mehr verfügbar ist. Natürlich liegt es ganz im Ermessen des Serverinhabers, ob alle dauerhaft nicht verfügbaren Ressourcen mit dem Statuscode „410 Gone“ gekennzeichnet werden müssen und wie lange diese Kennzeichnung beibehalten werden sollte. |
| 411 | Der Server weigert sich, Anfragen anzunehmen, ohne den Content-Length-Kopf zu definieren. Nachdem ein gültiger Content-Length-Header hinzugefügt wurde, der die Länge des Anforderung nachrichten körpers anzeigt, kann der Client die Anforderung erneut einreichen. |
| 412 | Der Server konnte eine oder mehrere von ihnen nicht erfüllen, als die Überprüfung im Header feld der Anforderung angegeben wurde. Mit diesem Status code kann der Client beim Abrufen der Ressource die Voraussetzungen in den angeforderten Meta informationen (Anforderung header feld daten) festlegen, um zu verhindern, dass die Anforderung methode auf andere Ressourcen als den gewünschten Inhalt angewendet wird. |
| 413 | Der Server weigert sich, die aktuelle Anforderung zu verarbeiten, da die Größe der von der Anforderung übermittelten Entität daten den Bereich übers ch reitet, den der Server bereit oder in der Lage ist, damit umzugehen. In diesem Fall kann der Server die Verbindung schließen, damit der Client diese Anforderung nicht weiter sendet. Wenn diese Situation vorübergehend ist, sollte der Server einen Retry-After-Antwort header zurückgeben, um dem Client mitzuteilen, wie lange er es später erneut versuchen kann. |
| 414 | Die Länge des angefragten URIs übersteigt die Länge, die der Server verarbeiten kann; daher weigert sich der Server, die Anfrage zu bearbeiten. Dies ist relativ selten; typische Fälle sind etwa, dass eine Formularübermittlung, die eigentlich mit der POST-Methode erfolgen sollte, stattdessen als GET-Anfrage durchgeführt wird, was zu einem überlängen Query String führt. „Schwarzes Loch“ beim Redirect-URI: Beispielsweise wird bei jedem Redirect der alte URI als Teil des neuen URIs übernommen, was nach mehreren Umleitungen zu einem überlängen URI führt. Der Client versucht, mithilfe einer Sicherheitslücke, die auf bestimmten Servern vorhanden ist, den Server anzugreifen. Solche Server verwenden Puffer mit festem Länge, um die URI einer Anfrage zu lesen oder zu verarbeiten. Wenn die Parameter nach dem GET-Schlüssel eine bestimmte Länge überschreiten, kann es zu einem Pufferüberlauf kommen, der die Ausführung von beliebigem Code ermöglicht [1]. Server, die keine derartigen Schwachstellen aufweisen, sollten den Statuscode 414 zurückgeben. |
| 415 | Für die aktuell angeforderte Methode und die angeforderte Ressource ist die in der Anforderung übermittelte Entität nicht das vom Server unterstützte Format, sodass die Anforderung abgelehnt wird. |
| 416 | Wenn der Range-Anforderung header in der Anforderung enthalten ist und der in Range angegebene Daten bereich nicht mit dem verfügbaren Bereich der aktuellen Ressource überein fällt und der If-Range-Anforderung header nicht in der Anforderung definiert ist, sollte der Server den Status code 416 zurückgeben. Wenn Range einen Byte bereich verwendet, bedeutet dies, dass die erste Byte position aller von der Anforderung angegebenen Daten bereiche die Länge der aktuellen Ressource übers ch reitet. Der Server sollte auch einen Content-Range-Entität header enthalten, während der Status code 416 zurück gegeben wird, um die Länge der aktuellen Ressource anzugeben. Diese Antwort wurde auch verboten, multi part/byter anges als Content-Type zu verwenden. |
| 417 | Der im Anforderung header Expect angegebene erwartete Inhalt kann vom Server nicht erfüllt werden, oder der Server ist ein Proxy server, der offen sichtliche Beweise dafür hat, dass der Inhalt von Expect auf dem nächsten Knoten der aktuellen Route nicht erfüllt werden kann. |
| 421 | Die Anzahl der Verbindungen von der IP-Adresse, in der sich der aktuelle Client befindet, zum Server übers ch reitet den maximalen Bereich der Server lizenz. In der Regel bezieht sich die IP-Adresse hier auf die Client-Adresse (z. B. die Gateway-oder Proxy-Server-Adresse des Benutzers), die vom Server angezeigt wird. In diesem Fall kann die Berechnung der Anzahl der Verbindungen mehr als einen Endnutzer betreffen. |
| 422 | Die Anzahl der Verbindungen von der IP-Adresse, in der sich der aktuelle Client befindet, zum Server übers ch reitet den maximalen Bereich der Server lizenz. In der Regel bezieht sich die IP-Adresse hier auf die Client-Adresse (z. B. die Gateway-oder Proxy-Server-Adresse des Benutzers), die vom Server angezeigt wird. In diesem Fall kann die Berechnung der Anzahl der Verbindungen mehr als einen Endnutzer betreffen. |
| 422 | Die Anforderung ist korrekt formatiert, kann jedoch aufgrund eines semantischen Fehlers nicht antworten. (RFC 4918 WebDAV) Die aktuelle Ressource von 423 Locked ist gesperrt. (RFC 4918 WebDAV) |
| 424 | Die aktuelle Anforderung schlägt aufgrund eines Fehlers fehl, der bei einer früheren Anforderung aufgetreten ist, z. B. PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Es ist im WebDav Advanced Collections-Entwurf definiert, wird jedoch nicht im WebDAV Sequented Set-Protokoll (RFC 3658) angezeigt. |
| 426 | Der Client sollte zu TLS/1.0 wechseln. (RFC 2817) |
| 449 | Von Microsoft erweitert, sollte die repräsent ative Anfrage nach Durchführung geeigneter Vorgänge erneut versucht werden. |
| 500 | Der Server stieß auf eine unerwartete Situation, die dazu führte, dass er die Verarbeitung der Anforderung nicht abschließen konnte. Im Allgemeinen tritt dieses Problem auf, wenn der Programmcode des Servers falsch ist. |
| 501 | Der Server unterstützt keine Funktion, die für die aktuelle Anforderung erforderlich ist. Wenn der Server die angeforderte Methode nicht erkennt und seine Anforderung an eine Ressource nicht unterstützt. |
| 502 | Wenn ein Server, der als Gateway oder Proxy arbeitet, versucht, eine Anforderung auszuführen, erhält er eine ungültige Antwort vom Upstream-Server. |
| 503 | Aufgrund einer temporären Server wartung oder Überlastung kann der Server die Anforderung derzeit nicht verarbeiten. Diese Situation ist vorübergehend und wird nach einiger Zeit wieder hergestellt. Wenn die Verzögerung szeit vorhergesagt werden kann, kann die Antwort einen Retry-After-Header enthalten, um die Verzögerung szeit anzuzeigen. Wenn diese Retry-After-Information nicht gegeben wird, sollte der Client sie so verarbeiten, dass er die 500-Antwort verarbeitet. Hinweis: Das Vorhanden sein des Status codes 503 bedeutet nicht, dass der Server ihn verwenden muss, wenn er überlastet ist. Einige Server möchten lediglich die Verbindung des Clients ablehnen. |
| 504 | Wenn ein Server, der als Gateway oder Proxy arbeitet, versucht, eine Anforderung auszuführen, empfängt er nicht rechtzeitig eine Antwort von einem Upstream-Server (einem vom URI ident ifi zierten Server wie HTTP, FTP, LDAP) oder einem sekundären Server (z. B. DNS). Hinweis: Einige Proxy server geben 400 oder 500 Fehler zurück, wenn die DNS-Abfrage Zeit überschreitung |
| 505 | Der Server unterstützt die in der Anforderung verwendete HTTP-Version nicht oder lehnt sie ab. Dies impliziert, dass der Server nicht dieselbe Version wie der Client verwenden kann oder will. 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 die "Transparent Content Consultation Agreement" (RFC 2295), was bedeutet, dass der Server einen internen Konfiguration fehler aufweist: Die angeforderten Transformation ressourcen für Verhandlungen sind so konfiguriert, dass sie sich selbst bei der Aushandlung von transparenten Inhalten verwenden, sodass dies kein geeigneter Schwerpunkt bei einer Verhandlungs verarbeitung ist. |
| 507 | Der Server kann nicht speichern, was zum Abschließen der Anforderung erforderlich ist. Diese Situation gilt als vorübergehend. WebDAV(RFC 4918) |
| 509 | Der Server erreicht das Bandbreiten limit. Dies ist kein offizieller Status code, aber immer noch weit verbreitet. |
| 510 | Die Strategie, die erforderlich ist, um Ressourcen zu erhalten, ist nicht unerfüllt. (RFC 2774) |
Freundlicher Link:iCMS