Online-Werkzeuge
Http Status Codes Statuscode 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 zurückgewiesen 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 Upgrade-Header mit, dass ein anderes Protokoll zum Abschluss der Anfrage verwendet wurde. Nach dem Senden der letzten Leerzeile der Antwort wechselt der Server zu den im Upgrade-Header definierten Protokollen. Dies sollte nur geschehen, wenn es vorteilhafter ist, auf das neue Protokoll umzuschalten. So kann beispielsweise der Wechsel zu einer neuen Version von HTTP vorteilhafter sein als zu einer älteren Version oder der Wechsel zu einem synchronen Echtzeitprotokoll, 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 die von der Anfrage gewünschten Antwort-Header oder Datenkörper werden mit der Antwort zurückgegeben.
201 Die Anforderung wurde erfüllt und eine neue Ressource wurde als Antwort auf die Anforderung erstellt und ihr URI wurde mit dem Location-Header zurückgegeben. Wenn die angeforderte Ressource nicht rechtzeitig erstellt werden kann, sollte Folgendes zurückgegeben werden'202 Accepted'。
202 Der Server hat die Anfrage angenommen, aber noch nicht verarbeitet. Genauso wie die Anfrage abgelehnt werden kann, kann sie letztendlich ausgeführt werden oder auch nicht. Bei asynchronen Vorgängen gibt es nichts Bequemeres, als diesen Statuscode zu senden. Der Zweck der Rückgabe einer 202-Antwort 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 eine Verbindung zum Server aufrechterhalten muss, bis die Batch-Operation 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 oder nicht.
203 Der Server hat die Anfrage erfolgreich bearbeitet, aber die zurückgegebene Entity-Header-Meta-Information ist kein endgültiger Satz, der auf dem ursprünglichen Server gültig ist, sondern eine Kopie von einer lokalen oder dritten Partei. Bei den aktuellen Informationen kann es sich um eine Teilmenge oder Obermenge des Originals handeln. Zum Beispiel können Metadaten, die Ressourcen enthalten, dazu führen, dass der Ursprungsserver die Meta-Informationen super 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 diese Kopfzeilen vorhanden sind, sollten sie den angeforderten Variablen entsprechen. Handelt es sich bei dem Client um einen Browser, SOLLTE der Browser des Benutzers die Seite, auf der die Anfrage gesendet wurde, ohne Änderungen an 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 bearbeitet die Anfrage erfolgreich und gibt nichts zurück. 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 vornehmen 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 um eine große Datei in mehrere Downloads gleichzeitig 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, um den Umfang des in dieser Antwort zurückgegebenen Inhalts anzugeben, oder, im Fall von mehrteiligen Downloads mit einem Content-Type von multipart/byteranges, ein Content-Range-Feld in jedem mehrteiligen Segment, um den Umfang des Inhalts in diesem Segment anzugeben. Wenn die Antwort eine Content-Length enthält, muss ihr Wert mit der tatsächlichen Anzahl der Bytes im Bereich des zurückgegebenen Inhalts übereinstimmen. Expires, Cache-Control und/oder Vary, wenn sich deren Werte von den Werten anderer vorheriger Antworten mit denselben 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 dem gecachten Entity-Inhalt und den aktualisierten Entity-Header-Informationen vermieden. Andernfalls SOLLTE diese Antwort alle Entity-Header-Felder enthalten, die in der 200-Antwort 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 nicht zulassen. Jeder Cache, der die Range- und Content-Range-Header nicht unterstützt, darf den von der 206-Antwort zurückgegebenen Inhalt nicht zwischenspeichern.
207 Von WebDAV erweiterte Statuscodes(RFC 2518) Der von WebDAV erweiterte Statuscode bedeutet, dass der nachfolgende Nachrichtentext eine XML-Nachricht ist und je nach Anzahl der vorangegangenen Unterabfragen eine Reihe von separaten Antwortcodes enthalten kann.
300 Die angeforderte Ressource verfügt über eine Reihe von alternativen Antworten, jede mit ihrer eigenen spezifischen Adresse und browsergesteuerten Verhandlungsinformationen. Es ist Sache des Benutzers oder Browsers, eine bevorzugte Adresse für die Weiterleitung zu wä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 diese automatische Auswahl zu erfolgen hat. Wenn der Server selbst bereits eine bevorzugte Rückgabeoption hat, sollte die URI der Rückgabe in der Location angegeben werden; die Browser können diesen Location-Wert als Adresse für die automatische Umleitung verwenden. Darüber hinaus ist die Antwort, sofern nicht anders angegeben, cachefähig.
301 Die angeforderte Ressource wurde dauerhaft an den neuen Speicherort verschoben, und alle künftigen Verweise auf sie sollten einen der verschiedenen URIs verwenden, die in dieser Antwort zurückgegeben werden. 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, darf der Browser keine automatische Weiterleitung vornehmen, 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 Umleitungsanforderung GET sein.
302 Die angeforderte Ressource antwortet nun vorübergehend auf die Anfrage von einem anderen URI. Da diese Umleitung vorübergehend ist, sollte der Client künftige Anfragen weiterhin an die ursprüngliche Adresse senden. Die Antwort ist nur dann cachbar, 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 gestatten, die Methode der Anfrage während 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 auf eine neue Ressource umzuleiten. Diese neue URI ist kein Ersatzverweis auf die ursprüngliche Ressource. Außerdem darf die 303-Antwort nicht zwischengespeichert werden. Natürlich darf die zweite Anfrage (Umleitung) zwischengespeichert werden. Die 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 verstehen den 303-Status nicht richtig. Wenn eine Interaktion mit diesen Browsern in Betracht gezogen werden muss, sollte der 302-Statuscode funktionieren, da die meisten Browser die 302-Antwort genau so behandeln, wie es die obige Spezifikation vom Client für die 303-Antwort verlangt.
304 Dieser Statuscode sollte vom Server zurückgegeben werden, wenn der Client eine bedingte GET-Anfrage sendet und die Anfrage zulässig ist und der Inhalt des Dokuments sich nicht geändert hat (entweder seit dem letzten Besuch oder gemäß den Bedingungen der Anfrage). 304-Antworten dürfen keinen Nachrichtentext enthalten und enden daher immer mit der ersten Leerzeile nach dem Header der Nachricht. Die Antwort muss die folgenden Header-Informationen enthalten: Datum, es sei denn, der Server verfügt über keine Uhr. Wenn der Server keine Uhr hat, 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 wird ordnungsgemäß funktionieren.ETag und/oder Content-Location, wenn dieselbe Anfrage eine 200er-Antwort hätte liefern sollen. Expires, Cache-Control und/oder Vary, wenn sich ihre Werte von den Werten anderer früherer Antworten mit denselben Variablen unterscheiden können. Wenn die Antwortanfrage eine starke Cache-Validierung verwendet, sollte die Antwort keine zusätzlichen Entity-Header enthalten; andernfalls (z. B. wenn eine bedingte GET-Anfrage eine schwache Cache-Validierung verwendet) ist es der Antwort untersagt, zusätzliche Entity-Header zu enthalten; dadurch werden Inkonsistenzen zwischen gecacheten 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 diese 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 einen bestimmten Proxy zugegriffen werden. Das Feld Location enthält Informationen über den URI des angegebenen Proxys, und der Empfänger muss wiederholt eine separate Anfrage senden, um auf die Ressource über diesen Proxy 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 Ursprungsserver erstellt werden kann. Die Nichtbeachtung dieser Einschränkungen kann schwerwiegende Sicherheitsfolgen nach sich ziehen.
306 In der neuesten Version der Spezifikation wird der Statuscode 306 nicht mehr verwendet.
307 Angefragte Ressourcen antworten nun vorübergehend auf Anfragen von anderen URIs. Da diese Umleitung nur vorübergehend ist, sollten Clients zukü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, ist es notwendig, die oben genannten Informationen hinzuzufügen, damit der Benutzer den neuen URI verstehen und Zugang zu ihm 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, semantischer Fehler, die aktuelle Anfrage kann vom Server nicht verstanden werden. Der Client sollte die Anfrage nicht wiederholen, wenn sie nicht geändert wird. 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 eine Anfrage mit den entsprechenden Autorisierungs-Header-Informationen erneut übermitteln. Wenn die aktuelle Anfrage bereits Autorisierungsdaten enthält, bedeutet eine 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, 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 die Anfrage sollte nicht erneut gesendet werden. Wenn es sich nicht um eine HEAD-Anfrage handelt und der Server in der Lage sein möchte, mitzuteilen, warum die Anfrage nicht ausgeführt werden kann, dann sollte der Grund für die Ablehnung in der Entität beschrieben werden. Natürlich kann der Server auch eine 404-Antwort zurückgeben, wenn er nicht möchte, dass der Client irgendwelche Informationen erhält.
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 Server 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 preisgeben will, 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, werden sie von den meisten Webservern standardmäßig nicht unterstützt oder zugelassen und geben für solche Anfragen 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 die am besten geeigneten Entitätsmerkmale und eine Liste von Adressen enthält, aus denen der Benutzer oder Browser wählen kann. Das Format der Entität wird durch den im Content-Type-Header definierten Medientyp bestimmt. Der Browser kann auf der Grundlage des Formats und seiner 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-Authorisation-Header zur Authentifizierung zurücksenden. Siehe RFC 2617.
408 Anfrage-Zeitüberschreitung. Der Client hat eine 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 häufig bei der Verarbeitung von PUT-Anfragen auf. In einer Umgebung mit Versionskontrolle sollte beispielsweise eine PUT-Anfrage zur Änderung einer bestimmten Ressource mit Versionsinformationen, die mit einer früheren (fremden) Anfrage in Konflikt steht, 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 in Konflikt stehenden Versionen enthalten, so dass der Benutzer die neue, zusammengeführte Version erneut übermitteln kann.
410 Die angeforderte Ressource ist auf dem Server nicht mehr verfügbar und es gibt keine bekannte Weiterleitungsadresse. Eine solche Situation 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 der Zustand dauerhaft ist, sollte ein 404-Statuscode verwendet werden. Der Zweck der 410-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 Eigentümer des Servers wünscht, dass alle Fernverbindungen zu dieser Ressource ebenfalls gelöscht werden. Diese Art von Ereignissen ist bei zeitlich begrenzten Diensten mit Mehrwert üblich. In ähnlicher Weise wird die Antwort 410 verwendet, um dem Client mitzuteilen, dass eine Ressource, die einer Person gehört, am aktuellen Serverstandort nicht mehr verfügbar ist. Natürlich ist auch die Frage wichtig, ob alle dauerhaft nicht verfügbaren Ressourcen als solche gekennzeichnet werden müssen und wie lange sie in diesem Zustand gehalten werden müssen.'410 Gone'， Wie lange diese Kennzeichnung aufrechterhalten werden soll, ist allein Sache des Serverbetreibers.
411 Der Server weigert sich, Anfragen ohne den Content-Length-Header zu akzeptieren. Der Client kann die Anfrage erneut übermitteln, nachdem er einen gültigen Content-Length-Header hinzugefügt hat, der die Länge des Nachrichtentextes der Anfrage angibt.
412 Der Server konnte bei der Validierung der Anfrage eine oder mehrere der im Header-Feld der Anfrage angegebenen Voraussetzungen nicht erfüllen. Dieser Statuscode ermöglicht es dem Client, bei der Abfrage einer Ressource Vorbedingungen in den Metainformationen der Anfrage (Daten des Anfrage-Header-Feldes) festzulegen und damit 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 mehr physische Daten enthält, als der Server verarbeiten kann oder will. In diesem Fall kann der Server die Verbindung schließen, um den Client daran zu hindern, die Anfrage weiter zu senden. Wenn die Situation vorübergehend ist, sollte der Server einen Retry-After-Header zurücksenden, um dem Client mitzuteilen, wie viel Zeit er für einen erneuten Versuch hat.
414 Der Anforderungs-URI ist länger als der Server interpretieren kann, so dass der Server sich weigert, die Anforderung zu bedienen. Dies kommt selten vor und tritt in der Regel auf, wenn eine Formularübermittlung, die die POST-Methode hätte verwenden sollen, zu einer GET-Methode wird, was zu einem langen Query String führt. Schwarze Löcher" bei URI-Umleitungen, 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 angeforderten URI zu lesen oder zu manipulieren, was zu einem Pufferüberlauf führen kann, wenn der GET-Parameter einen bestimmten Wert überschreitet, was 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 und die Anforderung wird zurückgewiesen.
416 Wenn die Anforderung einen Range-Anforderungsheader enthält und alle im Range angegebenen Datenbereiche nicht mit den für die aktuelle Ressource verfügbaren Bereichen übereinstimmen und der If-Range-Anforderungsheader in der Anforderung nicht definiert ist, sollte der Server einen 416-Statuscode zurückgeben. Wenn Range Bytebereiche verwendet, bedeutet dies, dass das erste Byte 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 der 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 des aktuellen Clients ü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 es sein, dass mehr als ein Endbenutzer an der Verbindungszählung beteiligt ist.
422 Die Anzahl der Verbindungen von der IP-Adresse des aktuellen Clients zum Server ü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 es sein, dass mehr als ein Endbenutzer an der Verbindungszählung beteiligt ist.
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) 423 Gesperrt
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 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 gehindert hat, die Bearbeitung der Anfrage abzuschließen. Typischerweise tritt dieses Problem auf, wenn ein Fehler im Programmcode des Servers vorliegt.
501 Der Server unterstützt eine Funktion nicht, die für die aktuelle Anfrage erforderlich ist. Wenn der Server die angeforderte Methode nicht erkennt und die Anfrage nach einer Ressource nicht unterstützen kann.
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 ist derzeit nicht in der Lage, die Anfrage zu bearbeiten, weil der Server vorübergehend gewartet wird oder überlastet ist. Dieser Zustand ist vorübergehend und wird nach einer gewissen 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 500-Antwort behandeln. Hinweis: Die Existenz des Statuscodes 503 bedeutet nicht, dass der Server ihn verwenden muss, wenn er überlastet ist. Manche Server wollen dem Client einfach eine Verbindung verweigern.
504 Ein Server, der als Gateway oder Proxy fungiert und versucht, eine Anfrage auszuführen, erhält keine rechtzeitige Antwort von einem Upstream-Server (einem Server, der durch einen URI identifiziert wird, z. B. HTTP, FTP, LDAP) oder einem Sekundärserver (z. B. DNS). Hinweis: Einige Proxyserver 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 Transparent Content Negotiation verwendet, und ist daher kein geeigneter Fokus in einem Verhandlungsprozess.
507 Der Server ist nicht in der Lage, den zur Erfüllung der Anforderung erforderlichen Inhalt zu speichern. Dieser Zustand wird als vorübergehend angesehen.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 erfüllt. (RFC 2774)
Zugang zu Aufzeichnungen: