| Http-Statuscode |
Bedeutung des Statuscodes |
| 100 |
Der Client sollte die Anfrage fortsetzen. Diese vorübergehende Antwort wird verwendet, um den Client zu benachrichtigen, dass ein Teil seiner Anfrage vom Server empfangen wurde und nicht abgelehnt wurde. Der Client sollte den verbleibenden Teil der Anfrage senden oder, wenn die Anfrage abgeschlossen ist, diese Antwort ignorieren. Der Server muss dem Client nach Abschluss der Anfrage eine endgültige Antwort senden. |
| 101 |
Der Server hat die Anfrage des Clients verstanden und wird den Client über den Upgrade-Header benachrichtigen, um ein anderes Protokoll zu verwenden, um diese Anfrage abzuschließen. Nach dem Senden dieser Antwort und der letzten Leerzeile wechselt der Server zu den im Upgrade-Header definierten Protokollen. Es sollten nur Maßnahmen ergriffen werden, wenn der Wechsel zu einem neuen Protokoll vorteilhaft ist. Beispielsweise wäre der Wechsel zu einer neuen HTTP-Version vorteilhafter als die alte Version oder das Wechseln zu einem Echtzeit- und synchronen Protokoll für die Übertragung von Ressourcen, die solche Eigenschaften nutzen. |
| 102 |
Ein erweiterter Statuscode von WebDAV (RFC 2518), der anzeigt, dass die Verarbeitung fortgesetzt wird. |
| 200 |
Die Anfrage war erfolgreich, die gewünschten Antwortköpfe oder der Datenkörper werden mit dieser Antwort zurückgegeben. |
| 201 |
Die Anfrage wurde erfolgreich verarbeitet und es wurde eine neue Ressource erstellt, die auf die Anforderungen der Anfrage basiert, und ihre URI wurde mit dem Location-Header zurückgegeben. Wenn die benötigte Ressource nicht innerhalb eines angemessenen Zeitrahmens erstellt werden kann, sollte '202 Accepted' zurückgegeben werden. |
| 202 |
Der Server hat die Anfrage angenommen, aber noch nicht bearbeitet. Wie es abgelehnt werden könnte, könnte die Anfrage schlussendlich auch nicht ausgeführt werden. In Fällen von asynchronen Operationen gibt es keinen bequemeren Schritt als diesen Statuscode zurückzugeben. Der Zweck der Rückgabe einer Antwort mit dem Statuscode 202 ist es, dem Server zu erlauben, die Anfragen anderer Prozesse (z.B. eine einmal täglich ausgeführte Batch-Operation) zu akzeptieren, ohne dass der Client weiterhin eine Verbindung mit dem Server aufrechterhalten muss, bis die Batch-Operation vollständig abgeschlossen ist. Bei der Bearbeitung von Anfragen und dem Zurückgeben einer 202-Statuscode-Antwort sollten Informationen über den aktuellen Verarbeitungsstatus und Hinweise zur Überwachung des Verarbeitungsstatus enthalten sein, damit der Benutzer schätzen kann, ob die Operation bereits abgeschlossen ist. |
| 203 |
Der Server hat die Anfrage erfolgreich verarbeitet, aber die zurückgegebenen Metainformationen des Entitätskopfs sind nicht die auf dem Ursprungsserver gültige definitive Menge, sondern stammen aus einer lokalen oder Drittstadtkopie. Die aktuellen Informationen können ein Teil- oder Übermengen der Originalversion sein. Beispielsweise könnten die Metadaten der Ressource dazu führen, dass der Ursprungsserver von den Supermetainformationen erfährt. Die Verwendung dieses Statuscodes ist nicht zwingend erforderlich und nur sinnvoll, wenn die Antwort ansonsten ohne diesen Statuscode eine 200 OK zurückgegeben hätte. |
| 204 |
Der Server hat die Anfrage erfolgreich verarbeitet, benötigt jedoch keine Rückgabe eines Entitätsinhalts und möchte aktualisierte Metainformationen zurückgeben. Die Antwort kann in Form des Entitätskopfes neue oder aktualisierte Metainformationen zurückgeben. Wenn diese Kopfzeilen existieren, sollten sie den angeforderten Variablen entsprechen. Wenn der Client ein Browser ist, sollte der Benutzerbrowser die Seite, die diese Anfrage gesendet hat, beibehalten, ohne dass es zu Änderungen in der Dokumentansicht kommt, selbst wenn neue oder aktualisierte Metainformationen gemäß den Spezifikationen auf die Dokumentansichten im Benutzerbrowser angewendet werden sollten. Da 204-Antworten die Rückgabe eines Nachrichtentextes verbieten, endet sie immer mit der ersten Leerzeile nach dem Nachrichtenkopf. |
| 205 |
Der Server hat die Anfrage erfolgreich verarbeitet und gibt keine Inhalte zurück. Im Gegensatz zur 204-Antwort verlangt die Rückgabe dieser Statuscode-Antwort die Rücksetzung der Dokumentansicht durch den Anforderer. Diese Antwort wird hauptsächlich verwendet, nachdem Benutzereingaben akzeptiert wurden, um schnell das Formular zurückzusetzen, damit der Benutzer erneut eingeben kann. Wie bei der 204-Antwort ist auch diese Antwort von der Rückgabe einer Nachrichtentexts ausgeschlossen und endet mit der ersten Leerzeile nach dem Nachrichtenkopf. |
| 206 |
Der Server hat einen Teil der GET-Anfrage erfolgreich verarbeitet. Ähnliche HTTP-Downloadtools wie FlashGet oder Thunder implementieren diese Antwort, um eine unterbrochene Übertragung fortzusetzen oder ein großes Dokument in mehrere gleichzeitige Downloads zu unterteilen. Die Anfrage muss einen Range-Header enthalten, um den Inhaltbereich anzugeben, den der Client erhalten möchte, und kann eventuell If-Range als Antragsbedingung enthalten. Die Antwort muss folgende Kopfzeilen enthalten: Content-Range, um anzugeben, welcher Inhalt bei dieser Antwort zurückgegeben wurde; wenn es sich um multipart/byteranges mit mehrteiligen Downloads handelt, sollte jeder Mehrteiler einen Content-Range-Kopf enthalten, um den Inhalt dieses Abschnitts anzugeben. Falls die Antwort einen Content-Length enthält, muss dessen Wert mit der tatsächlichen Byteanzahl des zurückgegebenen Inhaltsbereichs übereinstimmen. Date ETag und / oder Content-Location, wenn die gleiche Anfrage tatsächlich eine 200-Antwort zurückgegeben hätte. Expires, Cache-Control und / oder Vary, wenn deren Werte möglicherweise von den Werten anderer Antworten für dasselbe Anforderungsvariablen abweichen. Wenn diese Antwort mit einer If-Range starken Cache-Validierung angefordert wurde, sollte keine anderen Entitätskopfdaten in dieser Antwort enthalten sein; wenn die Anfrage dieser Antwort eine If-Range schwache Cache-Validierung verwendet hat, sollte diese Antwort keine anderen Entitätskopfdaten enthalten; dies vermeidet Inkonsistenzen zwischen den zwischengespeicherten Inhaltsdaten und den aktualisierten Entitätskopfinformationen. Andernfalls sollte diese Antwort alle Entitätskopfzeilen enthalten, die normalerweise in einer Antwort für Status 200 zurückgegeben werden sollten. Wenn ETag oder Last-Modified-Kopf nicht genau übereinstimmen kann, sollte der Client-Cache das von der 206-Antwort zurückgegebene Material nicht mit dem zuvor zwischengespeicherten Material kombinieren. Jeder Cache, der Range und Content-Range-Kopfen nicht unterstützt, sollte 206-Antworten nicht speichern. |
| 207 |
Ein erweiterter Statuscode von WebDAV (RFC 2518), der anzeigt, dass der kommende Nachrichtenkörper eine XML-Nachricht sein wird und möglicherweise in Abhängigkeit von der Anzahl der vorhergehenden Teilanfragen eine Reihe von separaten Antwortcodes enthalten kann. |
| 300 |
Die angeforderte Ressource hat eine Reihe von antwortfähigen Informationen, die jeweils mit einer spezifischen Adresse und von einem vom Browser gesteuerten Werbeteilnehmer verbunden sind. Der Benutzer oder der Browser kann eine bevorzugte Adresse zum Umleiten auswählen. Es sei denn, dies ist eine HEAD-Anfrage, sollte die Antwort einen Körper des Entitäts enthalten, der eine Liste der Ressourcenmerkmale und Adressen enthält, aus denen der Benutzer oder der Browser den geeignetsten Umleitungsort wählen kann. Das Format dieses Körpers wird durch das im Content-Type festgelegte Format bestimmt. Der Browser kann anhand des Formats und seiner eigenen Fähigkeiten die geeignetste Auswahl treffen. Natürlich sind solche automatischen Auswahlverfahren in der RFC 2616-Norm nicht festgelegt. Wenn der Server bereits eine bevorzugte Rückmeldewahl hat, sollte dieser Rückmeldungs URI im Standort angegeben werden. Browsers können diesen Location-Wert möglicherweise als Adresse für eine automatische Umleitung verwenden. Darüber hinaus ist diese Antwort, sofern nicht anders angegeben, ebenfalls speicherbar. |
| 301 |
Die angeforderte Ressource wurde dauerhaft an einen neuen Ort verschoben, und zukünftige Verweise auf diese Ressource sollten einen der in dieser Antwort zurückgegebenen URIs verwenden. Wenn möglich, sollten Clients mit Bearbeitungslinks die angeforderte Adresse automatisch auf die vom Server zurückgegebene Adresse ändern. Diese Antwort ist, sofern nicht anders angegeben, ebenfalls speicherbar. Die neue dauerhafte URI sollte im Location-Feld der Antwort zurückgegeben werden. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte der Antwortkörper einen Hyperlink auf die neue URI sowie eine kurze Beschreibung enthalten. Wenn dies keine GET- oder HEAD-Anfrage ist, ist der Browser davor geschützt, eine automatische Umleitung durchzuführen, es sei denn, der Benutzer gibt seine Zustimmung, da sich die Anforderungen dadurch ändern können. Hinweis: Bei einigen Browsern, die das HTTP/1.0-Protokoll verwenden, kann eine nachfolgende Umleitungsanforderung zu einem POST-Request geführt werden, wenn eine 301-Antwort empfangen wurde, um auf die GET-Methode umzuleiten. |
| 302 |
Die angeforderte Ressource wird vorübergehend von einer anderen URI angefordert. Da eine solche Umleitung vorübergehend ist, sollte der Client weiterhin Anfragen an die ursprüngliche Adresse senden. Diese Antwort ist nur dann speicherbar, wenn in Cache-Control oder Expires etwas angegeben wurde. Die neue, vorübergehende URI sollte im Standortfeld der Antwort zurückgegeben werden. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte die Antwort einen Hyperlink auf die neue URI sowie eine kurze Beschreibung enthalten. Wenn dies keine GET- oder HEAD-Anfrage ist, ist der Browser davor geschützt, eine automatische Umleitung durchzuführen, es sei denn, der Benutzer gibt seine Zustimmung, da sich die Bedingungen der Anfrage dadurch ändern können. Hinweis: Obwohl die RFC 1945 und RFC 2068-Normen es dem Client nicht erlaubten, bei Umleitungen den Anfrage-Befehlsmodus zu ändern, werden viele bestehende Browser eine 302-Antwort als eine 303-Antwort ansehen und mit der GET-Methode auf die in Location angegebene URI zugreifen, wobei der ursprüngliche Anfrage-Befehlsmodus ignoriert wird. Die Statuscodes 303 und 307 wurden hinzugefügt, um deutlich zu machen, wie der Server erwartet, dass der Client reagiert. |
| 303 |
Die Antwort auf die aktuelle Anfrage kann an einer anderen URI gefunden werden, und der Client sollte versuchen, diese Ressource mit der GET-Methode zu erreichen. Diese Methode wurde hauptsächlich eingeführt, um eine durch Skripte aktivierte POST-Anfrage auf eine neue Ressource umzuleiten. Diese neue URI stellt kein alternatives Referenzstück zur ursprünglichen Ressource dar. Gleichzeitig ist die 303-Antwort speicherbar, aber die zweite Anfrage (Umleitung) könnte zwischengespeichert werden. Die neue URI sollte im Standortfeld der Antwort zurückgegeben werden. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte die Antwort einen Hyperlink auf die neue URI sowie eine kurze Beschreibung enthalten. Hinweis: Viele vor der HTTP/1.1-Version vorgenommenen Browser konnten den 303-Status nicht korrekt verstehen. Wenn eine Interaktion mit diesen Browsern notwendig ist, sollte der 302-Status ausreichen, da die meisten Browser die 302-Antwort genau so behandeln, wie die Norm für die Behandlung der 303-Antwort vorgibt. |
| 304 |
Wenn der Client eine bedingte GET-Anfrage gesendet hat und diese Anfrage zugelassen wurde und der Inhalt des Dokuments (seit dem letzten Besuch oder gemäß den Antragsbedingungen) sich nicht geändert hat, sollte der Server diesen Statuscode zurückgeben. Die 304-Antwort enthält keinen Nachrichtentext, daher endet sie immer mit der ersten Leerzeile nach dem Nachrichtenkopf. Diese Antwort muss folgende Kopfzeilen enthalten: Datumsangabe, es sei denn, dieser Server hat keine Uhr. Wenn ein Server ohne Tisch auch diese Regeln befolgt, können Proxy-Server und Clients das Datumsfeld in den empfangenen Antwortkopf aufnehmen (so wie in RFC 2068 angegeben), und die Caching-Mechanismen funktionieren normal. ETag und / oder Content-Location, wenn die gleiche Anfrage tatsächlich eine 200-Antwort zurückgeben sollte. Expires, Cache-Control und / oder Vary, wenn deren Werte möglicherweise von den Werten anderer Zeiten, in denen dasselbe Anforderungsvariablen behandelt wurde, abweichen. Wenn der Anforderer dieser Antwort eine starke Cache-Überprüfung verwendet hat, sollten keine anderen Entitätskopfdaten in dieser Antwort enthalten sein; andernfalls (z.B. bei einer bedingten GET-Anfrage, die eine schwache Cache-Überprüfung verwendet) sollte diese Antwort ebenfalls keine anderen Entitätskopfdaten enthalten; dies vermeidet Inkonsistenzen zwischen zwischengespeicherten Entitätsinhalten und aktualisierten Entitätskopfinformationen. Sollte eine 304-Antwort darauf hinweisen, dass eine bestimmte Entität nicht im Cache gespeichert ist, sollte das Cache-System diese Antwort ignorieren und die Anfragen wiederholen, ohne Einschränkungen zu senden. Sollte eine 304-Antwort empfangen werden, die eine Aufforderung zur Aktualisierung eines Cache-Eintrags darstellt, sollte das Cache-System den gesamten Eintrag aktualisieren, um die Werte sämtlicher in der Antwort aktualisierten Felder zu widerspiegeln. |
| 305 |
Die angeforderte Ressource muss über einen angegebenen Proxy bereitgestellt werden. Die Standortangabe liefert Informationen über die URI des angegebenen Proxys, der Empfänger muss eine separate Anfrage an diese Adresse senden, um auf die entsprechende Ressource zuzugreifen. Nur der ursprüngliche Server kann eine 305-Antwort erzeugen. Hinweis: RFC 2068 macht nicht explizit deutlich, dass eine 305-Antwort zur Umleitung einer einzelnen Anfrage dient, und dass sie nur vom ursprünglichen Server erzeugt werden kann. Diese Einschränkungen zu ignorieren kann zu schwerwiegenden Sicherheitsproblemen führen. |
| 306 |
In der neuesten Spezifikation wird der 306-Statuscode nicht mehr verwendet. |
| 307 |
Die angeforderte Ressource wird vorübergehend von einer anderen URI angefordert. Da eine solche Umleitung vorübergehend ist, sollte der Client weiterhin Anfragen an die ursprüngliche Adresse senden. Diese Antwort ist nur dann speicherbar, wenn angibt, dass Cache-Control oder Expires etwas vorsehen. Die neue, vorübergehende URI sollte im Standortfeld der Antwort zurückgegeben werden. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte die Antwort einen Hyperlink auf die neue URI sowie eine kurze Beschreibung enthalten. Da einige Browser 307-Antworten möglicherweise nicht erkennen, sollten die oben genannten notwendigen Informationen ergänzt werden, damit Benutzer klar verstehen können, dass sie an die neue URI weitergeleitet werden sollen. Wenn dies keine GET- oder HEAD-Anfrage ist, darf der Browser keine automatische Umleitung ohne ausdrückliche Genehmigung des Benutzers durchführen, da sich die Anforderungen durch diese änderungen möglicherweise ändern. |
| 400 |
1. Semantische Fehler, die aktuelle Anfrage kann vom Server nicht verstanden werden. Der Client sollte diese Anfrage nicht wiederholen, es sei denn, sie wurde geändert. 2. Die Anforderungsparameter sind fehlerhaft. |
| 401 |
Die aktuelle Anfrage benötigt eine Benutzer-Authentifizierung. Diese Antwort muss einen passenden WWW-Authenticate-Header enthalten, um Benutzerinformationen abzufragen. Der Client kann eine weitere Anfrage mit einem gültigen Authorization-Header senden. Wenn die aktuelle Anfrage bereits ein Authorization-Zertifikat enthielt, dann zeigt ein 401-Antwortcode an, dass der Server die Zertifikate abgelehnt hat. Wenn die 401-Antwort den gleichen Authentifizierungsanfrage-Header wie die vorherige Rückmeldung enthält und der Browser mindestens einmal versucht hat, die Authentifizierung durchzuführen, sollte der Browser dem Benutzer die Informationen in der Antwort anzeigen, da diese möglicherweise relevante Diagnoseninformationen enthält. Siehe RFC 2617. |
| 402 |
Dieser Statuscode ist für zukünftige mögliche Anforderungen reserviert. |
| 403 |
Der Server hat die Anfrage verstanden, lehnt jedoch die Ausführung ab. Im Gegensatz zur 401-Antwort kann die Authentifizierung hier nichts erreichen, und die Anfrage sollte nicht erneut gesendet werden. Wenn dies keine HEAD-Anfrage ist und der Server erklären möchte, warum die Anfrage nicht ausgeführt werden kann, sollte der Grund im Entitätskörper dargelegt werden. Der Server kann auch eine 404-Antwort zurückgeben, wenn er keine Informationen an den Client weitergeben will. |
| 404 |
Die Anfrage ist fehlgeschlagen, die gewünschte Ressource konnte nicht auf dem Server gefunden werden. Es kann keine Information hinzugefügt werden, die dem Benutzer sagt, ob dies vorübergehend oder dauerhaft ist. Wenn der Server sich des Sachverhalts bewusst ist, kann er den Status 410 verwenden, um zu melden, dass die alte Ressource aufgrund mancher interner Zuordnungsmechanismen dauerhaft nicht mehr verfügbar ist und dass es keine Adresse gibt, auf die umgeleitet werden kann. Der Status 404 wird weithin verwendet, wenn der Server nicht offenlegen möchte, warum eine Anfrage abgelehnt wurde oder wenn keine geeigneten Rückmeldungen vorhanden sind. |
| 405 |
Die gewählte Anfrage-Methode kann nicht zum Anfordern der entsprechenden Ressource verwendet werden. Diese Antwort muss einen Allow-Header zurückgeben, um eine Liste der aktuellen Anfrage-Methoden anzugeben, die für die Ressource akzeptabel sind. Da PUT und DELETE-Methoden Schreiboperationen auf Ressourcen auf dem Server durchführen, unterstützen die meisten Webserver diese Anfrage-Methoden standardmäßig nicht oder möglicherweise nicht. Solche Anforderungen führen normal zu einem 405-Fehler. |
| 406 |
Die Eigenschaften des Inhalts der angeforderten Ressource erfüllen nicht die Anforderungen an den Anfrage-Header und können somit kein Entitätsmaß liefern. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte diese Antwort einen Körper zurückgeben, der eine Liste der gewünschten entitätsmerkmale und Adressen enthält, die den Benutzern oder Browsern zur Verfügung stehen, um das geeignetste Entitätsmerkmal auszuwählen. Die Form des Körpers wird durch den im Content-Type-Header angegebenen Medientyp bestimmt. Der Browser kann die beste Auswahl auf Grundlage des Formats und seiner eigenen Fähigkeiten treffen, aber es gibt keinen Standard in der Spezifikation, nach dem eine solch automatisierte Auswahl getroffen werden kann. |
| 407 |
Ähnlich wie die 401-Antwort, jedoch muss der Client sich bei einem Proxy authentifizieren. Der Proxy-Server muss ein Proxy-Authenticate zurückgeben, um zu authentifizieren. Der Client kann seinen Proxy-Authorization-Header zur Authentifizierung zurückgeben. Siehe RFC 2617. |
| 408 |
Die Anfrage hat Zeitüberschreitung. Der Client hat nicht innerhalb der vorbereiteten Wartezeit des Servers eine Anfrage gesendet. Die Anfrage kann jederzeit ohne Änderungen erneut eingereicht werden. |
| 409 |
Die Anfrage kann aufgrund eines Konflikts mit dem aktuellen Status der angeforderten Ressource nicht abgeschlossen werden. Dieser Code darf nur in einer Situation verwendet werden, in der der Benutzer denkt, dass er den Konflikt lösen kann, und er eine neue Anfrage stellen kann. Diese Antwort sollte ausreichende Informationen enthalten, um den Benutzer die Quelle des Konflikts finden zu lassen. Konflikte treten häufig bei der Verarbeitung von PUT-Anfragen auf. Beispielsweise sollte eine 409-Antwort gegeben werden, wenn die Version einer PUT-Anfrage zur Änderung spezifischer Inhalte mit der Version eines vorhergehenden (Dritten)-Anforderungsanliegens in Konflikt steht. Es ist wahrscheinlich, dass die Antwort im Entitätskörper einen Vergleich zwischen den unterschiedlichen Versionen anzeigt, um dem Benutzer zu ermöglichen, die vermischte neue Version erneut einzureichen. |
| 410 |
Die angeforderte Ressource ist auf dem Server nicht mehr verfügbar, und es gibt keine bekannten Weiterleitungsadressen. Diese Situation sollte als dauerhaft angesehen werden. Wenn möglich, sollten Clients mit Links-Bearbeitungsfunktionen alle Verweise auf diese Adresse mit Genehmigung des Benutzers entfernen. Wenn der Server nicht weiß oder nicht sicher ist, ob diese Situation dauerhaft ist, sollte der Status 404 verwendet werden. Sofern nicht anders angegeben, ist diese Antwort speicherbar. Der Zweck der 410-Antwort besteht hauptsächlich darin, Website-Besitzern bei der Wartung ihrer Website zu helfen und den Benutzern mitzuteilen, dass diese Ressource nicht mehr verfügbar ist, und dass dem Server-Besitzer unabhängige Verbindungen zu dieser Ressource gelöscht werden sollen. Solche Ereignisse sind in zeitlich begrenzten, erweiterten Dienstleistungen sehr verbreitet. Die 410-Antwort wird auch verwendet, um dem Client zu melden, dass eine Ressource, die ursprünglich einer bestimmten Person gehörte, unangekündigt nicht mehr verfügbar ist. Natürlich liegt es ganz am Serverbesitzer, ob alle dauerhaft ungenutzten Ressourcen als '410 Gone' gekennzeichnet werden sollen und wie lange dieses Symbol erhalten bleibt. |
| 411 |
Der Server verweigert die Annahme der Anfrage, wenn kein Content-Length-Header definiert ist. Der Client kann die Anfrage erneut stellen, nachdem ein gültiger Content-Length-Header, der die Länge des Anforderungskörpers angibt, hinzugefügt wurde. |
| 412 |
Der Server hat bei der Überprüfung der in den Anfragekopfzeilen angegebenen Bedingungen eines oder mehrere Bedingungen nicht erfüllt. Dieser Statuscode erlaubt es dem Client, Bedingungen in den Anfragekopfzeilen festzulegen, um zu verhindern, dass die Anforderung auf Ressourcen angewendet wird, die nicht gewünscht sind. |
| 413 |
Der Server weigert sich, die aktuelle Anfrage zu verarbeiten, weil die übergebene Entität die Größe überschreitet, die der Server bereit ist oder in der Lage ist, zu verarbeiten. In diesem Fall kann der Server die Verbindung schließen, um zu verhindern, dass der Client die Anfrage weiterhin sendet. Wenn diese Situation vorübergehend ist, sollte der Server einen Retry-After-Header zurückgeben, um dem Client mitzuteilen, wann er es erneut versuchen kann. |
| 414 |
Die angeforderte URI ist länger als die vom Server interpretierbare Länge, daher verweigert der Server die Bereitstellung von Diensten für diese Anfrage. Dies ist selten; typische Fälle sind: Formulare, die POST verwenden sollten, wurden zu GET mit einer zu langen Abfragezeichenfolge (Query String). Umleitungs-URIs führen zu einem "Schwarzen Loch", wenn jede Umleitung die alte URI als Teil der neuen URI verwendet, was dazu führt, dass die URI nach mehreren Umleitungen überlang wird. Der Client versucht, Sicherheitsanfälligkeiten in bestimmten Servern auszunutzen. Diese Server verwenden feste Größen für Pufferspeicher, um die URI des Anforderungs-URI zu lesen oder zu verarbeiten; wenn die nach dem GET-Parameter eine bestimmte Zahl überschreitet, kann dies zu einem Pufferüberlauf kommen, was zu einer Ausführung beliebigen Codes führen kann[1]. Server ohne solche Anfälligkeiten sollten den Statuscode 414 zurückgeben. |
| 415 |
Die im Anfrage-Körper übergebene Entität ist nicht das Format, das vom Server für die aktuelle Anfrage-Methode und -Ressource unterstützt wird, sodass die Anfrage abgelehnt wird. |
| 416 |
Wenn die Anfrage einen Range-Header enthält und jeder im Range angegebene Datenbereich nicht mit dem verfügbaren Bereich im aktuellen Server übereinstimmt und die Anfrage keinen If-Range-Header festlegt, sollte der Server den Statuscode 416 zurückgeben. Wenn der Range in Byte angegeben wird, bedeutet dies, dass die Startbyteposition aller vom Client angeforderten Datenbereiche die Länge des aktuellen Ressourceninhalts überschreitet. Der Server sollte auch bei der Rückgabe des Statuscodes 416 einen Content-Range-Header hinzufügen, um die Länge des aktuellen Inhalts anzugeben. Diese Antwort sollte auch multipart/byteranges nicht als Content-Type verwenden. |
| 417 |
Der im Anfrage-Header din sao Erwartungsinhalt kann vom Server nicht erfüllt werden, oder dieser Server ist ein Proxy, dies hat offensichtlich eine Meinung, dass der Erwartungsinhalt an der nächsten Stelle im Routing nicht erfüllt werden kann. |
| 421 |
Die Anzahl an Verbindungen vom aktuellen Clientstandort zur Serveradresse übersteigt die vom Server erlaubte Obergrenze. In der Regel bezieht sich die IP-Adresse hier auf die Adresse des Clients, die vom Server wahrgenommen wird (zum Beispiel das Gateway oder die Proxy-Serveradresse). In diesem Fall kann es sein, dass die Berechnung der Verbindungen nicht nur ein Endbenutzer berücksichtigt. |
| 422 |
Das Anfrageformat ist korrekt, kann jedoch aufgrund einer semantischen Fehler nicht beantwortet werden. (RFC 4918 WebDAV) 423 Locked die aktuelle Ressource ist gesperrt. (RFC 4918 WebDAV) |
| 424 |
Die aktuelle Anfrage ist aufgrund eines Fehlers der vorhergehenden Anfrage fehlgeschlagen, z.B. aufgrund von PROPPATCH. (RFC 4918 WebDAV) |
| 425 |
Definiert im Entwurf der WebDav Advanced Collections, taucht jedoch nicht im "WebDAV Sequential Collection Protocol" (RFC 3658) auf. |
| 426 |
Der Client sollte auf TLS/1.0 wechseln. (RFC 2817) |
| 449 |
Erweiterung durch Microsoft, bedeutet, dass der Anforderung nach dem Abschluss der geeigneten Operation wiederholt werden sollte. |
| 500 |
Der Server ist auf ein unerwartetes Problem gestoßen, das ihn daran hindert, die Anfrage zu verarbeiten. Diese belastende Situation tritt normalerweise auf, wenn ein Fehler im Servercode auftritt. |
| 501 |
Der Server unterstützt eine benötigte Funktion für die aktuelle Anfrage nicht. Wenn der Server die Anfrage nicht erkennt und auch keine Unterstützung für deren Ressourceneinwilligungen hat. |
| 502 |
Ein Server, der als Gateway oder Proxy fungiert, erhielt von einem vorhergehenden Server eine nicht gültige Antwort, als er die Anfrage ausführen wollte. |
| 503 |
Der Server kann aufgrund vorübergehender Wartungsarbeiten oder Überlastung keine Anfrage verarbeiten. Dieser Zustand ist vorübergehend und wird in naher Zukunft wiederhergestellt. Wenn eine Verzögerung erwartet wird, kann die Antwort einen Retry-After-Header enthalten, um die Verzögerung anzugeben. Wenn diese Retry-After-Information nicht angegeben ist, sollten die Clients diese Antwort wie eine 500-Antwort verarbeiten. Hinweis: Es bedeutet nicht, dass der Server diese Nummer unbedingt verwenden muss, wenn er überladen ist. Einige Server möchten lediglich die Verbindung des Clients abweisen. |
| 504 |
Ein Server, der als Gateway oder Proxy fungiert, hat eine Antwort nicht rechtzeitig von einem vorhergehenden Server (URI-angegebene Server, z.B. HTTP, FTP, LDAP) oder einem Hilfsserver (z.B. DNS) empfangen, als er versuchte, die Anfrage auszuführen. Hinweis: Einige Proxy-Server geben möglicherweise einen 400 oder 500 Fehler zurück, wenn DNS-Anfragen außerhalb der Zeitüberschreitung ablaufen. |
| 505 |
Der Server unterstützt das im Antrag verwendete HTTP-Protokoll nicht oder hat sich geweigert, es zu unterstützen. Dies deutet an, dass der Server nicht bereit oder bereit ist, dasselbe Protokoll zu verwenden, das der Client verwendet. Die Antwort sollte einen Inhalt enthalten, der beschreibt, warum das Protokoll nicht unterstützt wird und welche Protokolle vom Server unterstützt werden. |
| 506 |
Erweiterung durch das "Transparent Content Negotiation Protocol" (RFC 2295), bedeutet, dass der Server ein internes Konfigurationsproblem hat: Die angeforderte Verhandlungsressource wurde konfiguriert, um sich selbst in transparenter Inhaltsverhandlung zu verwenden und ist daher kein geeigneter Schwerpunkt in einem Verhandlungsprozess. |
| 507 |
Der Server kann die notwendigen Inhalte zum Abschluss der Anfrage nicht speichern. Diese Situation wird als vorübergehend betrachtet. WebDAV (RFC 4918) |
| 509 |
Der Server hat das Bandbreitenlimit erreicht. Dies ist kein offizieller Statuscode, wird aber dennoch weit verbreitet. |
| 510 |
Die für den Zugriff auf die Ressource benötigte Richtlinie wurde nicht erfüllt. (RFC 2774) |