| HTTP Statuscode | Bedeutung des Statuscodes |
|---|
| 100 | Die Client-Seite sollte weiterhin Anfragen senden. Diese vorläufige Antwort wird verwendet, um der Client-Seite zu informieren, dass einige seiner Anfragen vom Server empfangen wurden und nicht abgelehnt wurden. Die Client-Seite sollte die restlichen Anfragen weiterhin senden oder die Antwort ignorieren, wenn die Anfrage abgeschlossen wurde. Der Server muss nach Abschluss der Anfrage eine endgültige Antwort an die Client-Seite senden. |
| 101 | Der Server hat den Antrag des Clients verstanden und wird den Client-Ende durch den Upgrade-Header informieren, um ein anderes Protokoll zu verwenden, um den Antrag abzuschließen. Nachdem die letzte leere Zeile in der Antwort gesendet wurde, wechselt der Server zu den Protokollen, die im Upgrade-Header definiert sind. Solche Maßnahmen sollten nur ergriffen werden, wenn der Wechsel zu einem neuen Protokoll mehr Vorteile bringt. Zum Beispiel hat der Wechsel zu einer neuen HTTP-Version Vorteile gegenüber einer alten Version oder der Wechsel zu einem echten-Zeit- und Synchronisationsprotokoll, um Ressourcen zu liefern, die von solchen Funktionen profitieren. |
| 102 | Der durch WebDAV (RFC erweiterte Statuscode 2518) zeigt an, dass die Verarbeitung fortgesetzt wird. |
| 200. | Der Antrag war erfolgreich, und die gewünschten Antwort-Header oder Datenkörper werden zusammen mit der Antwort zurückgegeben. |
| 201 | Der Antrag wurde erfüllt, und ein neues Ressource basierend auf den Anforderungen des Antrags erstellt und seine URI zusammen mit dem Location-Header zurückgegeben. Wenn das erforderliche Ressource nicht rechtzeitig erstellt werden kann,'202 Akzeptiert' sollte zurückgegeben werden. |
| 202 | Der Server hat den Antrag angenommen, hat ihn aber noch nicht verarbeitet. Genau wie er abgelehnt werden könnte, könnte der Antrag letztendlich ausgeführt oder nicht ausgeführt werden. Bei asynchronen Operationen gibt es keine bequemere Möglichkeit, dies zu tun als die Übermittlung dieses Statuscodes. Der Zweck der Rückgabe eines 202 Statuscode-Antwort ist es, dem Server zu ermöglichen, Anfragen von anderen Prozessen (wie einem Stapel-eine einmal täglich durchgeführte Grundoperation, ohne dass der Client-Ende bis zum Abschluss der Stapeloperation mit dem Server verbunden bleiben muss. Als Reaktion auf die Annahme eines Antrags zur Verarbeitung und Rückgabe eines 202 Statuscode, sollte die zurückgegebene Entity einige Informationen enthalten, die den aktuellen Zustand des Prozesses angeben, sowie einen Verweis auf den Prozessstatusmonitor oder die Statusprognose, so dass der Benutzer abschätzen kann, ob die Operation abgeschlossen ist. |
| 203 | Der Server hat die Anfrage erfolgreich verarbeitet, aber die zurückgegebene Entity-Header-Metainformation ist auf dem Ursprungsserver nicht ein gültiges deterministisches Set, sondern ein lokales oder drittes-Partei Kopie. Die aktuelle Information kann ein Teilmenge oder eine Übermenge der ursprünglichen Version sein. Zum Beispiel können Metadaten, die Ressourcen enthalten, den Ursprungsserver dazu bringen, die Metasuper zu kennen. Der Einsatz dieses Statuscodes ist nicht erforderlich und ist nur angemessen, wenn die Antwort 200 OK ohne diesen Statuscode. |
| 204 | Der Server hat die Anfrage erfolgreich verarbeitet, aber muss keine physische Inhalte zurückgeben und möchte aktualisierte Metainformationen zurückgeben. Die Antwort kann in Form eines Entity-Headers vorliegen, das neue oder aktualisierte Metainformationen zurückgibt. Wenn diese Header-Informationen existieren, sollten sie der angeforderten Variable entsprechen. Wenn die Client-Seite ein Browser ist, sollte der Benutzerbrowser die Seite, die die Anfrage gesendet hat, ohne jegliche Änderungen an der Dokumentansicht beibehalten, selbst wenn neue oder aktualisierte Metainformationen gemäß der Spezifikation auf das Dokument in der aktiven Ansicht des Benutzerbrowsers angewendet werden sollten. Da die 204 Antwort ist es verboten, irgendeinen Nachrichtenkörper zu enthalten, sie endet immer mit der ersten leeren Zeile nach dem Header. |
| 205 | Der Server hat die Anfrage erfolgreich verarbeitet und nichts zurückgegeben. Aber im Gegensatz zur 204 Antwort, die Antwort, die diesen Statuscode zurückgibt, erfordert, dass der Anforderer die Dokumentansicht zurücksetzt. Diese Antwort wird hauptsächlich verwendet, um das Formular unmittelbar nach der Annahme der Benutzereingabe zurückzusetzen, damit der Benutzer leicht eine weitere Eingabe starten kann. Wie die 204 Antwort, diese Antwort ist ebenfalls davon ausgeschlossen, eine Nachrichtenkörper zu enthalten und endet mit der ersten leeren Zeile nach dem Header. |
| 206 | Der Server hat erfolgreich einen Teil der GET-Anfrage verarbeitet. HTTP-Download-Tools wie FlashGet oder Xunlei verwenden diesen Typ der Antwort, um einen Abbruch fortzusetzen oder ein großes Dokument in mehrere Download-Segmente zu zerlegen, um gleichzeitig herunterzuladen. Die Anfrage muss einen Range-Header enthalten, um den Inhaltsumfang anzuzeigen, den die Client-Seite möchte, und kann If-Als Anforderungsbedingung für Range. Die Antwort muss die folgenden Header-Felder enthalten: Content-Range, um den Inhaltsumfang zurückzugeben, der in dieser Antwort enthalten ist; wenn es sich um einen-Segment-Download mit Content-Typ multipart/byteranges enthält, sollte jeder Multiteil-Abschnitt einen Content-Header Range, um den Inhaltsumfang dieses Abschnitts anzuzeigen. Wenn die Antwort Content-Antwort-Header If-Length verwendet wird, muss sein Wert mit der tatsächlichen Anzahl der Bytes im zurückgegebenen Inhaltsumfang übereinstimmen. Datum ETag und/oder Content-Location, wenn die gleiche Anforderung eine 200-Antwort. Expires, Cache-Control und/Antwort-Header If oder Vary verwendet wird, wenn sein Wert von dem Wert abweichen kann, der auf andere Antworten zu demselben Variablen voranging. Wenn dieser-Range starken Cache-Validierung verwendet werden, sollte diese Antwort keine anderen Entity-Header enthalten; wenn dieser-Range schwachen Cache-Validierung verwendet werden, sollte diese Antwort keine anderen Entity-Header enthalten; dies verhindert Inconsistenzen zwischen dem zwischengespeicherten Entity-Inhalt und den aktualisierten Entity-Header-Informationen. Andernfalls sollte diese Antwort alle Entity-Header-Felder enthalten, die in einer 200-Antwort zurückgegeben wird, nicht kombinieren. Wenn ETag oder Last-Modified-Header für den-Header für die geänderte Modified-Header nicht exakt unterstützt, sollte den Inhalt, der in der 206 Antwort zurückgegebenen Inhalt mit jedem zuvor zwischengespeicherten Inhalt zu cachen. Jeder Cache, der Range und den-Das Range-Header ist davon ausgeschlossen, den vom 206 Antwort. |
| 207 | Ein Statuscode, der von WebDAV (RFC) erweitert wird 2518) zeigt an, dass der Körper der folgenden Nachricht eine XML-Nachricht sein wird und eine Reihe unabhängiger Antwortcodes enthalten kann, abhängig von der Anzahl der vorherigen Unter-Anfragen. |
| 300 | Die angeforderte Ressource hat eine Reihe von Rückmeldungsoptionen, jede mit ihrer eigenen spezifischen Adresse und Browser-getriebene Verhandlungsinformationen. Der Benutzer oder der Browser kann eine bevorzugte Adresse für die Umleitung auswählen. Es sei denn, dies ist ein HEAD-Anfrage, sollte die Antwort eine Entität enthalten, die eine Liste von Ressourceneigenschaften und Adressen enthält, aus denen der Benutzer oder der Browser die am besten geeignete Umleitungsadresse auswählen kann. Das Format dieser Entität wird durch das Format bestimmt, das durch Content-Typ. Der Browser kann automatisch die am besten geeignete Wahl basierend auf dem Format der Antwort und den eigenen Fähigkeiten des Browsers treffen. Natürlich enthält die RFC 2616 bestimmt nicht, wie eine solche automatische Auswahl durchgeführt werden soll. Wenn der Server selbst bereits eine bevorzugte Rückmeldungsselektion hat, sollte die URI der Rückmeldung im Feld 'Location' angegeben werden; Browser können diesen Wert als Adresse für die automatische Umleitung verwenden. Darüber hinaus ist die Antwort auch zwischengespeichert, es sei denn, anderes ist angegeben. |
| 301 | Die angeforderte Ressource wurde dauerhaft in eine neue Lage verschoben, und jede zukünftige Bezugnahme auf diese Ressource sollte eine der mehreren URIs verwenden, die von dieser Antwort zurückgegeben werden. Wenn möglich, sollte der Client mit Linkbearbeitungsfähigkeiten die angeforderte Adresse automatisch in die von dem Server zurückgegebene Adresse ändern. Es sei denn, anderes ist angegeben, ist diese Antwort auch zwischengespeichert. Die neue dauerhafte URI sollte im Feld 'Location' der Antwort zurückgegeben werden. Es sei denn, dies ist ein HEAD-Anfrage, sollte die Antwortentität einen Hyperlink zur neuen URI und eine kurze Beschreibung enthalten. Wenn dies keine GET- oder HEAD-Anfrage ist, ist der Browser von einer automatischen Umleitung verboten, es sei denn, der Benutzer bestätigt dies, da sich die Bedingungen der Anfrage ändern können. Hinweis: Für einige Browser, die die HTTP-Spezifikation verwenden/1.0-Protokoll, wenn sie eine POST-Anfrage senden und eine 301 Antwort angegeben ist, wird die nachfolgende Umleitungsanfrage GET sein. |
| 302 | Die angeforderte Ressource antwortet jetzt temporär auf die Anfrage von einer anderen URI. Da solche Umleitungen temporär sind, sollte die Client-Seite zukünftige Anfragen weiterhin an die ursprüngliche Adresse senden. Diese Antwort ist nur dann cachelbar, wenn sie im Feld Cache-Kontrolle oder Expires. Die neue temporäre URI sollte im Feld Location der Antwort zurückgegeben werden. Es sei denn, dies ist eine HEAD-Anfrage, sollte die Antwortentität einen Hyperlink zur neuen URI und eine kurze Beschreibung enthalten. Wenn dies keine GET- oder HEAD-Anfrage ist, verbietet der Browser automatische Umleitungen, es sei denn, sie werden durch den Benutzer bestätigt, da sich die Bedingungen der Anfrage als Folge dessen ändern könnten. Hinweis: Obwohl die RFC 1945 und RFC 2068 Spezifikationen erlauben es der Client-Seite nicht, die Methode der Anfrage bei der Umleitung zu ändern, viele bestehende Browser behandeln die 302 Antwort als 303 Antwort und verwenden GET, um auf die in der Location angegebene URI zuzugreifen, die ursprüngliche Anfragemethode zu ignorieren. Statuscodes 303 und 307 hinzugefügt wurden, um zu klären, was der Server von der Client-Seite erwartet. |
| 303 | Die Antwort auf die aktuelle Anfrage finden Sie auf einer anderen URI, und der Client sollte Zugang zu dieser Ressource mit GET erhalten. Diese Methode existiert hauptsächlich, um Skripten-aktiviert POST-Anforderungsausgabe, um auf eine neue Ressource umgeleitet zu werden. Diese neue URI ist keine Ersatzreferenz zur ursprünglichen Ressource. Auch, 303 Antworten dürfen nicht zwischengespeichert werden. Natürlich kann eine zweite Anforderung (Umleitung) zwischengespeichert werden. Die neue URI sollte im Feld Location der Antwort zurückgegeben werden. Es sei denn, dies ist eine HEAD-Anforderung, sollte die Antwortkörper eine Hyperlink zum neuen URI und eine kurze Beschreibung enthalten. Hinweis: Viele Browserversionen vor HTTP/1.1 nicht verstehen 303 wenn Sie Interaktionen mit diesen Browsern in Betracht ziehen müssen, die 302 der Statuscode sollte ausreichend sein, weil die meisten Browser die Statusmeldungen korrekt verarbeiten. 302 Antworten genau so behandeln, wie es die obige Spezifikation vorschreibt, dass die Client-Seite sie behandelt 303 Antworten. |
| 304 | Wenn die Client-Seite eine bedingte GET-Anforderung sendet und die Anforderung erlaubt wurde und der Inhalt des Dokuments sich nicht geändert hat (seit dem letzten Besuch oder gemäß den Bedingungen der Anforderung), sollte der Server diesen Statuscode zurückgeben. 304 Antworten dürfen keine Nachrichtenkörper enthalten, daher sollte die Antwort immer mit der ersten Leerzeile nach dem Kopf enden. Die Antwort muss die folgenden Kopfinformationen enthalten: Datum, es sei denn, dieser Server hat keine Uhr.
Wenn der Server ohne Uhr auch diese Regeln befolgt, können der Proxy-Server und die Client-Seite selbst das Datumsfeld zum empfangenen Antwortkopf hinzufügen (wie in RFC 2068), und das Caching-Mechanismus funktioniert gut. ETag und/oder Content-Location, wenn die gleiche Anforderung eine 200-Antwort. Expires, Cache-Control und/oder Vary verwendet wird und ihr Wert möglicherweise von dem Wert abweicht, der anderen Antworten auf denselben Variablenwert voranging.
Wenn diese Antwortanforderung eine starke Cache-Validierung verwendet, sollte diese Antwort keine anderen Entity-Header enthalten; andernfalls (z.B. eine bedingte GET-Anforderung verwendet eine schwache Cache-Validierung) ist es verboten, andere Entity-Header zu enthalten; dies vermeidet Inkonsistenzen zwischen dem gespeicherten Entity-Inhalt und den aktualisierten Entity-Header-Informationen. Wenn eine 304 Antwort anzeigt, dass eine Entität derzeit nicht im Cache gespeichert ist, muss das Caching-System die Antwort ignorieren und wiederholte Anfragen ohne Einschränkungen senden.
Wenn eine 304 Antwort erhalten, um einen Cache-Eintrag zu aktualisieren, muss das Caching-System den gesamten Eintrag aktualisieren, um die Werte aller Felder widerzuspiegeln, die in der Antwort aktualisiert wurden. |
| 305 | Der angeforderte Ressource muss über den angegebenen Proxy erreicht werden. Die URI-Information des angegebenen Proxys wird im Location-Feld gegeben. Der Empfänger muss wiederholt eine separate Anfrage senden, um den entsprechenden Ressource über diesen Proxy zu erreichen. Nur der Ursprungsserver kann eine 305 Antwort. Hinweis: Es gibt keine explizite 305 Antwort im RFC 2068 um eine einzelne Anfrage umzuleiten, und dies kann nur durch den Ursprungsserver eingerichtet werden. Das Ignorieren dieser Einschränkungen kann schwerwiegende Sicherheitsfolgen haben. |
| 306 | In der neuesten Version der Spezifikation wird die 306 Statuscode wird nicht mehr verwendet. |
| 307 | Der angeforderte Ressource antwortet jetzt temporär auf die Anfrage von einer anderen URI. Da solche Umleitungen temporär sind, sollte der Client zukünftige Anfragen weiterhin an die ursprüngliche Adresse senden. Diese Antwort kann nur im Cache gespeichert werden, wenn dies im Cache-Steuerung oder Ablaufdatum. Die neue temporäre URI sollte im Location-Feld der Antwort zurückgegeben werden. Es sei denn, es handelt sich um eine HEAD-Anfrage, sollte die antwortende Entität einen Hyperlink enthalten, der auf die neue URI verweist, sowie eine kurze Beschreibung. Da einige Browser die 307 Antwort, muss diese Information hinzugefügt werden, damit der Benutzer die Möglichkeit hat, den Zugriff auf die neue URI zu verstehen und zu beantragen.
Wenn dies keine GET- oder HEAD-Anfrage ist, verbietet der Browser automatische Umleitungen, es sei denn, sie werden durch den Benutzer bestätigt, da sich die Bedingungen der Anfrage als Folge dessen ändern könnten. |
| 400 | 1. Die Semantik ist falsch, und der aktuelle Anfrage kann vom Server nicht verstanden werden. Es sei denn, sie wird geändert, sollte die Client-Seite die Anfrage nicht wiederholt einreichen. 2. Die Anfrageparameter sind falsch. |
| 401 | Aktuelle Anfrage erfordert Benutzerauthentifizierung. Die Antwort muss eine WWW-Authenticate-Header für die angeforderte Ressource, um den Benutzer nach Informationen zu fragen. Die Client-Seite kann eine Anfrage mit der entsprechenden Authorization-Header-Information erneut einreichen. Wenn die aktuelle Anfrage bereits Autorisierungszertifikate enthält, dann die 401 Antwort zeigt an, dass der Server diese Zertifikate abgelehnt hat. Wenn der 401 Antwort enthält die gleiche Authentifizierungsabfrage wie die vorherige Antwort und der Browser hat mindestens einmal eine Authentifizierung versucht, dann sollte der Browser dem Benutzer die im Antwort enthaltene Entitätinformation zeigen, da diese Entitätinformation relevante Diagnoseinformationen enthalten kann. Siehe RFC 2617. |
| 402 | Dieser Statuscode ist für mögliche zukünftige Anforderungen reserviert. |
| 403 | Der Server hat die Anfrage verstanden, aber ablehnt, sie auszuführen. Im Gegensatz zu einem 401 Antwort enthält die gleiche Authentifizierungsabfrage wie die vorherige Antwort und der Browser hat mindestens einmal eine Authentifizierung versucht, dann sollte der Browser dem Benutzer die im Antwort enthaltene Entitätinformation zeigen, da diese Entitätinformation relevante Diagnoseinformationen enthalten kann. Siehe RFC 404 Antwort, wenn er nicht möchte, dass die Client-Seite irgendwelche Informationen erhält. |
| 404 | Die Anfrage schlug fehl, und das gewünschte Ressource wurde auf dem Server nicht gefunden. Es gibt keine Informationen, um dem Benutzer zu sagen, ob die Bedingung vorübergehend oder dauerhaft ist. Wenn der Server über die Situation Bescheid weiß, die 410 Der Statuscode sollte verwendet werden, um das alte Ressource zu informieren, dass es aufgrund eines internen Konfigurationsmechanismus dauerhaft nicht verfügbar ist und keinen Adresssaltzweck hat. Der 404 Der Statuscode wird weit verbreitet verwendet, wenn der Server nicht möchte, warum die Anfrage abgelehnt wurde, oder keine andere geeignete Antwort verfügbar ist. |
| 405 | The request method specified in the request line cannot be used to request the corresponding resource. The response must return an Allow header indicating a list of request methods that can be accepted by the current resource. Since PUT and DELETE methods write to resources on the server, most web servers do not support or do not allow the above request method by default, and will return a 405 Die im Request-Line angegebene Anfragemethode kann nicht verwendet werden, um die entsprechende Ressource anzufordern. Die Antwort muss einen Allow-Header zurückgeben, der eine Liste der Anfragemethoden enthält, die von der aktuellen Ressource akzeptiert werden können. Da PUT- und DELETE-Methoden Ressourcen auf dem Server schreiben, unterstützen die meisten Webserver diese Anfragemethoden standardmäßig nicht oder erlauben sie nicht, und geben daher eine zurück |
| 406 | Fehler für solche Anfragen.-Die inhaltlichen Merkmale der angeforderten Ressource erfüllen nicht die Bedingungen im Request-Header, daher kann keine Antwortentität generiert werden. Es sei denn, dies ist eine HEAD-Anfrage, dann sollte die Antwort eine Entität zurückgeben, die es dem Benutzer oder dem Browser ermöglicht, die am besten geeigneten Entitätsmerkmale und Adressenliste auszuwählen. Das Format der Entität wird durch den im Content definierten Medientyp bestimmt |
| 407 | Typenheader. Der Browser kann die beste Wahl auf Basis des Formats und seiner eigenen Fähigkeiten treffen. Allerdings definiert die Spezifikation keine Kriterien für die Durchführung solcher automatischen Auswahlen. 401 Ähnlich wie die-Authentifizierung für die Authentifizierung. Die Client-Seite kann eine Proxy-Antwort zurückgeben, wobei die Client-Seite jedoch auf dem Proxy-Server authentifiziert werden muss. Der Proxy-Server muss eine Proxy-Antwort zurückgeben-Autorisierungsheader für die Authentifizierung. Siehe RFC 2617. |
| 408 | Die Anfrage hat timed out. Die Client-Seite hat die Übermittlung der Anfrage innerhalb der Zeit nicht abgeschlossen, in der der Server bereit war, zu warten. Die Client-Seite kann die Anfrage jederzeit ohne Änderungen erneut einreichen. |
| 409 | Die Anfrage kann aufgrund eines Konflikts mit dem aktuellen Zustand der angeforderten Ressource nicht abgeschlossen werden. Dieser Code darf nur verwendet werden, wenn davon ausgegangen wird, dass der Benutzer in der Lage ist, den Konflikt zu lösen und eine neue Anfrage erneut einzureichen. Die Antwort sollte ausreichend Informationen enthalten, damit der Benutzer die Ursache des Konflikts erkennen kann. Konflikte treten in der Regel bei der Verarbeitung von PUT-Anfragen auf. Zum Beispiel in einer Version-geprüften Umgebung, wenn die an einen PUT angehängte Versionsinformation-vorgeschlagene Änderungsanfrage für eine bestimmte Ressource mit einer früheren (dritten-Partei) Anfrage, der Server sollte eine 409 Fehlermeldung an den Benutzer, dass die Anfrage nicht abgeschlossen werden konnte.
Zu diesem Zeitpunkt ist es wahrscheinlich, dass die Antwortkörper eine Vergleichsuntersuchung zwischen den beiden konkurrierenden Versionen enthält, so dass der Benutzer die zusammengeführte Version erneut einreichen kann. |
| 410 | Die angeforderte Ressource ist auf dem Server nicht mehr verfügbar und hat keine bekannte Weiterleitungsadresse. Diese Bedingung sollte als dauerhaft betrachtet werden. Wenn möglich, sollte der Client mit Linkbearbeitungsfähigkeiten alle Referenzen auf diese Adresse mit der Erlaubnis des Benutzers entfernen. Wenn der Server nicht weiß oder nicht bestimmen kann, ob diese Bedingung dauerhaft ist, dann wird eine 404 Statuscode verwendet werden sollte. Es sei denn, anderes ist angegeben, ist diese Antwort zwischengespeichert. Zweck der 410 Antwort wird hauptsächlich verwendet, um dem Webmaster bei der Wartung der Website zu helfen, dem Benutzer mitzuteilen, dass die Ressource nicht mehr verfügbar ist und dass der Serverinhaber alle Remote-Verbindungen zu dieser Ressource gelöscht haben möchte.
Dieser Typ von Ereignis ist in der Zeit-begrenzte, Wert-hinzugefügte Dienste. Ähnlich wie der 410 Antwort wird verwendet, um dem Client mitzuteilen, dass Ressourcen, die ursprünglich einer Person gehören, auf der aktuellen Serverseite nicht mehr verfügbar sind. Natürlich liegt es entirely in der Hand des Serverinhabers, ob alle dauerhaft nicht verfügbaren Ressourcen als' 410 Gone ', und wie lange diese Marke beibehalten werden soll. |
| 411 | Der Server lehnt die Anfrage ab, ohne einen Inhalt zu definieren.-Längenkopf. Nachdem ein gültiges Inhalt-Längenkopf, der die Länge des Anhangs der Anfrage anzeigt, kann der Client die Anfrage erneut einreichen. |
| 412 | Der Server hat bei der Überprüfung, ob die Voraussetzungen in der Kopfzeile der Anfrage angegeben wurden, eine oder mehrere Voraussetzungen nicht erfüllt. Dieser Statuscode ermöglicht es der Clientseite, Voraussetzungen in den angeforderten Metadaten (Anfragekopfzeilen Daten) festzulegen, wenn Ressourcen abgerufen werden, was verhindert, dass die Anfragemethode auf Ressourcen angewendet wird, die nicht gewünscht sind. |
| 413 | Der Server lehnt die Verarbeitung der aktuellen Anfrage ab, weil die Anfrage mehr Entitätsdaten einreicht als der Server bereit oder in der Lage ist zu verarbeiten. In diesem Fall kann der Server die Verbindung schließen, um zu verhindern, dass der Clientseite weiterhin die Anfrage sendet. Wenn diese Situation vorübergehend ist, sollte der Server einen Retry-Nach dem Antwortkopf, um dem Client mitzuteilen, wie lange er noch versuchen kann. |
| 414 | Die angeforderte URI ist länger als der Server interpretieren kann, daher lehnt der Server den Dienst für die Anfrage ab. Dies ist selten und häufige Fälle umfassen: Ein Formular, das die POST-Methode verwenden sollte, wird zu einer GET-Methode, was zu einem zu langen Query-String (Abfragezeichenfolge) führt. Umleitungs-URI "Schwarze Löcher", wie jede Umleitung, bei der der alte URI als Teil der neuen URI verwendet wird, was nach mehreren Umleitungen zu einer zu langen URI führt. Der Client versucht, den Server mit Sicherheitslücken zu angreifen, die in einigen Servern vorhanden sind.
Dieser Typ von Server verwendet einen festen-Längenpuffer, um die angeforderte URI zu lesen oder zu manipulieren, zurückgeben. Wenn die Parameter nach GET einen bestimmten Wert überschreiten, kann ein Pufferüberlauf auftreten, was zu einer willkürlichen Ausführung von Code führen kann [1]. Server ohne solche Schwachstellen sollten eine 414 Statuscode. |
| 415 | Für die Methode der aktuellen Anfrage und die angeforderte Ressource ist die im Antrag eingereichte Entität nicht im von der Server unterstützten Format, daher wird die Anfrage abgelehnt. |
| 416 | Wenn die Anfrage einen Range-Header enthält und keine der angegebenen Datenbereiche im Range mit dem verfügbaren Bereich der aktuellen Ressource übereinstimmt, und der If-Der Range-Header ist in der Anfrage nicht definiert, der Server sollte eine 416 status code. Wenn der Range einen Byte-Bereich verwendet, bedeutet dies, dass die erste Byte-Position aller durch die Anfrage angegebenen Datenbereiche die Länge der aktuellen Ressource überschreitet. Der Server sollte auch eine Content-Range-Entity-Header zusammen mit dem 416 status code, um die Länge der aktuellen Ressource anzuzeigen. Diese Antwort ist auch von der Verwendung von multipart verboten/byteranges als sein Inhalt-Typ. |
| 417 | Das im Request-Header angegebene erwartete Inhalt kann vom Server nicht erfüllt werden, oder der Server ist ein Proxy-Server, der eindeutige Beweise hat, dass das erwartete Inhalt auf dem nächsten Knoten der aktuellen Route nicht erfüllt werden kann. |
| 421 | Die Anzahl der Verbindungen zum Server aus der Internet-Protokoll-Adresse, von der aus der aktuelle Client-Side located ist, überschreitet die vom Server erlaubte maximale Anzahl. Typischerweise bezieht sich die Internet-Protokoll-Adresse hier auf die Client-Side-Adresse, wie sie vom Server aus gesehen wird (z.B. die Adresse des Benutzers Gateway oder Proxy-Server). In diesem Fall kann die Verbindungszahl mehr als einen Endbenutzer umfassen. |
| 422 | Die Anzahl der Verbindungen zum Server aus der Internet-Protokoll-Adresse, von der aus der aktuelle Client-Side located ist, überschreitet die vom Server erlaubte maximale Anzahl. Typischerweise bezieht sich die Internet-Protokoll-Adresse hier auf die Client-Side-Adresse, wie sie vom Server aus gesehen wird (z.B. die Adresse des Benutzers Gateway oder Proxy-Server). In diesem Fall kann die Verbindungszahl mehr als einen Endbenutzer umfassen. |
| 422 | Die Anfrage wurde korrekt formatiert, konnte aber aufgrund eines semantischen Fehlers 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, wie z.B. PROPPATCH, fehlgeschlagen. (RFC 4918 WebDAV) |
| 425 | Definiert im WebDav Advanced Collections Draft, aber nicht im WebDAV Sequential Set Protocol (RFC 3658). |
| 426 | Die Client-Seite sollte auf TLS umschalten/1.0. (RFC 2817) |
| 449 | Erweitert von Microsoft, sollten Anfragen nach Ausführung der entsprechenden Maßnahmen neu versucht werden. |
| 500 | Der Server stieß auf eine unerwartete Situation, die ihn daran hinderte, die Anfrage abzuschließen. In der Regel tritt dieses Problem auf, wenn der Code des Servers fehlschlägt. |
| 501 | Der Server unterstützt eine für die aktuelle Anfrage erforderliche Funktion nicht. Wenn der Server die angeforderte Methode nicht erkennen kann und seine Anfrage für任何资源不支持. |
| 502 | Wenn ein Server als Gateway oder Proxy arbeitet und versucht, eine Anfrage auszuführen, erhält er eine ungültige Antwort von einem Upstream-Server. |
| 503 | The server is currently unable to process requests due to temporary server maintenance or overload. This condition is temporary and will be restored after some time. If the delay time can be predicted, the response can include a Retry-After header to indicate the delay time. If this Retry-After information is not given, the client side should handle it as if it were a 500 response. Note: The existence of a 503 status code does not mean that the server must use it in the event of an overload. Some servers simply wish to deny the client's connection. |
| 504 | When a server working as a gateway or proxy attempts to execute a request, it fails to receive a response from an upstream server (identified by the URI, such as HTTP, FTP, LDAP) or a secondary server (such as DNS) in a timely manner. Note: Some proxy servers return a 400 or 500 error when the DNS query times out |
| 505 | The server does not support, or refuses to support, the version of HTTP used in the request. This implies that the server cannot or will not use the same version as the client side. The response should include an entity describing why the version is not supported and which protocols the server supports. |
| 506 | Extended by the Transparent Content Negotiation Protocol (RFC 2295), this represents an internal configuration error on the server: the requested negotiation variable resource is configured to use itself in a transparent content negotiation, and therefore is not an appropriate focus in a negotiation process. |
| 507 | The server cannot store the content necessary to complete the request. This condition is considered temporary. WebDAV (RFC 4918) |
| 509 | Server has reached bandwidth limit. This is not an official status code, but it is still widely used. |
| 510 | The policies required to acquire resources are not met. (RFC 2774) |
