HTTP-Statuscode-Funktion

Die Funktion des HTTP-Statuscodes besteht darin, dass der Webserver ihn verwendet, um dem Client mitzuteilen, was passiert ist.

Der Statuscode befindet sich in der ersten Zeile der HTTP-Antwort und gibt einen „dreistelligen Statuscode“ und eine „Statusmeldung“ zurück. Der „dreistellige Statuscode“ ist für das Programm einfacher zu verarbeiten und die „Statusmeldung“ ist für Menschen einfacher zu verstehen.

Statuscode-Klassifizierung

HTTP-Statuscodes sind in fünf Kategorien unterteilt. Die aktuell von uns verwendete HTTP-Protokollversion ist 1.1 und die folgenden Statuscodes werden unterstützt. Mit der Weiterentwicklung des Protokolls werden in der HTTP-Spezifikation weitere Statuscodes definiert.

Tipps: Wenn Sie den Statuscode 518 sehen, wissen Sie nicht, was 518 konkret bedeutet. Zu diesem Zeitpunkt müssen Sie nur wissen, dass 518 zu (5XX, Serverfehler reicht)

Definierter Bereich Kategorie

1XX 100-101 Informationsaufforderung

2XX 200 gehört -206 Erfolg

3XX 300-305 Weiterleitung

4XX 400-415 Clientfehler

5XX 500-505 Serverfehler

Allgemeine Statuscodes

Die meisten Menschen müssen nur die folgenden allgemeinen Statuscodes kennen. Wenn Sie mehr wissen möchten, lesen Sie bitte weiter.

200 OK Der Server hat die Anfrage erfolgreich verarbeitet (das sehen wir am häufigsten)

301/302 Permanent verschoben (Umleitung) Die angeforderte URL wurde verschoben. Die Antwort sollte eine Standort-URL enthalten, die den aktuellen Standort der Ressource angibt

304 Nicht geändert (unverändert) Die zwischengespeicherte Ressource des Clients ist die neueste, sodass der Client den Cache verwenden muss

404 Nicht Gefundene Ressource nicht gefunden

501 Interner Serverfehler Der Server ist auf einen Fehler gestoßen, der die Bearbeitung der Anfrage verhindert hat

1xx-Nachricht

Diese Art von Statuscode bedeutet, dass die Anfrage erfüllt ist wurde angenommen, die Bearbeitung muss fortgesetzt werden. Bei diesem Antworttyp handelt es sich um eine temporäre Antwort, die nur eine Statuszeile und einige optionale Antwortheaderinformationen enthält und mit einer Leerzeile endet. Da im HTTP/1.0-Protokoll keine 1xx-Statuscodes definiert sind, ist es Servern untersagt, 1xx-Antworten an solche Clients zu senden, außer unter bestimmten experimentellen Bedingungen. Die durch diese Statuscodes dargestellten Antworten dienen der Information und weisen auf zusätzliche Maßnahmen hin, die der Client ergreifen sollte.

100 Weiter Der Kunde sollte weiterhin Anfragen senden. Diese vorläufige Antwort wird verwendet, um den Client darüber zu informieren, dass ein Teil seiner Anfrage vom Server empfangen und noch nicht abgelehnt wurde. Der Client SOLLTE den Rest der Anfrage weiter senden oder diese Antwort ignorieren, wenn die Anfrage bereits abgeschlossen wurde. Der Server muss nach Abschluss der Anfrage eine endgültige Antwort an den Client senden. 101 Switching-Protokolle (Switching-Protokoll) Der Server hat die Anfrage des Clients verstanden und benachrichtigt den Client über den Upgrade-Nachrichtenheader, ein anderes Protokoll zum Abschließen der Anfrage zu verwenden. Nach dem Senden der letzten Leerzeile dieser Antwort wechselt der Server zu den im Upgrade-Header definierten Protokollen. Solche Maßnahmen sollten nur dann ergriffen werden, wenn die Umstellung auf ein neues Protokoll vorteilhafter ist. Beispielsweise hat der Wechsel zu einer neuen HTTP-Version Vorteile gegenüber einer älteren Version oder der Wechsel zu einem Echtzeit- und synchronen Protokoll, um Ressourcen bereitzustellen, die solche Funktionen nutzen. 102 Processing ist ein durch WebDAV (RFC 2518) erweiterter Statuscode, der angibt, dass die Verarbeitung fortgesetzt wird.

2xx Success

Diese Art von Statuscode bedeutet, dass die Anfrage erfolgreich vom Server empfangen, verstanden und akzeptiert wurde.

200 OK (Erfolg) Die Anfrage war erfolgreich und der von der Anfrage erwartete Antwortheader oder Datenkörper wird mit dieser Antwort zurückgegeben. 201 Die erstellte (erstellte) Anfrage wurde implementiert und eine neue Ressource wurde gemäß den Anforderungen der Anfrage erstellt und ihr URI wurde mit den Standort-Header-Informationen zurückgegeben. Wenn die erforderlichen Ressourcen nicht rechtzeitig erstellt werden können, sollte „202 Akzeptiert“ zurückgegeben werden. 202 Akzeptiert Der Server hat die Anfrage angenommen, aber noch nicht verarbeitet. Ebenso wie der Antrag abgelehnt werden kann, kann es sein, dass der Antrag letztendlich ausgeführt wird oder auch nicht. Bei asynchronen Vorgängen gibt es keinen bequemeren Weg, als diesen Statuscode zu senden. Der Zweck der Rückgabe einer 202-Statuscode-Antwort besteht darin, dem Server zu ermöglichen, Anforderungen von anderen Prozessen (z. B. einem Batch-basierten Vorgang, der nur einmal am Tag ausgeführt wird) anzunehmen, ohne dass der Client bis zum Batch-Vorgang mit dem Server verbunden bleiben muss ist abgeschlossen. Eine Antwort, die die Anforderungsverarbeitung akzeptiert und einen 202-Statuscode zurückgibt, sollte in der zurückgegebenen Entität einige Informationen enthalten, die den aktuellen Status der Verarbeitung angeben, sowie einen Zeiger auf einen Verarbeitungsstatusmonitor oder eine Statusvorhersage, damit der Benutzer abschätzen kann, ob der Vorgang ausgeführt wird ist abgeschlossen. 203 Nicht autoritative Informationen (nicht autorisierte Informationen) Der Server hat die Anfrage erfolgreich verarbeitet, aber die zurückgegebenen Entitätsheader-Metainformationen sind kein festgelegter Satz, der auf dem ursprünglichen Server gültig ist, sondern eine Kopie von einem lokalen oder Drittanbieter. Die aktuellen Informationen können eine Teilmenge oder eine Obermenge der Originalversion sein. Wenn beispielsweise Metadaten für eine Ressource enthalten sind, kann dies dazu führen, dass der Ursprungsserver eine Obermenge der Metainformationen kennt. Die Verwendung dieses Statuscodes ist nicht erforderlich und nur dann sinnvoll, wenn die Antwort ohne diesen Statuscode 200 OK zurückgegeben hätte. 204 Kein Inhalt Der Server hat die Anfrage erfolgreich verarbeitet, muss jedoch keinen Entitätsinhalt zurückgeben und möchte aktualisierte Metainformationen zurückgeben. Die Antwort kann neue oder aktualisierte Metainformationen in Form von Entitätsheadern zurückgeben. Diese Header sollten, sofern vorhanden, den angeforderten Variablen entsprechen. Wenn der Client ein Browser ist, SOLLTE der Browser des Benutzers die Seite, für die die Anforderung gestellt wurde, ohne Änderungen an der Dokumentansicht beibehalten, selbst wenn neue oder aktualisierte Metainformationen gemäß der Spezifikation „Dokument in Ansicht“ auf die Browseraktivität des Benutzers angewendet werden sollen. Da eine 204-Antwort keinen Nachrichtentext enthalten darf, endet sie immer mit der ersten leeren Zeile nach dem Nachrichtenkopf. 205 Inhalt zurücksetzen Der Server hat die Anfrage erfolgreich verarbeitet und keinen Inhalt 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 wird hauptsächlich verwendet, um das Formular unmittelbar nach der Annahme einer Benutzereingabe zurückzusetzen, damit der Benutzer problemlos eine andere Eingabe starten kann. Wie die 204-Antwort darf diese Antwort keinen Nachrichtentext enthalten und endet mit der ersten Leerzeile nach dem Nachrichtenkopf. 206 Teilinhalt (Teilinhalt) Der Server hat eine teilweise GET-Anfrage erfolgreich verarbeitet. HTTP-Download-Tools wie FlashGet oder Thunder verwenden diese Art von Reaktion, um unterbrochene Downloads fortzusetzen oder ein großes Dokument in mehrere Download-Segmente aufzuteilen, um es gleichzeitig herunterzuladen. Die Anfrage muss einen Range-Header enthalten, um den Inhaltsbereich anzugeben, den der Client erwartet, und kann einen If-Range als Anfragebedingung enthalten. Die Antwort muss die folgenden Header-Felder enthalten:

Content-Range wird verwendet, um den Bereich des in dieser Antwort zurückgegebenen Inhalts anzugeben, wenn der Content-Type „multipart/byteranges“ ist Beim Herunterladen mehrerer Teile sollte jeder mehrteilige Teil das Feld „Content-Range“ enthalten, um den Inhaltsbereich dieses Teils anzugeben. Wenn eine Content-Length in der Antwort enthalten ist, muss ihr Wert mit der tatsächlichen Anzahl von Bytes im zurückgegebenen Inhaltsbereich übereinstimmen.

Datum

ETag und/oder Content-Location, wenn dieselbe Anfrage eine 200-Antwort hätte zurückgeben sollen.

Läuft ab, Cache-Kontrolle und/oder variiert, wenn sich sein Wert möglicherweise von dem Wert unterscheidet, der anderen vorherigen Antworten auf dieselbe Variable entspricht.

Wenn diese Antwortanforderung die starke If-Range-Cache-Überprüfung verwendet, sollte diese Antwort keine anderen Entitätsheader enthalten. Wenn diese Antwortanforderung die schwache If-Range-Cache-Überprüfung verwendet, darf diese Antwort keine anderen Entitätsheader enthalten ; Dadurch werden Inkonsistenzen zwischen zwischengespeicherten Entitätsinhalten und aktualisierten Entitätsheaderinformationen vermieden. Andernfalls sollte diese Antwort alle Entitätsheaderfelder enthalten, die in einer 200-Antwort zurückgegeben werden sollen. Wenn der ETag- oder Last-Modified-Header nicht genau übereinstimmt, sollte der Client-Cache den von der 206-Antwort zurückgegebenen Inhalt nicht mit zuvor zwischengespeicherten Inhalten kombinieren. Jedem Cache, der Range- und Content-Range-Header nicht unterstützt, ist das Zwischenspeichern von Inhalten, die von einer 206-Antwort zurückgegeben werden, untersagt. 207 Multi-Status ist ein von WebDAV (RFC 2518) erweiterter Statuscode, der bedeutet, dass der nachfolgende Nachrichtentext eine XML-Nachricht ist und je nach Anzahl der vorherigen Unteranfragen eine Reihe unabhängiger Antwortcodes enthalten kann.

3xx-Weiterleitung

Diese Art von Statuscode zeigt an, dass der Kunde weitere Maßnahmen ergreifen muss, um die Anfrage abzuschließen. Normalerweise werden diese Statuscodes für die Umleitung verwendet und die nachfolgende Anforderungsadresse (Umleitungsziel) wird im Feld „Standort“ dieser Antwort angegeben.

Nur ​​wenn die von der Folgeanforderung verwendete Methode GET oder HEAD ist, kann der Browser des Benutzers die erforderliche Folgeanforderung automatisch ohne Benutzereingriff senden. Clients sollten Endlosschleifenumleitungen automatisch erkennen (z. B. A→B→C→...→A oder A→A), da dies zu einem unnötigen Ressourcenverbrauch auf dem Server und Client führt. Wie in der HTTP/1.0-Spezifikation empfohlen, sollten Browser nicht automatisch auf mehr als 5 Weiterleitungen zugreifen.

300 Multiple Choices Die angeforderte Ressource verfügt über eine Reihe alternativer Antworten, jede mit ihrer eigenen spezifischen 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 mit einer Liste von Ressourcenattributen und Adressen enthalten, aus der der Benutzer oder Browser die am besten geeignete Weiterleitungsadresse auswählen kann. Das Format dieser Entität wird durch das durch 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. Natürlich gibt die RFC 2616-Spezifikation nicht an, wie eine solche automatische Auswahl durchgeführt werden soll. Wenn der Server selbst bereits über eine bevorzugte Feedback-Auswahl verfügt, sollte der URI dieses Feedbacks in „Location“ angegeben werden; der Browser kann diesen Location-Wert als Adresse für die automatische Umleitung verwenden. Darüber hinaus ist diese Antwort zwischenspeicherbar, sofern nicht anders angegeben. 301 Permanent verschoben Die angeforderte Ressource wurde dauerhaft an einen neuen Speicherort verschoben und alle zukünftigen Verweise auf diese Ressource sollten einen von mehreren in dieser Antwort zurückgegebenen URIs verwenden. Wenn möglich, sollten Clients mit Linkbearbeitungsfunktionen die angeforderte Adresse automatisch in die vom Server zurückgegebene Adresse ändern. Sofern nicht anders angegeben, ist diese Antwort auch zwischenspeicherbar. 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, verbietet der Browser die automatische Weiterleitung, sofern dies nicht vom Benutzer bestätigt wird, da sich die Bedingungen der Anfrage entsprechend ändern können. Hinweis: Bei einigen Browsern, die das HTTP/1.0-Protokoll verwenden, wird die nachfolgende Umleitungsanforderung zu einer GET-Methode, wenn die von ihnen gesendete POST-Anfrage eine 301-Antwort erhält. 302 Gefunden (vorübergehend verschoben) Die angeforderte Ressource wird jetzt vorübergehend von einem anderen URI bereitgestellt. Da solche Weiterleitungen temporär sind, sollte der Client künftige Anfragen weiterhin an die ursprüngliche Adresse senden. Diese Antwort kann nur zwischengespeichert werden, wenn sie in „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, verbietet der Browser die automatische Weiterleitung, sofern dies nicht vom Benutzer bestätigt wird, da sich die Bedingungen der Anfrage entsprechend ändern können. Hinweis: Obwohl die Spezifikationen RFC 1945 und RFC 2068 es dem Client nicht erlauben, die Anforderungsmethode bei der Umleitung zu ändern, betrachten viele bestehende Browser die 302-Antwort als 303-Antwort und verwenden unabhängig davon die GET-Methode, um auf den im Standort angegebenen URI zuzugreifen of Die Methode der ursprünglichen Anfrage. Die Statuscodes 303 und 307 wurden hinzugefügt, um zu verdeutlichen, welche Antwort der Server vom Client erwartet. 303 See Other Die Antwort auf die aktuelle Anfrage 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 Umleitung der skriptaktivierten POST-Anforderungsausgabe an eine neue Ressource zu ermöglichen. Dieser neue URI ist kein Ersatzverweis auf die ursprüngliche Ressource. Gleichzeitig ist es verboten, 303-Antworten zwischenzuspeichern. Natürlich könnte die zweite Anfrage (Weiterleitung) zwischengespeichert werden. 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 verstehen den 303-Status nicht richtig. Wenn Sie die Interaktion mit diesen Browsern in Betracht ziehen müssen, sollte der Statuscode 302 ausreichen, da die meisten Browser 302-Antworten genau so verarbeiten, wie die obige Spezifikation vom Client verlangt, 303-Antworten zu verarbeiten. 304 Not Modified (nicht geändert) Wenn der Client eine bedingte GET-Anfrage sendet und die Anfrage zulässig ist, sich der Inhalt des Dokuments jedoch nicht geändert hat (seit dem letzten Zugriff oder gemäß den Bedingungen der Anfrage), sollte der Server dies zurückgeben Statuscode. Eine 304-Antwort darf keinen Nachrichtentext enthalten und endet daher immer mit der ersten Leerzeile nach dem Nachrichtenkopf. Die Antwort muss die folgenden Header-Informationen enthalten:

Datum, es sei denn, der Server verfügt nicht über eine Uhr. Wenn auch Server ohne Uhren diese Regeln einhalten, können Proxyserver und Clients das Datumsfeld selbst zu den empfangenen Antwortheadern hinzufügen (wie in RFC 2068 angegeben), und der Caching-Mechanismus funktioniert normal.

ETag und/oder Content-Location, wenn dieselbe Anfrage eine 200-Antwort hätte zurückgeben sollen.

Läuft ab, Cache-Kontrolle und/oder variiert, wenn sich sein Wert möglicherweise von dem Wert unterscheidet, der anderen vorherigen Antworten derselben Variablen entspricht.

Wenn diese Antwortanforderung eine starke Cache-Überprüfung verwendet, sollte diese Antwort keine anderen Entitätsheader enthalten. Andernfalls darf diese Antwort keine anderen Entitätsheader enthalten (z. B. verwendet eine bedingte GET-Anfrage eine schwache Cache-Überprüfung). Dadurch werden Inkonsistenzen zwischen zwischengespeicherten Entitätsinhalten und aktualisierten Entitätsheaderinformationen vermieden. Wenn eine 304-Antwort darauf hinweist, dass eine Entität derzeit nicht zwischengespeichert ist, muss das Caching-System die Antwort ignorieren und die Anfrage ohne Einschränkung wiederholen. Wenn eine 304-Antwort empfangen wird, die eine Aktualisierung eines Cache-Eintrags erfordert, muss das Cache-System den gesamten Eintrag aktualisieren, um die Werte aller Felder widerzuspiegeln, die in der Antwort aktualisiert wurden. 305 Proxy verwenden Auf die angeforderte Ressource muss über den angegebenen Proxy zugegriffen werden. Die URI-Informationen des angegebenen Proxys werden im Feld Standort angegeben. Der Empfänger muss wiederholt eine separate Anfrage senden, um über diesen Proxy auf die entsprechenden Ressourcen zuzugreifen. Nur der Ursprungsserver kann eine 305-Antwort erstellen. Hinweis: Aus RFC 2068 geht nicht klar hervor, dass eine 305-Antwort dazu gedacht ist, eine einzelne Anfrage umzuleiten, und dass sie nur vom Ursprungsserver erstellt werden kann. Die Nichtbeachtung dieser Einschränkungen kann schwerwiegende Folgen für die Sicherheit haben. 306 Switch Proxy In der neuesten Version der Spezifikation wird der Statuscode 306 nicht mehr verwendet. 307 Temporäre Umleitung Die angeforderte Ressource antwortet nun vorübergehend auf Anfragen von einem anderen URI. Da solche Weiterleitungen temporär sind, sollte der Client künftige Anfragen weiterhin an die ursprüngliche Adresse senden. Diese Antwort kann nur zwischengespeichert werden, wenn sie in „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. Da einige Browser die 307-Antwort nicht erkennen können, müssen die oben genannten notwendigen Informationen hinzugefügt werden, damit Benutzer den neuen URI verstehen und Zugriffsanfragen an ihn stellen können. Wenn es sich nicht um eine GET- oder HEAD-Anfrage handelt, verbietet der Browser die automatische Weiterleitung, sofern dies nicht vom Benutzer bestätigt wird, da sich die Bedingungen der Anfrage entsprechend ändern können.

4xx-Client-Fehler

Diese Art von Statuscode bedeutet, dass möglicherweise ein Fehler auf dem Client aufgetreten ist, der die Verarbeitung des Servers behindert. Sofern es sich bei der Antwort nicht um eine HEAD-Anfrage handelt, SOLLTE der Server eine Entität zurückgeben, die den aktuellen Fehlerzustand erläutert und angibt, ob dieser vorübergehend oder dauerhaft ist. Diese Statuscodes gelten für jede Anforderungsmethode. Browser sollten dem Benutzer alle in solchen Fehlerantworten enthaltenen Entitätsinhalte anzeigen.

Wenn der Client Daten überträgt, wenn der Fehler auftritt, sollten Serverimplementierungen, die TCP verwenden, sorgfältig sicherstellen, dass der Client das Paket mit der Fehlermeldung empfangen hat, bevor die Verbindung zwischen Client und Server geschlossen wird. Wenn der Client nach Erhalt der Fehlermeldung weiterhin Daten an den Server sendet, sendet der TCP-Stack des Servers ein Reset-Paket an den Client, um alle nicht erkannten Eingabepuffer des Clients zu löschen und zu verhindern, dass diese Daten vom Server gelesen werden und stört letzteres.

400 Bad Request (Bad Request) Die aktuelle Anfrage kann vom Server nicht verstanden werden, da sie Syntaxfehler enthält. Der Client sollte diese Anfrage nicht erneut senden, es sei denn, sie wurde geändert. 401 Nicht autorisiert (Unauthorized) Die aktuelle Anfrage erfordert eine Benutzerüberprüfung. Die Antwort MUSS einen WWW-Authenticate-Header enthalten, der für die angeforderte Ressource geeignet ist und nach Benutzerinformationen fragt. Der Client kann wiederholt eine Anfrage senden, die die entsprechenden Autorisierungsheaderinformationen enthält. Wenn die aktuelle Anfrage bereits Autorisierungszertifikate enthält, weist die 401-Antwort darauf hin, dass die Serverüberprüfung diese Zertifikate abgelehnt hat. Wenn die 401-Antwort dieselbe Authentifizierungsabfrage 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, da diese Entitätsinformationen möglicherweise relevante Diagnoseinformationen enthalten. Siehe RFC 2617. 402 Zahlung erforderlich Dieser Statuscode ist für mögliche zukünftige Anforderungen reserviert. 403 Verboten Der Server hat die Anfrage verstanden, weigerte sich jedoch, 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 erklären möchte, warum die Anfrage nicht ausgeführt werden kann, 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 Nicht gefunden (Not Found) Die Anfrage ist fehlgeschlagen und die angeforderte Ressource wurde auf dem Server nicht gefunden. Es gibt keine Informationen darüber, ob der Zustand vorübergehend oder dauerhaft ist. Wenn der Server die Situation kennt, sollte er den Statuscode 410 verwenden, um ihn darüber zu informieren, dass die alte Ressource aufgrund einiger Probleme mit dem internen Konfigurationsmechanismus dauerhaft nicht verfügbar ist und keine Sprungadresse vorhanden ist. Der Statuscode 404 wird häufig verwendet, wenn der Server nicht preisgeben möchte, warum die Anfrage abgelehnt wurde oder keine andere geeignete Antwort verfügbar ist. 405 Methode nicht zulässig (Methode deaktiviert) Die in der Anforderungszeile angegebene Anforderungsmethode kann nicht zum Anfordern der entsprechenden Ressource verwendet werden. Die Antwort muss eine Allow-Header-Information zurückgeben, um die Liste der Anforderungsmethoden anzugeben, die die aktuelle Ressource akzeptieren kann. Da die PUT- und DELETE-Methoden Ressourcen auf den Server schreiben, unterstützen die meisten Webserver die oben genannten Anforderungsmethoden in der Standardkonfiguration nicht oder erlauben sie nicht, und für solche Anforderungen wird ein 405-Fehler zurückgegeben. 406 Nicht akzeptabel (Nicht akzeptabel) Die Inhaltsmerkmale der angeforderten Ressource können die Bedingungen im Anforderungsheader nicht erfüllen, sodass die Antwortentität nicht generiert werden kann. 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 denen der Benutzer oder Browser die am besten geeigneten 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 seinen Funktionen seine eigene beste Wahl treffen. Die Spezifikation definiert jedoch keine Kriterien für die Durchführung einer solchen automatischen Auswahl. 407 Proxy Authentication Required ähnelt der 401-Antwort, außer dass sich der Client beim Proxyserver authentifizieren muss. Der Proxyserver muss zur Identitätsabfrage ein Proxy-Authenticate zurückgeben. Der Client kann zur Überprüfung einen Proxy-Authorization-Header zurückgeben. Siehe RFC 2617. 408 Request Timeout Request Timeout. Der Client hat das Senden einer Anfrage nicht innerhalb der Zeit abgeschlossen, die der Server warten wollte. Der Kunde kann diesen Antrag jederzeit erneut stellen, ohne dass Änderungen erforderlich sind. 409 Konflikt Die Anfrage kann aufgrund eines Konflikts mit dem aktuellen Status der angeforderten Ressource nicht abgeschlossen werden. Dieser Code sollte nur verwendet werden, wenn davon ausgegangen wird, dass der Benutzer den Konflikt lösen und eine neue Anfrage erneut einreichen kann. Die Antwort sollte genügend Informationen enthalten, damit der Benutzer die Ursache des Konflikts ermitteln kann. Bei der Verarbeitung von PUT-Anfragen kommt es in der Regel zu Konflikten. Wenn beispielsweise in einer Umgebung mit Versionsprüfung die Versionsinformationen, die an eine von einem PUT übermittelte Änderungsanforderung für eine bestimmte Ressource angehängt sind, mit einer vorherigen Anforderung (von einem Drittanbieter) in Konflikt stehen, sollte der Server zu diesem Zeitpunkt einen 409-Fehler zurückgeben. Informieren Sie den Benutzer darüber, dass die Anfrage nicht abgeschlossen werden kann. Zu diesem Zeitpunkt enthält die Antwortentität wahrscheinlich einen Differenzvergleich zwischen den beiden widersprüchlichen Versionen, sodass der Benutzer die neue Version nach dem Zusammenführen erneut einreichen kann. 410 Gone (Deleted) Die angeforderte Ressource ist auf dem Server nicht mehr verfügbar und hat keine bekannte Weiterleitungsadresse. Eine solche Situation sollte als dauerhaft angesehen werden. Wenn möglich, sollten Clients mit Linkbearbeitungsfunktionen alle Verweise auf diese Adresse mit Zustimmung des Benutzers entfernen. Wenn der Server nicht weiß oder nicht feststellen kann, ob der Zustand dauerhaft ist, sollte der Statuscode 404 verwendet werden. Sofern nicht anders angegeben, ist diese Antwort zwischenspeicherbar. Der Zweck der 410-Antwort besteht hauptsächlich darin, Website-Administratoren bei der Wartung der Website zu helfen, Benutzer darüber zu informieren, dass die Ressource nicht mehr verfügbar ist, und der Serverbesitzer hofft, dass auch alle Remote-Verbindungen gelöscht werden, die auf diese Ressource verweisen. Diese Art von Vorfall kommt häufig bei zeitlich begrenzten Mehrwertdiensten vor. In ähnlicher Weise wird die 410-Antwort auch verwendet, um den Client darüber zu informieren, dass Ressourcen, die ursprünglich einer Person gehörten, auf dem aktuellen Serverstandort nicht mehr verfügbar sind.Natürlich liegt es ganz beim Serverbesitzer, ob alle dauerhaft nicht verfügbaren Ressourcen mit „410 Gone“ gekennzeichnet werden müssen und wie lange er diese Markierung behalten muss. 411 Länge erforderlich (gültige Länge erforderlich) Der Server weigert sich, die Anfrage anzunehmen, ohne den Content-Length-Header zu definieren. Nach dem Hinzufügen eines gültigen Content-Length-Headers, der die Länge des Anforderungsnachrichtentexts angibt, kann der Client die Anforderung erneut senden. 412 Vorbedingung fehlgeschlagen Der Server konnte bei der Validierung eine oder mehrere der in den Header-Feldern der Anfrage angegebenen Vorbedingungen nicht erfüllen. Mit diesem Statuscode kann der Client beim Abrufen der Ressource Vorbedingungen in den Anforderungsmetainformationen (Anfrage-Header-Felddaten) festlegen und so verhindern, dass die Anforderungsmethode anders als erwartet auf die Ressource angewendet wird. 413 Anforderungsentität zu groß (Anforderungsentität zu groß) Der Server weigert sich, die aktuelle Anforderung zu verarbeiten, da die Größe der von der Anforderung übermittelten Entitätsdaten den Bereich überschreitet, den der Server verarbeiten möchte oder kann. In diesem Fall kann der Server die Verbindung schließen, um zu verhindern, dass der Client diese Anfrage weiterhin sendet. Wenn die Situation vorübergehend ist, sollte der Server einen Retry-After-Antwortheader zurückgeben, um den Client darüber zu informieren, wie viel Zeit später er es erneut versuchen kann. 414 Request-URI Too Long (Der angeforderte URI ist zu lang) Die Länge des angeforderten URI überschreitet die Länge, die der Server interpretieren kann, sodass der Server die Bearbeitung der Anfrage verweigert. Dies kommt relativ selten vor:

Formularübermittlung, die die POST-Methode verwenden sollte, wird zur GET-Methode, was dazu führt, dass die Abfragezeichenfolge (Abfragezeichenfolge) zu lang ist.

Umleitungs-URI „Schwarzes Loch“, zum Beispiel verwendet jede Umleitung den alten URI als Teil des neuen URI, was nach mehreren Umleitungen zu einem überlangen URI führt.

Der Client versucht, den Server anzugreifen, indem er eine Sicherheitslücke ausnutzt, die in einigen Servern besteht. Dieser Servertyp verwendet einen Puffer fester Länge, um den angeforderten URI zu lesen oder zu betreiben. Wenn die Parameter nach GET einen bestimmten Wert überschreiten, kann es zu einem Pufferüberlauf kommen, der zur Ausführung beliebigen Codes führt [1]. Server ohne solche Schwachstellen sollten den Statuscode 414 zurückgeben.

415 Nicht unterstützter Medientyp (Nicht unterstützter Medientyp) Für die aktuelle Anforderungsmethode und die angeforderte Ressource liegt die in der Anforderung übermittelte Entität nicht in einem vom Server unterstützten Format vor, sodass die Anforderung abgelehnt wird. 416 Angeforderter Bereich nicht erfüllt (Der angeforderte Bereich erfüllt nicht die Anforderungen) Wenn die Anforderung den Bereichsanforderungsheader enthält und ein im Bereich angegebener Datenbereich nicht mit dem verfügbaren Bereich der aktuellen Ressource und der If-Range-Anforderung übereinstimmt Wenn der Header in der Anfrage nicht definiert ist, sollte der Server den Statuscode 416 zurückgeben. Wenn Range einen Bytebereich verwendet, bedeutet diese Situation, dass die erste Byteposition aller in der Anforderung angegebenen Datenbereiche die Länge der aktuellen Ressource überschreitet. Der Server sollte außerdem einen Content-Range-Entitätsheader enthalten, um die Länge der aktuellen Ressource anzugeben und gleichzeitig den Statuscode 416 zurückzugeben. Es ist dieser Antwort auch untersagt, multipart/byteranges als Inhaltstyp zu verwenden. 417 Erwartung fehlgeschlagen (Erwartung nicht erfüllt) Der im Anforderungsheader Expect angegebene erwartete Inhalt kann vom Server nicht erfüllt werden, oder der Server ist ein Proxyserver und es gibt offensichtliche Hinweise darauf, dass der Inhalt von Expect auf dem nächsten Knoten des nicht erfüllt werden kann aktuelle Route erfüllen. 418 I'm a teapot Dieser Opcode wurde 1998 von der IETF als traditioneller Aprilscherz im RFC 2324 Hypertext Coffee Pot Control Protocol definiert und muss nicht auf einem echten HTTP-Server definiert werden. 421 Es gibt zu viele Verbindungen von Ihrer Internetadresse. Die Anzahl der Verbindungen von der IP-Adresse des aktuellen Clients zum Server überschreitet den maximal zulässigen Bereich des Servers. Normalerweise bezieht sich die IP-Adresse hier auf die Client-Adresse, die vom Server aus gesehen wird (z. B. die Gateway- oder Proxy-Server-Adresse des Benutzers). In diesem Fall kann die Anzahl der Verbindungen mehr als einen Endbenutzer umfassen. 422 Nicht verarbeitbare Entität Das Anforderungsformat ist korrekt, es kann jedoch aufgrund semantischer Fehler nicht geantwortet werden. (RFC 4918 WebDAV) 423 GesperrtDie aktuelle Ressource ist gesperrt. (RFC 4918 WebDAV) 424 Failed Dependency Die aktuelle Anfrage ist aufgrund eines Fehlers in einer vorherigen Anfrage, z. B. PROPPATCH, fehlgeschlagen. (RFC 4918 WebDAV) 425 Unordered Collection ist im WebDav Advanced Collections-Entwurf definiert, erscheint jedoch nicht im „WebDAV Sequential Collection Protocol“ (RFC 3658). 426 Upgrade erforderlich Der Client sollte auf TLS/1.0 wechseln. (RFC 2817) 449 Retry With wird von Microsoft erweitert und gibt an, dass die Anforderung nach der Durchführung der entsprechenden Vorgänge erneut versucht werden sollte.

5xx-Serverfehler

Diese Art von Statuscode zeigt an, dass der Server einen Fehler oder einen abnormalen Zustand bei der Verarbeitung der Anfrage hat. Es kann auch sein, dass der Server erkennt, dass er nicht abgeschlossen werden kann die Anfrage mit den aktuellen Software- und Hardwareressourcen. Sofern es sich nicht um eine HEAD-Anfrage handelt, SOLLTE der Server eine Erläuterung des aktuellen Fehlerstatus und der Angabe, ob der Zustand vorübergehend oder dauerhaft ist, enthalten. Der Browser SOLLTE dem Benutzer alle Entitäten anzeigen, die in der aktuellen Antwort enthalten sind.

Diese Statuscodes gelten für jede Antwortmethode.

500 Interner Serverfehler Der Server ist auf einen unerwarteten Zustand gestoßen, der den Abschluss der Verarbeitung der Anfrage verhindert hat. Im Allgemeinen tritt dieses Problem auf, wenn im Programmcode des Servers ein Fehler vorliegt. 501 Nicht implementiert (noch nicht implementiert) Der Server unterstützt eine für die aktuelle Anfrage erforderliche Funktion nicht. Wenn der Server die angeforderte Methode nicht erkennt und seine Anforderung für keine Ressource unterstützen kann. 502 Bad Gateway Ein Server, der als Gateway oder Proxy fungiert, hat beim Versuch, eine Anfrage auszuführen, eine ungültige Antwort vom Upstream-Server erhalten. 503 Dienst nicht verfügbar (Dienst nicht verfügbar) Aufgrund vorübergehender Serverwartung oder Überlastung ist der Server derzeit nicht in der Lage, die Anfrage zu verarbeiten. Dieser Zustand ist vorübergehend und wird nach einiger Zeit wiederhergestellt. Wenn die Verzögerungszeit zu erwarten ist, kann die Antwort einen Retry-After-Header enthalten, um die Verzögerungszeit anzugeben. Wenn diese Retry-After-Nachricht nicht gegeben wird, SOLLTE der Client sie genauso behandeln wie eine 500-Antwort. 504 Gateway-Timeout (Gateway-Timeout) Wenn ein Server, der als Gateway oder Proxy fungiert, versucht, eine Anfrage auszuführen, erhält er nicht rechtzeitig eine Antwort vom Upstream-Server (dem durch den URI identifizierten Server, z. B. HTTP, FTP, LDAP). oder der Hilfsserver (z. B. DNS). Hinweis: Einige Proxyserver geben einen 400- oder 500-Fehler zurück, wenn die DNS-Abfrage das Zeitlimit überschreitet. 505 HTTP-Version nicht unterstützt Der Server unterstützt die in der Anfrage verwendete HTTP-Version nicht oder verweigert die Unterstützung. Dies bedeutet, dass der Server nicht in der Lage oder nicht bereit ist, dieselbe 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 Variant Also Negotiates wird durch das Transparent Content Negotiation Protocol (RFC 2295) erweitert und stellt einen internen Konfigurationsfehler im Server dar: Die angeforderte Verhandlungsvariablenressource ist so konfiguriert, dass sie sich selbst in der transparenten Inhaltsverhandlung verwendet, und ist daher kein geeigneter Verhandlungsprozess Fokus. 507 Unzureichender Speicher Der Server kann den zum Abschließen der Anforderung erforderlichen Inhalt nicht speichern. Dieser Zustand gilt als vorübergehend. (WebDAV RFC 4918) 509 Bandbreitenlimit überschritten Der Server hat sein Bandbreitenlimit erreicht. Dies ist kein offizieller Statuscode, wird aber dennoch häufig verwendet. 510 Nicht erweitert Die zum Abrufen der Ressource erforderliche Richtlinie wird nicht erfüllt. (RFC 2774)