| HTTP-Statuscode | Die Bedeutung des Statuscodes |
|---|---|
| 100 | 客户端仍应发送请bitten. Diese vorläufige Antwort wird verwendet, um den Client darüber zu informieren, dass ein Teil der Anfrage vom Server empfangen und noch nicht abgelehnt wurde. Der Client sollte den Rest der Anfrage weiter senden oder die Antwort ignorieren, wenn die Anfrage abgeschlossen ist. Nach Abschluss der Anfrage sollte der Server eine endgültige Antwort an den Client senden. |
| 101 | Der Server versteht die Anfrage des Clients und benachrichtigt den Client über den Upgrade-Nachrichtenheader, ein anderes Protokoll zu verwenden, um die Anfrage abzuschließen. Nach dem Senden der letzten leeren Zeile dieser Antwort wechselt der Server zu dem im Upgrade-Nachrichtenheader definierten Protokoll. Ein ähnliches Vorgehen sollte nur dann durchgeführt werden, wenn die Umstellung auf ein neues Protokoll vorteilhafter wäre. Beispielsweise hat der Wechsel auf eine neuere HTTP-Version Vorteile gegenüber älteren Versionen. Alternativ können Sie auf Echtzeit- und isochrone Protokolle umsteigen, um Ressourcen mithilfe solcher Funktionen zu übertragen. |
| 102 | Ein durch WebDAV (RFC 2518) erweiterter Statuscode, der angibt, dass die Verarbeitung fortgesetzt werden soll. |
| 200 | Die Anfrage war erfolgreich. Mit dieser Antwort werden die angeforderten Antwortheader oder Datenkörper zurückgegeben. |
| 201 | Die Anfrage ist abgeschlossen, eine neue Ressource wurde basierend auf der Anfrage erstellt und ihr URI wurde mit dem Location-Header zurückgegeben. Wenn die erforderliche Ressource nicht rechtzeitig erstellt werden kann, muss ein "202 Accepted" zurückgegeben werden. |
| 202 | Der Server hat die Anfrage angenommen, aber noch nicht verarbeitet. Einem Antrag kann am Ende entsprochen werden oder auch nicht, genauso wie er abgelehnt werden kann. Für asynchrone Vorgänge gibt es keine andere praktische Methode als das Senden dieses Statuscodes. Der Zweck der Rückgabe einer Antwort mit dem Statuscode 202 besteht darin, dem Server die Annahme von Anforderungen von anderen Prozessen zu ermöglichen (z. B. stapelbasierte Vorgänge, die nur einmal am Tag ausgeführt werden). Der Batch-Vorgang ist abgeschlossen. Eine Antwort, die eine Verarbeitungsanforderung akzeptiert und einen 202-Statuscode zurückgibt, MUSS in der zurückgegebenen Entität Informationen enthalten, die den aktuellen Status der Verarbeitung angeben, sowie einen Zeiger auf einen Verarbeitungsstatusmonitor oder eine Statusprognose. Der Vorgang ist abgeschlossen. |
| 203 | Der Server hat die Anforderung erfolgreich verarbeitet, aber die Entitätsheaderinformationen von einer lokalen Kopie oder einer Kopie eines Drittanbieters zurückgegeben, und nicht von einem deterministischen Satz, der auf dem Originalserver gültig war. Aktuelle Informationen können eine Teilmenge oder eine Obermenge der Originalversion sein. Wenn Sie beispielsweise Metadaten für eine Ressource einschließen, könnte der Ursprungsserver die Metadaten erkennen. Es ist nicht erforderlich, diesen Statuscode zu verwenden. Geben Sie 200 nur zurück, wenn dieser Statuscode nicht in der Antwort verwendet wurde. Die Situation ist in Ordnung. |
| 204 | Der Server hat die Anfrage erfolgreich verarbeitet, muss jedoch keinen Entitätsinhalt zurückgeben, sondern möchte aktualisierte Metainformationen zurückgeben. Antworten können neue oder aktualisierte Metainformationen in Form von Entitätsheadern zurückgeben. Wenn diese Header vorhanden sind, müssen sie den angeforderten Variablen entsprechen. Wenn der Client ein Browser ist, rendert der Browser des Benutzers die angeforderte Seite, ohne die Dokumentansicht zu ändern, selbst wenn neue oder aktualisierte Metainformationen auf die aktive Dokumentansicht des Browsers des Benutzers angewendet werden müssen. Eine 204 Forbidden-Antwort enthält einen Nachrichtentext und endet daher immer mit der ersten Leerzeile nach den Nachrichtenkopfzeilen. |
| 205 | Der Server hat die Anfrage erfolgreich verarbeitet und nichts zurückgegeben. Im Gegensatz zu einer 204-Antwort erfordert eine Antwort, die diesen Statuscode zurückgibt, jedoch, dass der Anforderer die Dokumentansicht zurücksetzt. Diese Antwort dient in erster Linie dazu, das Formular unmittelbar nach der Annahme einer Benutzereingabe zurückzusetzen, damit der Benutzer problemlos eine weitere Eingabe starten kann. Wie die 204-Antwort darf auch die Antwort keinen Nachrichtentext enthalten, der mit der ersten Leerzeile nach den Nachrichtenkopfzeilen endet. |
| 206 | Der Server hat einige GET-Anfragen erfolgreich verarbeitet. FlashGet, Thunder und andere HTTP-Download-Tools verwenden diese Antwort, um einen Neustart am Haltepunkt zu implementieren oder große Dateien für den gleichzeitigen Download in mehrere Download-Segmente aufzuteilen. Die Anfrage muss einen Range-Header enthalten, der den vom Client gewünschten Inhaltsbereich angibt, und kann If-Range als Anfragebedingung enthalten. Die Antwort muss die folgenden Header-Felder enthalten: Content-Range wird verwendet, um den von dieser Antwort zurückgegebenen Inhaltsbereich anzugeben. Bei Multipart-Downloads mit einem Multipart/Byte-Range-Inhaltstyp MUSS jeder Multipart-Teil ein Content-Range-Feld enthalten, das den Bereich des Teils angibt. Wenn eine Content-Length in der Antwort enthalten ist, sollte ihr Wert mit der tatsächlichen Anzahl von Bytes im zurückgegebenen Inhaltsbereich übereinstimmen. Datums-ETag und/oder Inhaltsort (wenn dieselbe Anfrage 200 Antworten zurückgeben sollte). Die Werte "Ablauf", "Cache-Kontrolle" und/oder "Vary" können von entsprechenden Werten in anderen vorherigen Antworten für dieselbe Variable abweichen. Wenn diese Antwort die Verwendung der starken If-Range-Cache-Validierung anfordert, fügen Sie bitte keine anderen Entitätsheader in diese Antwort ein. Wenn diese Antwort die Verwendung einer schwachen Cache-Validierung im If-Range-Bereich anfordert, darf diese Antwort KEINE anderen Entitätsheader enthalten. Dadurch werden Inkonsistenzen zwischen zwischengespeicherten Entitätsinhalten und aktualisierten Entitätsheadern vermieden. Andernfalls MUSS diese Antwort alle Entitätsheaderfelder enthalten, die in einer 200-Antwort zurückgegeben werden sollen. Client-Caches sollten vermeiden, in einer 206-Antwort zurückgegebene Inhalte mit zuvor zwischengespeicherten Inhalten zu kombinieren, wenn die ETag- oder Last-Modified-Header nicht genau übereinstimmen. Verhindert, dass Caches, die die Header "Range" und "Content-Range" nicht unterstützen, Inhalte zwischenspeichern, die von 206-Antworten zurückgegeben werden. |
| 207 | Die von WebDAV (RFC 2518) erweiterten Statuscodes geben an, dass der nachfolgende Nachrichtentext eine XML-Nachricht ist und je nach Anzahl der vorherigen Unteranforderungen eine Reihe unabhängiger Antwortcodes enthalten kann. |
| 300 | Die angeforderte Ressource verfügt über einen optionalen Satz von Feedback-Informationen, jeweils mit einer eindeutigen Adresse und browsergesteuerten Verhandlungsinformationen. Der Benutzer oder Browser kann 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, die Ressourcenmerkmale und eine Liste von Adressen enthält, aus denen der Benutzer oder Browser die am besten geeignete Umleitungsadresse auswählen kann. Das Format dieser Entität wird durch das im Content-Type definierte Format bestimmt. Der Browser trifft möglicherweise automatisch die am besten geeignete Wahl, basierend auf dem Format der Antwort und den Fähigkeiten des Browsers selbst. Natürlich der RFC Die 2616-Spezifikation legt nicht fest, wie diese automatische Auswahl erfolgen soll. Wenn der Server selbst bereits über eine bevorzugte Feedback-Option verfügt, sollte der Standort-URI unter Standort angegeben werden. Browser können diesen Standortwert als Adresse für die automatische Umleitung verwenden. Diese Antwort ist auch zwischenspeicherbar, sofern nicht anders angegeben. |
| 301 | Die angeforderte Ressource wurde an einen völlig neuen Standort verschoben. Zukünftige Verweise auf diese Ressource sollten einen der in dieser Antwort zurückgegebenen URIs verwenden. Clients mit Linkbearbeitungsfunktionen sollten die angeforderte Adresse nach Möglichkeit automatisch in die vom Server zurückgegebene Adresse ändern. Diese Antwort ist auch zwischenspeicherbar, sofern nicht anders angegeben. Der 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. Wenn es sich nicht um eine GET- oder HEAD-Anfrage handelt, können sich die Bedingungen der Anfrage entsprechend ändern, sodass der Browser nicht automatisch umleitet, es sei denn, der Benutzer bestätigt dies. Hinweis: In einigen Browsern, die das HTTP/1.0-Protokoll verwenden, führt das Senden einer 301-Antwort auf eine POST-Anfrage zu einem GET für die nächste umgeleitete Anfrage. |
| 302 | Die angeforderte Ressource antwortet nun vorübergehend auf eine Anfrage von einem anderen URI. Diese Umleitung ist vorübergehend und der Client sollte weiterhin Anfragen an die ursprüngliche Adresse senden. Diese Antwort kann nur zwischengespeichert werden, wenn sie durch Cache-Control oder Expires angegeben wird. Der neue temporäre URI sollte im Feld "Standort" 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. Wenn es sich nicht um eine GET- oder HEAD-Anfrage handelt, können sich die Bedingungen der Anfrage entsprechend ändern, sodass Browser keine automatischen Weiterleitungen zulassen, es sei denn, der Benutzer bestätigt dies. Hinweis: Obwohl die Spezifikationen RFC 1945 und RFC 2068 es dem Client nicht erlauben, die Methode der Anfrage während der Umleitung zu ändern, behandeln viele bestehende Browser eine 302-Antwort als 303-Antwort und verwenden GET, um unabhängig vom Standort auf den durch "Location" angegebenen URI zuzugreifen. URIs. Die Methode der ursprünglichen Anfrage. Statuscodes 303 und 307 hinzugefügt, um zu verdeutlichen, was der Server vom Client erwartet. |
| 303 | Die der aktuellen Anfrage entsprechende Antwort kann unter einem anderen URI gefunden werden, und der Client sollte GET verwenden, um auf diese Ressource zuzugreifen. Diese Methode dient in erster Linie dazu, die Ausgabe einer durch ein Skript aktivierten POST-Anfrage an eine neue Ressource umzuleiten. Dieser neue URI ist kein Ersatzverweis auf die ursprüngliche Ressource. Deaktivieren Sie außerdem das Caching von 303-Antworten. Natürlich können Sie auch die zweite Anfrage zwischenspeichern (Redirect). Der neue 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. Hinweis: Viele Browser vor HTTP/1.1 erkennen den Status 303 nicht richtig. Wenn Ihnen die Interaktion mit diesen Browsern wichtig ist, reicht der Statuscode 302 aus. Dies liegt daran, dass die meisten Browser 302-Antworten genau so verarbeiten, wie Clients es tun sollten, wenn sie 303-Antworten gemäß der obigen Spezifikation verarbeiten. |
| 304 | Der Server SOLLTE diesen Statuscode zurückgeben, wenn der Client eine bedingte GET-Anfrage gesendet hat, die Anfrage gewährt wurde und sich der Inhalt des Dokuments nicht geändert hat (seit dem letzten Zugriff oder basierend auf den angeforderten Bedingungen). Eine 304 Forbidden-Antwort enthält einen Nachrichtentext und endet daher immer mit der ersten Leerzeile nach den Nachrichtenkopfzeilen. Antworten sollten die folgenden Header enthalten: Datum, es sei denn, dieser Server verfügt über keine Uhr. Proxyserver und Clients KÖNNEN den empfangenen Antwortheadern ein Datumsfeld (gemäß RFC) hinzufügen, wenn der uhrlose Server diese Regeln ebenfalls befolgt. 2068) funktioniert der Caching-Mechanismus einwandfrei. ETag und/oder Content-Location (wenn dieselbe Anfrage eine 200-Antwort zurückgeben soll). Die Werte "Ablauf", "Cache-Kontrolle" und/oder "Vary" können von entsprechenden Werten in anderen vorherigen Antworten für dieselbe Variable abweichen. Wenn diese Antwort die Verwendung einer starken Cache-Authentifizierung anfordert, fügen Sie bitte keine anderen Entitätsheader in diese Antwort ein. Andernfalls (z. B. wenn die bedingte GET-Anfrage eine schwache Cache-Authentifizierung verwendet) dürfen andere Entitätsheader nicht in diese Antwort einbezogen werden. Dadurch werden Inkonsistenzen zwischen zwischengespeicherten Entitätsinhalten und aktualisierten Entitätsheadern vermieden. Wenn eine 304-Antwort darauf hinweist, dass die Entität derzeit nicht zwischengespeichert ist, sollte das Caching-System die Antwort ignorieren und die Anfrage ohne Begrenzung wiederholen. Wenn eine 304-Antwort mit der Bitte um einen aktualisierten Cache-Eintrag empfangen wird, muss das Caching-System den gesamten Eintrag aktualisieren, um die aktualisierten Werte aller Felder in der Antwort widerzuspiegeln. |
| 305 | Auf die angeforderte Ressource muss über den angegebenen Proxy zugegriffen werden können. Das Feld "Standort" stellt die URI-Informationen für den angegebenen Proxy bereit. Der Empfänger muss wiederholt eine weitere Anfrage senden, um über diesen Proxy auf die entsprechende Ressource zuzugreifen. Nur der Ursprungsserver kann eine 305-Antwort erstellen. Hinweis: RFC 2068 verfügt nicht über eine explizite 305-Antwort zur Umleitung einzelner Anfragen, sie kann nur vom Ursprungsserver eingerichtet werden. Das Ignorieren dieser Einschränkungen kann schwerwiegende Folgen für die Sicherheit haben. |
| 306 | Die neueste Version der Spezifikation verwendet den Statuscode 306 nicht mehr. |
| 307 | Die angeforderte Ressource antwortet nun vorübergehend auf eine Anfrage von einem anderen URI. Diese Umleitung ist vorübergehend und der Client sollte weiterhin Anfragen an die ursprüngliche Adresse senden. Diese Antwort kann nur zwischengespeichert werden, wenn sie durch Cache-Control oder Expires angegeben wird. Der neue temporäre URI sollte im Feld "Standort" 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. Einige Browser verstehen eine 307-Antwort nicht, daher müssen Sie oben die erforderlichen Informationen hinzufügen, damit der Benutzer den neuen URI verstehen und eine Anfrage zum Besuch stellen kann. Wenn es sich nicht um eine GET- oder HEAD-Anfrage handelt, können sich die Bedingungen der Anfrage entsprechend ändern, sodass Browser keine automatischen Weiterleitungen zulassen, es sei denn, der Benutzer bestätigt dies. |
| 400 | 1. Die Semantik ist falsch und der Server kann die aktuelle Anfrage nicht verstehen. Kunden DÜRFEN diese Anfrage NICHT wiederholt senden, sofern sie nicht geändert wird. 2. Der Anforderungsparameter ist falsch. |
| 401 | Die aktuelle Anfrage erfordert eine Benutzerauthentifizierung. Die Antwort muss einen WWW-Authenticate-Header enthalten, der für die angeforderte Ressource geeignet ist und den Benutzer zur Eingabe von Informationen auffordert. Clients können wiederholt Anfragen mit entsprechenden Autorisierungsheadern senden. Wenn die aktuelle Anfrage bereits Authentifizierungszertifikate enthielt, bedeutet eine 401-Antwort, dass der Server bestätigt hat, dass diese Zertifikate abgelehnt wurden. Wenn die 401-Antwort die gleiche Authentifizierungsaufforderung wie die vorherige Antwort enthält und der Browser mindestens einmal einen Authentifizierungsversuch unternommen hat, sollte der Browser dem Benutzer die in der Antwort enthaltenen Entitätsinformationen anzeigen. Dies liegt daran, dass diese Entitätsinformationen möglicherweise relevante Diagnoseinformationen enthalten. Siehe RFCs 2617. |
| 402 | Dieser Statuscode ist für zukünftige Anforderungen reserviert. |
| 403 | Der Server hat die Anfrage verstanden, weigerte sich jedoch, sie zu erfüllen. Im Gegensatz zu einer 401-Antwort hilft Ihnen die Authentifizierung in keiner Weise weiter. Senden Sie diese Anfrage daher nicht erneut. Wenn es sich nicht um eine HEAD-Anfrage handelt und Sie möchten, dass der Server erklärt, warum die Anfrage nicht erfüllt werden konnte, SOLLTE die Entität den Grund für die Ablehnung erläutern. Wenn der Server nicht möchte, dass der Client Informationen erhält, kann er natürlich auch eine 404-Antwort zurückgeben. |
| 404 | Die Anfrage ist fehlgeschlagen, die angeforderte Ressource konnte nicht auf dem Server gefunden werden. Es gibt keine Informationen darüber, ob dieser Zustand vorübergehend oder dauerhaft ist. Wenn dem Server diese Situation bekannt ist, sollte er den Statuscode 410 verwenden, um mitzuteilen, dass die alte Ressource aufgrund eines Problems mit ihrem internen Konfigurationsmechanismus dauerhaft nicht verfügbar ist und keine Adresse hat, zu der sie springen kann. Der Statuscode 404 wird häufig verwendet, wenn der Server nicht offenlegen möchte, warum die Anfrage abgelehnt wurde oder keine andere angemessene Antwort erfolgt. |
| 405 | Die entsprechende Ressource konnte nicht mit der in der Anforderungszeile angegebenen Anforderungsmethode angefordert werden. Die Antwort sollte einen Allow-Header zurückgeben, um die Liste der für die aktuelle Ressource akzeptablen Anforderungsmethoden anzugeben. Wenn man PUT- und DELETE-Methoden berücksichtigt, schreiben sie Ressourcen auf den Server, sodass die meisten Webserver die obige Anforderungsmethode in ihrer Standardkonfiguration nicht unterstützen oder zulassen und für eine solche Anforderung den Fehler 405 zurückgeben. |
| 406 | Die Inhaltsmerkmale der angeforderten Ressource erfüllen nicht die Bedingungen im Anforderungsheader und die Antwortentität kann nicht generiert werden. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte die Antwort eine Entität zurückgeben, die eine Liste von Entitätsattributen und -adressen enthält, aus der der Benutzer oder Browser das am besten geeignete auswählen kann. Das Format der Entität wird durch den im Content-Type-Header definierten Medientyp bestimmt. Der Browser kann basierend auf dem Format und den einzigartigen Funktionen die beste Wahl treffen. Diese Spezifikation definiert jedoch keine Kriterien für diese automatische Auswahl. |
| 407 | Ähnlich einer 401-Antwort, aber der Client muss sich über den Proxyserver authentifizieren. Proxyserver MÜSSEN für Identitätsabfragen ein Proxy-Authenticate zurückgeben. Clients können zur Authentifizierung einen Proxy-Authorization-Header zurückgeben. Siehe RFCs 2617. |
| 408 | Zeitüberschreitung der Anforderung. Der Client hat das Senden der Anfrage nicht innerhalb der Zeit abgeschlossen, die der Server warten wollte. Der Client kann diese Anfrage jederzeit ohne Änderung erneut senden. |
| 409 | Die Anforderung kann nicht abgeschlossen werden, da sie mit dem aktuellen Status der angeforderten Ressource in Konflikt steht. Dieser Code ist nur zulässig, wenn der Benutzer den Konflikt lösen und eine neue Anfrage erneut stellen kann. Die Antwort sollte genügend Informationen enthalten, damit der Benutzer die Ursache des Konflikts ermitteln kann. Konflikte treten in der Regel bei der Verarbeitung von PUT-Anfragen auf. Wenn beispielsweise in einer Versionsprüfungsumgebung die Versionsinformationen, die an eine bestimmte, von PUT gesendete Ressourcenänderungsanforderung angehängt sind, mit der vorherigen (Drittanbieter-)Anfrage in Konflikt stehen, sollte der Server zu diesem Zeitpunkt einen 409-Fehler zurückgeben. Benachrichtigen Sie den Benutzer, dass die Anfrage nicht abgeschlossen werden konnte. Zu diesem Zeitpunkt kann die Antwortentität einen Vergleich der Unterschiede zwischen den beiden widersprüchlichen Versionen enthalten, sodass 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. Dieser Zustand sollte als dauerhaft angesehen werden. Kunden mit Linkbearbeitungsfunktionen sollten nach Möglichkeit alle Verweise auf die Adresse entfernen, nachdem sie die Erlaubnis des Benutzers eingeholt haben. Wenn der Server nicht weiß oder nicht sicher ist, ob der Zustand dauerhaft ist, sollte er den Statuscode 404 verwenden. Diese Antwort kann zwischengespeichert werden, sofern nicht anders angegeben. Der Hauptzweck der 410-Antwort besteht darin, dass Webmaster die Website warten, Benutzer darüber informieren, dass die Ressource nicht mehr verfügbar ist, und dass der Serverbesitzer alle Remoteverbindungen zur Ressource entfernt. Das ist alles. Solche Ereignisse sind in Unternehmen mit zeitlich begrenzter Wertschöpfung keine Seltenheit. In ähnlicher Weise wird die 410-Antwort auch verwendet, um den Client des aktuellen Serverstandorts darüber zu informieren, dass Ressourcen, die Einzelpersonen gehörten, nicht mehr verfügbar sind. Sollten doch nicht alle dauerhaft nicht verfügbaren Ressourcen mit "410" gekennzeichnet sein? Wie lange dieses Tag bestehen bleiben soll, liegt ganz im Ermessen des Serverbesitzers. |
| 411 | Der Server weigert sich, Anfragen anzunehmen, ohne dass ein Content-Length-Header definiert ist. Nachdem ein gültiger Content-Length-Header hinzugefügt wurde, der die Länge des Anforderungsnachrichtentexts angibt, kann der Client die Anforderung erneut senden. |
| 412 | Der Server konnte eine oder mehrere der in den Anforderungsheaderfeldern angegebenen Voraussetzungen bei der Überprüfung nicht erfüllen. Dieser Statuscode ermöglicht es dem Client, beim Abrufen von Ressourcen Vorbedingungen für die Metainformationen der Anfrage (Anfrage-Header-Felddaten) festzulegen, um zu verhindern, dass die Anfragemethode auf andere als die erforderlichen Ressourcen angewendet wird. . |
| 413 | Der Server weigert sich, die aktuelle Anfrage zu verarbeiten, da die Anfrage größere Entitätsdaten sendet, als der Server zu verarbeiten versucht oder verarbeiten kann. In diesem Fall kann der Server die Verbindung schließen, um zu verhindern, dass der Client diese Anfrage weiterhin sendet. Wenn die Bedingung vorübergehend ist, sollte der Server einen Retry-After-Antwortheader zurückgeben, um dem Client mitzuteilen, wie oft er es später erneut versuchen soll. |
| 414 | Der Server weigert sich, die Anfrage zu verarbeiten, da der Anfrage-URI länger ist, als der Server interpretieren kann. Dies ist seltener, aber üblich: Eine Formularübermittlung, die die POST-Methode hätte verwenden sollen, ist jetzt eine GET-Methode und die Abfragezeichenfolge (Query Zeichenfolge) ist zu lang. "Schwarze Löcher" in Weiterleitungs-URIs. Beispielsweise verwendet jede Umleitung den alten URI als Teil des neuen URI, was nach mehreren Umleitungen zu längeren URIs führt. Ein Client versucht, einen Server anzugreifen, bei dem einige Server eine Sicherheitslücke aufweisen. Dieser Servertyp verwendet einen Puffer fester Länge zum Lesen und Bearbeiten von Anforderungs-URIs. Wenn der Post-GET-Parameter einen bestimmten Wert überschreitet, kann es zu einem Pufferüberlauf kommen und beliebiger Code ausgeführt werden [1]. Server ohne solche Schwachstellen sollten den Statuscode 414 zurückgeben. |
| 415 | Die Anfrage wurde für die aktuell angeforderte Methode und angeforderte Ressource abgelehnt, da die in der Anfrage gesendete Entität nicht in einem vom Server unterstützten Format vorliegt. |
| 416 | Wenn die Anfrage einen Range-Anfrageheader enthält, der in Range angegebene Datenbereich nicht mit dem verfügbaren Bereich der aktuellen Ressource übereinstimmt und der If-Range-Anfrageheader in der Anfrage nicht definiert ist, sollte der Server einen 416-Statuscode zurückgeben. Wenn Range Bytebereiche verwendet, bedeutet diese Situation, dass die erste Byteposition aller von der Anforderung angegebenen Datenbereiche die Länge der aktuellen Ressource überschreitet. Der Server sollte außerdem einen 416-Statuscode zurückgeben und einen Content-Range-Entitätsheader enthalten, der die Länge der aktuellen Ressource angibt. Diese Antwort lässt auch keine Multipart-/Bytebereiche als Inhaltstyp zu. |
| 417 | Entweder wird die im Expect des Request-Headers angegebene Erwartung vom Server nicht erfüllt, oder es gibt eindeutige Hinweise darauf, dass der Server ein Proxyserver ist und der nächste Knoten in der aktuellen Route den Inhalt des Expect nicht erfüllt. Ich habe. |
| 421 | Die Anzahl der Verbindungen zum Server von der IP-Adresse des aktuellen Clients hat den vom Server maximal zulässigen Bereich überschritten. Die IP-Adresse bezieht sich hier normalerweise auf die vom Server gesehene Client-Adresse (z. B. die Adresse des Benutzer-Gateways oder Proxy-Servers). In diesem Fall können mehrere Endbenutzer an der Berechnung der Anzahl der Verbindungen beteiligt sein. |
| 422 | Die Anzahl der Verbindungen zum Server von der IP-Adresse des aktuellen Clients hat den vom Server maximal zulässigen Bereich überschritten. Die IP-Adresse bezieht sich hier normalerweise auf die vom Server gesehene Client-Adresse (z. B. die Adresse des Benutzer-Gateways oder Proxy-Servers). In diesem Fall können mehrere Endbenutzer an der Berechnung der Anzahl der Verbindungen beteiligt sein. |
| 422 | Die Anfrage ist korrekt formuliert, enthält jedoch semantische Fehler und kann nicht beantwortet werden. (RFC 4918 WebDAV) 423 Gesperrt Die aktuelle Ressource ist gesperrt. (RFC 4918 WebDAV) |
| 424 | Die aktuelle Anfrage ist aufgrund eines Fehlers in einer vorherigen Anfrage (z. B. PROPPATCH) fehlgeschlagen. (RFC 4918 WebDAV) |
| 425 | Definiert im WebDav Advanced Collections-Entwurf, aber nicht im WebDAV Serial Collections Protocol (RFC 3658) enthalten. |
| 426 | Kunden sollten auf TLS/1.0 umsteigen. (RFC2817) |
| 449 | Von Microsoft verbessert, um Stellvertretungsanfragen erneut zu versuchen, nachdem entsprechende Maßnahmen ergriffen wurden. |
| 500 | Der Server ist auf einen unerwarteten Zustand gestoßen und konnte Ihre Anfrage nicht abschließen. Dieses Problem tritt im Allgemeinen auf, wenn der Serverprogrammcode falsch ist. |
| 501 | Der Server unterstützt nicht die für die aktuelle Anforderung erforderliche Funktionalität. Wenn der Server die angeforderte Methode nicht erkennt und die Ressourcenanforderung nicht unterstützen kann. |
| 502 | Ein Server, der als Gateway oder Proxy fungiert, hat beim Versuch, eine Anfrage zu erfüllen, eine ungültige Antwort von einem Upstream-Server erhalten. |
| 503 | Der Server kann die Anfrage derzeit aufgrund vorübergehender Serverwartung oder Überlastung nicht verarbeiten. Dieser Zustand ist vorübergehend und normalisiert sich nach einiger Zeit wieder. Wenn die Verzögerung geschätzt werden kann, kann die Antwort einen Retry-After-Header enthalten, der die Verzögerung angibt. Wenn diese Retry-After-Informationen nicht bereitgestellt werden, sollten Clients sie als 500-Antwort behandeln. Hinweis: Das Vorhandensein des Statuscodes 503 bedeutet nicht, dass dieser verwendet werden sollte, wenn der Server überlastet ist. Einige Server möchten lediglich Clientverbindungen ablehnen. |
| 504 | Wenn ein Server, der als Gateway oder Proxy fungiert, versucht, eine Anfrage zu erfüllen, kann er keine Antwort von einem Upstream-Server (einem durch einen URI identifizierten Server wie HTTP, FTP, LDAP usw.) oder einem sekundären Server (DNS, usw.). ). schnell. Hinweis: Einige Proxyserver geben 400 oder 500 Fehler zurück, wenn bei DNS-Anfragen eine Zeitüberschreitung auftritt. |
| 505 | Der Server unterstützt die in der Anfrage verwendete HTTP-Version nicht oder verweigert die Unterstützung. Das bedeutet, dass der Server nicht die gleiche Version wie der Client verwenden kann oder will. Die Antwort MUSS eine Entität enthalten, die erklärt, warum die Version nicht unterstützt wird und welche Protokolle der Server unterstützt. |
| 506 | Erweitert durch das Transparent Content Negotiation-Protokoll (RFC 2295), um interne Serverfehlkonfigurationen anzuzeigen. |
| 507 | Der Server kann nicht speichern, was er zur Erfüllung der Anfrage benötigt. Dieser Zustand gilt als vorübergehend. WebDAV (RFC 4918) |
| 509 | Der Server hat sein Bandbreitenlimit erreicht. Dies ist kein offizieller Statuscode, wird aber dennoch häufig verwendet. |
| 510 | Die Strategien zur Ressourcenbeschaffung reichen nicht aus. (RFC2774) |
