Jedes Mal, wenn ein Task auf einem überwachten Gerät ausgeführt wird, gibt der Zielserver HTTP-Statuscodes zurück, um den Status der Antwort vom Server anzuzeigen.

Diese HTTP-Statuscodes oder Netzwerkfehlercodeswerden in den Ergebnissen einer Überwachungssitzung sowie in Warnungsbenachrichtigungen angezeigt. Diese Statuscodes werden von der Internet Assigned Numbers Authority (IANA) verwaltet und die aktuellste Liste der Codes finden Sie hier.

Mithilfe von Filtern können Sie Ergebnisse mit bestimmten Statuscodes aus Ihren Aufgaben, Warnungen und Berichten entfernen. Klicken Sie auf die RFC-Referenzdokumente in der Liste unten, um alle Details zu den Statuscodes zu erhalten.

 

What istdas HTTP-Protokoll?

Jedes Mal, wenn ein Benutzer eine Website besucht, stellt er eine Anfrage von seinem Browser/Client an einen Server, der mit den angeforderten Ressourcen antwortet. . Diese Anforderungen folgen alle dem HTTP-Standard (Hypertext Transfer Protocol). Die HTTP Protokoll, das technisch Teil der Anwendungsschicht innerhalb der Internet Protocol Suiteist, ist nur viele Protokolleunterder IP-Suite. Die Das HTTP-Protokoll ist das Rückgrat des Internets, das für die Kommunikation und das Senden von Daten zwischen Clients und Servern verwendet wird. Einige der anderen gebräuchlicheren Internetprotokolle Sie haben viele begegnet sind, sind die folgenden:

 

Anwendungsschichtprotokolle

das Anwendung laTer gibt die Protokolle und Schnittstellenmethoden an, die von Clients und Server. Es Ist die Schicht whier die Interaktion zwischen Person und Computer erfolgt Eined Informationen kann von einem Server hin und her gesendet werden über einen Client/Browser und interpretiert und für die Benutzer angezeigt werden.

  • DNS: Das DNS-Protokoll(Domain Name System) konvertiert Domänennamen in für den Browser lesbare IP-Adressen, damit Ressourcen geladen werden können.
  • FTP: Das FTP-Protokoll (FileTransfer Protocol) wird verwendet, um Dateien zwischen einem Browser und einem Server überein Computernetzwerk zu übertragen.
  • SMTP: Das SMTP-Protokoll (SimpleMail Transfer Protocol) wird verwendet, um einend-Adresse-E-Mails zwischen Absendern und Empfängern in einem Netzwerk zu senden.
  • TLS/SSL: Das SSL-Protokoll (SecureSockets Layer) wurde offiziell im Jahr 2015 veraltet. TLS(Transport Layer Security) wurde an seiner Stelle eingeführt, um eine sichere Möglichkeit zur Kommunikation über ein Netzwerk zu bieten.
  • IMAP: Das IMAP-Protokoll (Internet Message Access Protocol) wird Nachrichten von einem E-Mail-Server zu verwalten und zu empfangen. Im Gegensatz zu SMTP können Sie das IMAP-Protokoll nicht zum Senden von E-Mail-Nachrichten verwenden.
  • POP: Das POP-Protokoll (Post Office Protocol) ist wie IMAP, aber der Unterschied ist, dass das POP-Protokoll dem Benutzer erlaubt, Nachrichten von einem E-Mail-Server zu empfangen, die Nachricht wird dann jedoch vom E-Mail-Server gelöscht. Das IMAP-Protokoll kann Nachrichten über mehrere Geräte hinweg synchronisieren. Es hängt wirklich davon ab, wie Benutzer auf ihre E-Mails zugreifen sollen.
  • SIP: Di SIP(SessionInitiation Protocol) Protokoll ist ein Signalprotokoll, das in Echtzeit-Sprach- Video- und Messaginganwendungen. SIP ist das Protokoll, das wird verwendet, um VoIP zu aktivieren undzu de ploy (Voice Over Internet Protocol) Dienstleistungen. Sip wird auch in Verbindung mit anderen Protokollen wie SDP (Session Description Protocol), UDP, TCP und TLS verwendet, um Sitzungsdaten und Medien zu übertragen.

 

Transport-Layer-Protokolle

Die Transportschicht übernimmt die Datenübertragung, die auch TCP und UDP umfasst Protokolleund die Sicherstellung, dass Daten korrekt und zeitnahgesendet und empfangenwerden.

  • Tcp: Das TCP-Protokoll (Transport Control Protocol) wird verwendet, um sicherzustellen, dass die Übertragungen zwischen einem Client und einem Server sicher sind. und dass die die gesamte Kommunikation wurde verarbeitet. Zum Beispiel Wenn ein Server sendet eine Datei aufgrund einer Clientanforderung zurück, die HTTP-Schicht kommuniziert mit der Transportschicht, um die Datei angefordert. Das TCP-Protokoll verwaltet den Prozess der Montage und des Sendens (und manchmal auch erneut senden, falls erforderlich) Datenpakete und stellt sicher, dass alle Pakete wurden gesendet und zugestellt.
  • UDP: Das UDP-Protokoll (User Datagram Protocol) ermöglicht es Anwendungen, Nachrichten, so genannte Datagramme, an andere Hosts in einem Netzwerk zu senden.

 

Internet-Layer-Protokolle

Die Internetschicht, auch Netzwerkebene genannt, hat die Aufgabe, Netzwerkp-Ackets auf die effizienteste Weise zu senden und neu zusammenzubauen, indem Netzwerkadressen/IP-Adressen zum Senden von Paketen an ihr Zielverwendetwerden.

  • IP: Das IP-Protoc ol (Internet Protocol)ist zusammen mitdem TCP-Protokoll eine Reihe von Anforderungen, die definieren, wie Daten über das Internet gesendet werden.
  • ICMP: ICMP (Internet Control Message Protocol) Protokoll ist ein Netzwerkprotokoll, das Netzwerkgeräten, wie Routern, dieDiagnose vonKommunikationsproblemen ermöglicht. Das ICMP-Protokoll befasst sich nicht mit dem Austausch Daten,vielmehr ist es ihr Zweck, ob die Daten das beabsichtigte Ziel erreichen .

 

Link-Layer-Protokolle

Die Link-Schicht ist eineGruppe vonKommunikationsmethoden, die die Übertragung von Daten zwischen physischen Geräten und einem Netzwerkverwalten.

  • ARP: Das ARP-Protokoll (Address Resolution Protocol)-Protokoll/procedure zum Zuordnen von IP-Netzwerkadressen zu einer Adresse eines physischen Hardwaregeräts, auch als MAC-Adresse bezeichnet.
  • MAC: Das MAC-Protokoll (Medium Access Control) stellt Hardwaregeräten ihre eindeutige Identifikationsnummer zur Seite. Es bietet den Netzen die Möglichkeit,ct und kommunizieren mit Geräten.
  • Wi-Fi: Das Wi-Fi-Protokoll (Wireless Fidelity), das eines der Protokolle ist, auf die wir uns alle im Alltag verlassen, ist eine Gruppe von drahtlosen Netzwerkprotokollen, die für die Verbindung mit dem Internetzugang und LANs (Local Area Networks) verwendet wird.

 

Was sind Statuscodes und warum sind sie wichtig?

Es gibt sogar Erweiterungen der HTTP-Protokoll, das inkl. HTTPS (Hypertext Transfer Protocol Secure) und WebDAV (Web-based Distributed Authoring and Versioning), die wir in den HTTP-Statuscodes weiter erläuternwerden Unten. Wenn ein Client eine Anforderung an den Server stellt, informieren Sie Statuscodes darüber, ob die Anforderung erfolgreich, fehlgeschlagen oder etwas anderes war. Statuscodes werden von der Internet Assigned Numbers Authorityoder IANA und enthält Statuscodes der Internet Engineering Task Force (IETF) und der Internet Society (ISOC). Wie im IANA definiert OrganisationThier sind fünf Klassifikationen von HTTP-Status Kabeljaues:

1xx: Informational – Anfrage empfangen, Weiterverlauf
2xx: Erfolg – Die Aktion wurde erfolgreich empfangen, verstanden und angenommen
3xx: Umleitung – Weitere Maßnahmen müssen ergriffen werden, um die Anfrage abzuschließen
4xx: Clientfehler – Die Anforderung enthält eine fehlerhafte Syntax oder kann nicht erfüllt werden
5xx: Serverfehler – Der Server konnte eine scheinbar gültige Anforderung nicht erfüllen

Einzelpersonen und Ingenieure regelmäßig Vorschlagen neue Statuscodes durch Anfragen für Comments (RFC), und die IETF wird überprüfen, zu adoptieren und Zurückziehen Status Codes bei Bedarf.

 

HTTP-Statuscodes erklärt

Die folgenden Informationen bieten einen Überblick über alle gängigen HTTP-Statuscodes sowie die HTTP-Statuscodes, die die meisten Leute selten sehen oder gar wissen, dass sie existieren. Wie wir bereits erwähnt haben, werden viele Antwortcodes nie gesehen von Benutzern, da sie nur innerhalb des Netzwerks sichtbar sind.

Die erste Ziffer des Statuscodes identifiziert die Klasse; die zweiten beiden Ziffern spielen jedoch keine Rolle bei der weiteren Definition des Statuscodes zu einem bestimmten Nachrichten-/Antworttyp. Innerhalb dieser Klassifizierungsgruppen können mehrere Statuscodes vorhanden sein, und einige Gruppen haben mehr Statuscodes als andere. Und während es offiziell über 60 einzigartige Statuscodes gibt, werden die meisten Menschen eine Handvoll oder zwei im Laufe der Zeit begegnen.

Die meisten dieser Statuscodes werden hinter den Kulissen interpretiert und verarbeitet. Sie werden auch sehen, dass es Gruppen von Codes gibt, die als “Nicht zugewiesen” gekennzeichnet sind. Während die meisten Statuscodes, die wir heute sehen, standardisiert wurden und diese nicht zugewiesenen Nummern lassen bei Bedarf Platz für die Erstellung zusätzlicher Statuscodes. Auch wenn einige der nicht zugewiesenen Benutzercodes früher nicht Teil des HTTP-Standards (Hypertext Transfer Protocol) sind, gibt es Unternehmen, die sie als angepasste Serverantwort für Benutzer, sodass Unternehmen Probleme, die Benutzer möglicherweise auftreten, besser beheben können. Klicken Sie auf die RFC-Referenzdokumentlinks in der Liste unten, um alle Details zum jeweiligen HTTP-Statuscode zu erhalten.

 

Eine vollständige Liste und Übersicht der HTTP-Statuscodes

 

1xx Statuscodes: Informational

Die 1XxHTTP-Statuscodes auf Ebene teilen den Benutzern mit, dass die Anforderung, die Sie Haben gemacht wurde erhalten, aber wird noch verarbeitet. Die 1xx-Statuscodes Nicht notwendigerweise bedeuten, dass es ein Problem gibt, Ichs nur da, um Ihnen etwas zu lassen, ist noch im Prozess der Fertigstellung. iinklusive in dieser Gruppe sind nur eine Handvoll von 1Xx Codes, auf die Benutzer stoßen können und müssen sich dessen bewusst sein.

 

100: Weiter

Status code 100 Continue teilt Ihnen mit, dass ein Teil der Anforderung problemlosempfangen wurde. Auf an diesem Punkt ist alles OK, aber ist immer noch in Bearbeitung. Wenn die verbleibenden Teil der Antrag nicht abgelehnt wird,R sendet eine endgültige Antwort, sobald die Anforderung abgeschlossen istEd. Wenn die HTTP-Header abgelehnt wurden, stellt dies sicher, dass der Client Nicht eine Anfrage für die Stelle senden. Wenn die Anforderung jedoch tat kein Headerfeld, dann ignoriert der Browser einfach die bzw.diee. See RFC7231, Abschnitt 6.2.1 für weitere Informationen.

101: Schaltprotokolle

Seit den bescheidenen Anfängen des Internets wurden viele HTTP-Protokolle erstellt.. Die erste dokumentierte Version des HTTP-Protokolls war HTTP 0.9. Die aktuelle Iteration ist HTTP 2.0 oder HTTP/2. Statuscode 101 Schaltprotokolle zeigen an, dass der Server akzeptiert Die Anforderung des Clients, zu einem anderen HTTP-Protokoll zu wechseln über das Feld Upgrade-Header. Wenn ein Browser eine Anforderung für eine Seite stellt, das HTTP-Statuscode 101 und dann der Upgrade-Header,Ch Angibt der sever wechselt zu einer anderen HTTP-Version. Schließlich geht er davon aus,dass der Server nurdann dem Wechsel von Protokollen zustimmen wird, wenn es vorteilhaft ist, z. B. ein Upgrade/Umschalten auf ein neueres Protokoll im Vergleich zu einem älteren. See RFC7231, Abschnitt 6.2.2 für weitere Informationen.

102: Verarbeitung

Ein Status code 102 Die Verarbeitung wird nur mit WebDAV (Web Distributed Authoring and Versioning) verwendet. Die meisten Seiten sind schreibgeschützt. WebDAV ist eine Erweiterung des HTTP Protokoll, das Clients die Möglichkeit gibt, Inhalte aus der Ferne zubearbeiten und Dateien zu übertragen. das Webdav Protokoll erstellt wurde, um Benutzern die Möglichkeit zu geben, Zusammenarbeite zu Dateien mit anderen, mögen Dropbox oder Google Drive. Statuscode 102 ist einN Zwischenantwortcode, der dem Client mitteilt, dass der Server die vollständige Anforderung akzeptiert hat, hat die Anforderung nicht abgeschlossen. Dieser HTTP-Statuscode wird nur durch den Server Wenn Eine Anforderung dauert länger als 20 Sekunden. Siehe RFC2518, Abschnitt 10.2 für weitere Informationen.

103: Frühe Hinweise

Statuscodes 103 Early Hints befindet sich derzeit in der Auswertung/Versuchsphase. Dieser Statuscode wird beim Vorabladen externer Inhalte/Ressourcen verwendet. Das HTTP/2-Protokoll ermöglicht das Pushen von Inhalten, um die So können Webentwickler bestimmte Inhalte übertragen, während sie darauf warten, dass andere externe Ressourcen geladen werden. Dies ist aus der Sicht des Endbenutzers von Vorteil, da minimiert die wahrgenommene Ladezeit. Tsein HTTP-Antwortcode würde Anzugeben zu einem Browser, in dem der Server , um eine endgültige Antwort zu senden,zusammen mit den in der Antwort enthaltenen Kopfzeilenfeldern. See RFC8297, Abschnitt 2 für weitere Informationen

 

104-199: Nicht zugewiesen

Die Statuscodes 104 bis 199 sind derzeit nicht zugewiesen.

 

2xx Statuscode: Erfolg

Die 2xx-Level-HTTP-Statuscodes geben an, dass die Anforderung des Clients vom Server erfolgreich war,wenn sie erfolgreich empfangen undverarbeitetwurde. Im Gegensatz zu 4xx Statuscodes, 2xx Statuscodes sind, was Sie erhalten möchten. Wie 1xx Statuscodes werden die 2xx Statuscodes hinter den Kulissen verarbeitet und selten von Benutzern gesehen,es sei denn, sie verwenden Entwickler- oder SEO-Tools, um alle HTTP-Antworten einer Seite zu sehen.

 

200: OK

Als einer der am häufigsten verwendeten HTTP-Statuscodes wird der Statuscode 200 OK verwendet, um anzugeben, dass eine Anforderung empfangen,verarbeitet und erfolgreich war. Abhängig von der verwendeten Anforderungsmethode (GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE). Wenn es sich bei der Anforderung beispielsweise um eine GET-Anforderung handelt, enthält die Antwort die Ressource. Wenn es Ist eine der anderendie Antwort enthält das Ergebnis der Aktionen. das 200 Status Code ist ein von mehr als 10 anderen Antwortcodes das ist auch zwischenspeicherbar, was bedeutet, dass es gespeichert werden kann und abgerufen über die Client, um keine weitere Anforderung an den Server in die Zukunft. SEe RFC7231, Abschnitt 6.3.1 für weitere Informationen.

201: Erstellt

Ein 201 Erstellter Statuscode ist wie ein 200 OK-Statuscode, Ein 201-Statuscode bedeutet jedoch, dass eine Anforderung erfolgreich verarbeitet wurde und eine Ressource oder Reso-Uren im Prozess zurückgegebenoder erstellt wurde.. pro 201 Statuscode wird in der Regel für PUT-Anforderungen verwendet. Zum Beispiel, Wwird eine PUT-Anforderung verwendet,eine neue Ressource wird auf der URL erstellt in der Anforderung angegeben. Wenn in einer POST-Anforderung ein 201-Statuscode vorhanden ist, bedeutet dies, dass eine Ressource an einem anderen API-Endpunkt/Standort erstellt wurde. See RFC7231, Abschnitt 6.3.2 für weitere Informationen.

202: Angenommen

das 202 Akzeptiert Status code bedeutet, dass der Server einen Antrag auf Bearbeitung erhalten hat, und es Ichs akzeptiert, aber die Anfrage hat Nicht abgeschlossen wurde. Es tut auch Nicht bedeutet, dass der Antrag schließlich angenommen wird, da er hängt davon ab, wann die eigentliche Verarbeitung stattfindet. Diese Art von Anforderung wird in der Regel in APIs angezeigt. wobei ein Batch-Prozess einmal täglich ausgeführt wird. Seit dort Ist keine Möglichkeit für HTTP, nach einem Anfrage erfolgreich oder die Verbindung des Benutzers wurde geschlossenkann eine API eine E-Mail an einen Benutzer senden notifying Sie dass der Prozess erfolgreich war. SEe RFC7231, S-Ektion 6.3.3 für weitere Informationen.

203: Nicht autoritative Informationen

Der Statuscode 203 Nicht autorisierender Informationen wird in der Regel von einem HTTP-Proxy oder Drittanbieter. Der Proxy, der zwischen Client und Server sitzt kann die Antworten ändern, bevor sie den Client erreichen. An Anzugeben dass sich während der wird ein Statuscode 203 verwendet. Der Nachteil dieser Methode besteht jedoch darin, dass Es Ichs nicht möglich zu wissen, was der ursprüngliche Statuscode war wenn ein Proxy etwas in der Antwort geändert hat. Eine vorgeschlagene Problemumgehung ist, Verwenden eines Warnungsheaders zusammen mit einem 214 Status Code die verwendet wird An e darauf hinweisen, dass eine Änderung oder Änderung desonse. Verwenden der wArning-Header ermöglicht es dem ursprünglichen Statuscode, passed through. See RFC7231, Section6.3.4 für weitere Informationen.

204: Kein Inhalt

Ein Statuscode von 204 Keine Inhalte Angibt dass die Antwort erfolgreich vom Server übermittelt und erfüllt wurde und keine weiterenist in den Text der Antwort zu senden. Als Beispiel: Wenn die Anforderung im Formular auf einer Seite gesendet wird,nse gesendet wird, wird der Kunde/browser soll die Ansicht nicht ändern, d. h. das Formular sollte Nicht erfrischt oder direkt Benutzer zu einem neuen PagE. Nein zusätzliche Inhalte sollten ersetzt oder aus der Perspektive des Benutzers angezeigt werden. See RFC7231, Section6.3.5 für weitere Informationen.

205: Zurücksetzen von Inhalten

Wie der Status 204 No Content code, ein Statuscode 205 Zurücksetzen von Inhalten gibt an, dass der Server die Anforderung erfolgreich gesendet hat und vom Benutzer-Agent verlangt, dass die Ansicht auf seine oderi aktualisiert/zurückgesetzt wirdGinalzustand. Wenn wir das Beispiel eines Formulars auf einer Seite verwenden, vervollständigt und Senden Siedas Formular, sollte derClient/Browser das Formular wieder in den ursprünglichen Zustand löschen, damit ein Benutzer seineAktion furt. pro 205 Statuscode geht davon aus, dass keine weiteren Inhalte bereitgestellt werden. See RFC7231, Abschnitt 6.3.6 für weitere Informationen.

206: Teilinhalt

A 206 Partieller Inhaltsstatuscode kann für eine Vielzahl von Anforderungen verwendet werden und Angibt dass der Server hat eine Teilweise Anforderung für eine Ressource. Wenn z. B. ein Client nur nach einem bestimmten Teil, oder Bereich, von Eine Bestimmten Ressource oder Seite. Ein weiteres Beispiel dafür, wo ein 206 Status Code verwendet wird, ist im Video. Ein Client darf nur Video in Stücken, um nicht warten zu müssen, bis das Video gepuffert oder geladen wird, um eine negative Benutzererfahrung zu vermeiden, bei der ein Benutzer länger warten müsste bevor das Video abgespielt wird. Dies ist eine normale bewährte Methode unter HTTP-Videoplayernum Bandbreite und wahrgenommene Latenzprobleme zu vermeiden. See RFC7233, Abschnitt 4.1 für weitere Informationen.

207: Multi-Status

das 207 Multi-Status Status code Bietet Status für mehrere unabhängige Prozesse webDAV-Server. Die Standardnachricht/Antwort ist eine Text-/XML-Nachricht. Es Angibt dass mehrere Vorgänge stattgefunden haben und dass der Status für jeden Vorgang im Körper desonse. Statuscodes können zwischen einer der fünf Kategorien variieren. Antwortcodes variieren je nach Anzahl der Unteranforderungen. Im Gegensatz zu anderen 200 Status-Codes, ein 207-Statuscode bestätigen, dass der Prozess erfolgreich war. Der Client muss den Text jeder Anforderung festzustellen, ob es erfolgreich war oder nicht. See RFC4918, Abschnitt 11.1 für weitere Informationen.

208: Bereits gemeldet

das 208 Bereits gemeldet Status Code ist ein weiterer Statuscode, der in der WebDAV-Erweiterung verwendet wird. mögen das 207 Status Code, es ermöglicht es einem Client/Browser, Anzugeben auf den Server, den ein Ressource wurde bereits verarbeitet. Wenn ein Client nach Ressourcen fragt, kann es sein, dass eine Antwort doppelte Ressourcen enthält., was bedeuten würde, dass dieselben Ressourcen mehrmals gesendet würden, was redundant ist. das 208 Statusantwort vermeidet die Möglichkeit der Verarbeitung und Wiederholung die gleiche Antwort. 208 Statuscode Antworten wird nur im Antwortkörper und niemals als tatsächliche HTTP-Antwort angezeigt. See RFC5842, Abschnitt 7.1 für weitere Informationen.

209-225: Nicht zugewiesen

Die Statuscodes 209 bis 225 sind derzeit nicht zugewiesen.

226: IM Gebraucht

Ein 226 IM (Instanzmanipulationen) Verwendeter Statuscode wird verwendet, um anzugeben, dass ein Server eine GET-Anforderung für eine Ressource abgeschlossen hat, die Antwort jedoch eine oder mehrere Instanzmanipulationen ist, die auf die aktuelle Instanz angewendet wurden. Innerhalb des HTTP-Protokolls gibt es eine Erweiterung namens Delta-Codierung in HTTP, die auf der Serverseite unterstützt wird. Wenn dies implemkann der Client Änderungen an der zwischengespeicherten Version anfordern, und der Server sendet die Änderungen, anstatt die gesamtere-Quelle erneutzusenden. Um diese Funktion implementieren zu können, muss die Client/Browser-Anforderung geben Sie an, welcher IM-Typ unterstützt wurde. Wenn der Server auch diese Funktion unterstützt, antwortet er mit dem 226 Statuscode und die Veränderungen. Wenn ein 200 Statuscode wird zurückgesendet, was darauf hinweist, dass das Feature nicht unterstützt wird. See RFC3229, Abschnitt 10.4.1 für weitere Informationen.

227-299: Nicht zugewiesen

Die Statuscodes 227 bis 299 sind derzeit nicht zugewiesen.

 

3xx: Umleitung

Die 3xx Statuscodes werden bei URL-Umleitung verwendet. Websites ändern sich ständig und entwickeln sich ständig weiter, so dass es Zeiten geben kann,in denen MarKeter Benutzer zu einer aktualisierten oder anderen Seite leiten müssen. Umleitungen helfen, Benutzer von der Suche nach dem, was sie suchen und warten zu lindern Ihr Ranking in Suchmaschinen. Die Umleitungsaktionen können vom Browser automatisch durchgeführt werden oder zusätzliche Interaktion von Benutzern erfordern. Die 3xx HTTP Statuscodes sind entscheidend für SEO (Search Engine Optimization) und User Experience, sowie den Suchmaschinen mitteilen, welche Inhalte sie crawlen und indizieren sollen. Ichf nicht ordnungsgemäß umgesetzt, Benutzer können an einen unbeabsichtigten Ort weitergeleitet werden,was zueinem 4xx-Statuscode führen und SEO-Qualitätsbewertungen beeinflussen könnte.

 

300: Mehrere Auswahlmöglichkeiten

Der Statuscode 300 Multiple Choices gibt an, dass ein Resource verschoben wurdeund an mehrere Standorte. In diesem Fall wird der Benutzer muss entscheiden, welche Ressource verwendet werdensoll. Der Server kann Anzugeben eine bevorzugte Wahl und die sollte Angegeben in der Kopfzeile Feld wenn der Benutzer-Agent automatisch zur bevorzugten Auswahl umleiten kann. Im praktischen Gebrauch wird tsein Statuscode wird selten verwendet, da es keine standardisierte Möglichkeit gibt, aus mehreren Antworten auszuwählen. SEe RFC7231, Abschnitt 6.4.1 für weitere Informationen.

301: Dauerhaft verschoben

Ein 301 Moved Permanently Statuscode wird verwendet, um anzugeben, dass eine Zielressource an einen permanenten Speicherort verschoben wurde. Der Statuscode 301 weist den Browser/Client an, diesen neuen Speicherort oder diese URL in Zukunft im Header zu verwenden.. Zusammen mit der 301 Status Code wird die neue URL Gegeben in der Antwort sowie alle URLs in der Vorherigen standorts), zusammen mit der Aktualisierung auf die neue URL. SEe RFC7231, Abschnitt 6.4.2 für weitere Informationen.

302: Gefunden

Ein 302 Gefundener Statuscode gibt einem Client/Browser an, dass eine Ressource, auf die sie zugreifen, vorübergehend befindet sich unter einem anderen Ort. Im Gegensatz zum Statuscode 301 302 Statuscode zeigt eine temporäre Verschiebungan, sodass der Client Automatisch seine Links zum neuen Standort, wie auch hier, es Ichs zeitweilige. Ein Beispiel dafür, wo die 302-Status Code sollte verwendet werden, wenn Sind Mehrere Urls, aber sie könnte in verschiedenen Sprachen. Ein Benutzer kann zu einer bestimmten URL gelangen, aber der Client kann sie umleiten automatisch auf die richtige Seite basierend auf ihren Browsereinstellungen und verwenden Sie diese on nachfolgende Besuche. Es is beachten Sie, dass Browser in einigen Fällen eine Anforderung von POST in GET ändern können. Für den Fall, dass diese Maßnahme nicht begünstigt,sollteein 307 Statuscode verwendet werden. WeitereInformationen finden Sie unter See RFC7231, Abschnitt 6.4.3.

303: Siehe Sonstiges

Ein Statuscode 303 Siehe Andere gibt an, dass ein Server die Client/Browser zu einer anderen Ressource. Die Ressource wird als URL angegeben, das Headerfeld. Im Gegensatz zu den Statuscodes 301 und 302 Nicht bedeuten, dass eine Ressource tempora hatRioder dauerhaft bewegen,s beabsichtigt, die Url wohin die Antwort auf die specifIchC Anfrage kann Gefunden über eine GET-Anfrage. 303 Statuscodes sollten Nicht zwischengespeichert werden, jedoch die Antwort auf die Nachfolgend Anforderung kann zwischengespeichert werden. Eine typische Verwendung der 303 Status Code wäre, um sicherzustellen, dass benutzero nicht versehentlich erneut einreichen Formulardaten über eine POST-Anforderung. Sie sollten auf eine neue Seite weitergeleitet werden. Ist dies nicht der Fall, können sie unwissentlich auf die Zurück-Schaltfläche in ihrem Browser, die sie bitten kann, erneut einzureichen, was zu unne dupliziertee-Einreichungen. See RFC7231, Abschnitt 6.4.4 für weitere Informationen.

304: Nicht geändert

Statuscode von 304 Nicht geändert wird als Antwort auf eine bedingte GET- oder HEAD-Anforderung gesendet. Clients/Browser können eine bedingte Anforderungsenden, z. B. If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since, oder If-Range, die Frage, ob eine bestimmte Ressource geändert wurde seit einem bestimmten Datum/Uhrzeit. das Ist nur, wenn der Client zuvor auf die Ressource zugegriffen, heruntergeladen und gespeichert hat. Wenn es Seit dem letzten Zugriff auf das Datum/die Uhrzeit geändert wurde, gibt der Server einen Statuscode 200 OK zurück. Wenn es Nicht seit diesem Datum/dieser Uhrzeit geändert wurde, 304 Status Code wird gesendet als Antwort, Anzeige dass die gespeicherte Ressource bereitgestellt werden sollte, da sie Nicht Worden Geändert seit dem letzten Zugriff. SEe RFC7232, Abschnitt 4.1 für weitere Informationen.

305: Proxy verwenden

Der 305 Proxy-Statuscode is ein veralteter Statuscode, der aus Sicherheitsgründen nicht mehr verwendet wird . Es wurde verwendet, um einem Client zu indicate, dass auf die resource, auf die sie zugegriffen haben, über einen Proxy zugegriffen werden muss. Weitere Informationen zum Statuscode 305 Proxy verwenden finden Sie unter RFC7231, Abschnitt 6.4.5

306: Nicht verwendet

Wie der Statuscode 305 wird auch der Status 306 Nicht verwendet war ursprünglich als Switch Proxy bekannt. das 306 Statuscode wurde in einem früheren Spezifikation. Seine Absicht war es, wie in Hinweis an den Client, dass nachfolgende Requests an eine Ressource den angegebenen Proxy verwenden sollten. Dies wurde als Sicherheitsproblem betrachtet, so dass es nicht mehr verwendet wird. Weitere Informationen zum Statuscode 306 nicht verwendet finden Sie unter RFC7231, Abschnitt 6.4.6

307: Vorübergehende Umleitung

mögen der 302 Gefundene UmleitungsstatuscodeTer 307 Temporäre Umleitung Status code Angibt dem Client/Browser, dass eine Ressource oder ein Dokument an einem anderenTemporäre URL und gibt diese URL zurück. Da die Umleitung temporär ist und sich ändern könnte, Der Browser/Client sollte weiterhin auf die aktuelle URL für Nachfolgend Anforderungen. Der Hauptunterschied zwischen den 302-Status Code und die 307-Status Code ist, dass die 307-Status Code lässt keine Änderung von Anforderungen von Eine Bereitstellen Anfrage an eine Erhalten Anfrage, wenn der Client die POST-Anforderung angefordert hat, wird sie umgeleitet und Initiieren die POST-Anforderung erneut. SEe RFC7231, Abschnitt 6.4.7

308: Permanente Umleitung

Ein 308 Permanent Redirect Statuscode ist ein zwischengespeicherter Statuscode (es sei denn, Cache-Steuerelemente sind implementiert), der angibt, dass sich eine Zielressource jetzt an einer permanenten URL befindet und subsequent Anforderungen sollten auch an diese URL gerichtet werden. Darüber hinaus sollte der Client alle alte Lesezeichen an den neuen Standort. Der Statuscode 308 ist dem Statuscode 301 sehr ähnlich, jedoch muss der Initiieren und senden Sie dieselbe Anforderung am Zielspeicherort. pro 301 Statuscode tut nicht müssen dies tun. Die meisten Browser/Clients ändern die POST-Anforderung in einen GET-Request. See RFC7238, Abschnitt 3 für weitere Informationen.

 

309-399: Nicht zugewiesen

Die Statuscodes 309 bis 399 sind derzeit nicht zugewiesen.

 

4xx: Clientfehler

Die Klassifizierung mit den meisten HTTP-Statuscodes, 4xx HTTP-Statuscodes sind nicht das, was Ihre Benutzer sehen sollen. Jeder Statuscode, der mit einer 4 beginnt, bedeutet, dass es ein Problem mit dem Client gibt. 4xx Statuscodes werden in der Regel generiert, wenn eine Seite gelöscht und nicht umgeleitet wurde, oder etwas falsch in einer URL oder einem Link eingegeben wurde. Wenn Benutzer einen gefürchteten 4xx-Statuscode erhalten, bedeutet das, dass es ein Problem gibt mit dem Client/Browser, der Informationen vom Server empfängt. Diese sind Fehler, die Benutzer auf ihrem Bildschirm sehen und eine negative Benutzererfahrung zu schaffen,was zu ein wenig Frustration und suchen woanders. Wenn Suchmaschinen Beispielsweise Ihre Website durchforsten und einen 404-Fehler erhalten, wird dies als Fehler im Bericht angezeigt. pro wenige 404 Fehler sind in Ordnung und Suchmaschinen betrachten diese nicht unbedingt als eine negative Sache,aber eine 404, die zu einem 404 umleitet, könnte sich negativ auf Ihre SEO auswirken. Nicht nur, dass, wenn die betreffende Seite verwendet wird, um Verkehr oder Umsatz zu steuern, dies zu Verlusten an potenziellen Einnahmen führen könnte.

 

400: Schlechte Anfrage

A 400 Schlechte Anfrage Fehlerstatuscode bedeutet, dass der Server die Anforderung nicht verarbeiten kann aufgrund eines Problems des Clients. Dies könnte aus einer Vielzahl von Gründen, z. B. eine Datei, die zu groß ist, schlechte Syntax, eine ungültige URL oder ein anderes Problem ca,das von einer Drittanbieteranwendungverwendet wird, weshalb der 400-Statuscode manchmal als Catch-All-Statuscode verwendet wird,auch wenn auf der Serverseite ein Problem auftritt. Dies kann die Fehlerbehebung zu einem 400-Status Code etwas zeitaufwändiger und schwieriger, jedoch zusammen mit der 400 Status Codefehler und Headerinformationen, ter Server kann Zusätzliche Antwort mit Witzh, die angezeigt werden kann, um das Benutzer, um zu helfen Identifizieren und erleichtern Sie die Fehlerbehebung und Diagnose des Fehlers. SEe RFC7231, Abschnitt 6.5.1 für weitere Informationen.

401: Nicht autorisiert

Ein 401 Nicht autorisierter Fehler Statuscode gibt an, dass die Anforderung nicht die entsprechenden Authentifizierungsanmeldeinformationen enthält , authentication fehlgeschlagenist , oder der Benutzer muss sichanmelden. Der Client erfordert eine Authentifizierung vom Server. Die autorisierten und authentifizierten Begriffe werden häufig austauschbar verwendet, sie bedeuten getrennte Dinge. pro Statuscode von 401 ist Stribetroffen mit Authentifizierung. In Fällen, in denen Sie einen Kunden darüber informieren, dass er nicht Überhaupt, dann ein Statuscode von 403 sollte umgesetzt werden. pronach der Spezifikation, das 401-Status Code muss auch die WWW-Authenticate Header vom Server Antwort, Anzeige dem Client, welches Authentifizierungsschema oder welche Methode der Server requires. SEe RFC7235, Abschnitt 3.1 für weitere Informationen.

402: Zahlung erforderlich

Ursprünglichd als Teil einer Möglichkeit erstellen, um potenzielle zukünftige digitale Zahlungsmethoden, der 402 Payment Required-Fehler Statuscode ist offiziell für die zukünftige Verwendung reserviert, aber es verwendet einige begrenzte,aber selten, Situationen. Weitere Informationen zum Fehlercode 402 Payment Required finden Sie unter RFC7231, Abschnitt 6.5.2

403: Verboten

Die 403 Der Statuscode für verbotene Fehler gibt an, dass die Anforderung vom Client verstanden wurde, der Server ihn jedoch nicht autorisiert,sodass der Client darauf zugreifen. Der Server kann die Grund, warum es dieAnforderung innerhalb der Antwortnicht autorisiert, was aus verschiedenen Gründen wie falschem Passwort oder Benutzernamen sein könnte. Im Gegensatz zu den 401-Status Code, der eine Authentifizierung erfordert, 403 Status Code kann Anzugeben dass der Client wirklich keine Autorisierung hat , um auf diese Ressourcen zuzugreifen, so dass die Authentifizierung in diesem Fall Ist Nicht Möglich. SEe RFC7231, Abschnitt 6.5.3 für weitere Informationen.

404: Nicht gefunden

Einer der häufigsten und berüchtigtsten Statuscodes von Benutzern und Entwickler, die 404 Nicht gefunden Fehler Statuscode Angibt dass die Ressource Erforderlich vom Server Nicht vorhanden sind oder not bereit, es dem Kunden zur Verfügung zu stellen. pro 404 Status code wird nicht Anzugeben obE Mangel an Die Bereitstellung der Ressource ist vorübergehend oder dauerhaft, aberder Client kann Subsequent Anfragen stellen, um darauf zuzugreifen. In Fällen, in denen bekannt ist, dass die Ressourcen dauerhaft verschwunden sind, sollte der Statuscode 410 verwendet werden. 404 Statuscodes sind standardmäßig auch zwischengespeichert werden können, es sei denn, andere Cache-Steuerelemente arein place. See RFC7231, Abschnitt 6.5.4 für weitere Informationen.

405: Methode nicht zulässig

Der Fehlerstatuscode 405-Methode nicht zulässig gibt an, dass eine bestimmte vom Client angeforderte Ressource nicht von den Server. Die 405-Methode nicht zulässig ist mögen die 403 Fürbidden Statuscode, jedoch die 403 Status code Angibt dass die Ressource verfügbar sein kannEs Ichs nur, dass der Kunde Nicht über die erforderliche Genehmigung zur Durchführung des Antrags verfügen. Zusammen mit dem Status 405 Method Not Allowed muss der Server Anzugeben das appropriaTe Und Unterstützt Methoden für die Zielressource. Weitere Informationen zum Fehlercode 405-Methode nicht zulässig finden Sie unter RFC7231, Abschnitt 6.5.5

406: Nicht akzeptabel

Wie der Fehlerstatuscode 405-Methode nicht zulässig gibt der Fehlercode 406 Not Acceptable an, dasses keine Unterstützung für eine bestimmte Anforderung gibt. In diesem Fall ter 406 Nicht akzeptabel Statuscode gibt an, dass der Server die Anforderung verstanden hat, die Antwort jedoch nicht vom Client unterstützt oder verstanden werden. Ein Kunde kann Bestimmte Versionen einer Ressource im Header anfordern, z. B. A-IM oder Akzeptieren Sie Sprache, unter anderem, wenn der Server tut Nicht unterstützt wird, antwortet es mit dem Statuscode 406 Not Acceptable. Der Server kann entweder mit einer Liste von geeignete Ressource Identifikatoren, die der Client auswählen kann Von. SEe RFC7231, Abschnitt 6.5.6 für morE Informationen.

407: Proxy-Authentifizierung erforderlich

Die erforderliche 407-Proxyauthentifizierung Fehler status-Code ist mögen der 401 Nicht autorisierte Statuscode, jedoch im Falle einer 407-Status Code um einen Proxy verwenden, muss der Client zuerst authentifiziert werden. Der Proxy muss die Methode für die Authentifizierung zurückgeben. Nicht so häufig heute aufgrund des Aufstiegs von VPNs, Proxys als Vermittler zwischen Nutzern/Clients und dem Internet fungieren, Benutzern schnelleren Zugriff auf Ressourcen ermöglichen, da Der Inhalt Normalerweise Zwischengespeichert, und kann Auch eine Ebene der Sicherheit und Anonymität für die Benutzer bieten. Weitere Informationen zum Fehlercode 407 Proxy Authentication Required finden Sie unter RFC7235, Abschnitt 3.2

408: Anforderungstimeout

Ein 408 Request Timeout-Fehlerstatuscode bedeutet, dass der Server in einem bestimmten Zeitraum keine Anforderung vom Client erhalten hat. Eine verzögerte Anforderung vom Client kann aus einer Vielzahl von Gründen fällig werden, z. B. aus einer langsamen oder unterbrochenen Verbindung. Nach Ablauf dieser Zeit wird der Status 408 Request Timeout vom Server gesendet. und der Benutzer/Client kann die Anforderung erneut senden. Weitere Informationen zum Fehlercode 408 Request Timeout finden Sie unter RFC7231, Abschnitt 6.5.7

409: Konflikt

A 409 Konflikt Fehler Statuscode Angibt dass die Anforderung des Clients noT aufgrund eines Konflikts mit dem Server verarbeitet werden. Die Anfrage des Kunden war in Ordnung, aber es gab Waren Probleme auf der Serverseite, die die Ausführung der Anforderung verhindern. Ein Beispiel hierfür könnte sein, wenn eine Anforderung für eine bestimmte Datei bearbeitet werden sollte, löschend, oder vom Benutzer erstellt, aber diese Funktionen sind nicht zulässig. Zusammen mit der 409-Antwort sollte der Server Anweisungen zurückgeben, wie der Benutzer dieses Problem beheben oder angabee warum das Problem ing auftritt. See RFC7231, Abschnitt 6.5.8 für weitere Informationen.

410: Verschwunden

Wie der 404 Not Found-Fehlerstatuscode, den wir zuvor behandelt haben,gibt derStatuscode 410 Gone an, dass die Ressource, die der Client anfordert, entfernt wurde und vom Server nicht mehr verfügbar ist.. No weitere Informationen werden in Bezug auf die URL-Umleitung oder den Ort zum Zugriff auf die Ressourcebereitgestellt. Es wurde auf unbestimmte Zeit entfernt. Weitere Informationen zum Fehlercode 410 Gone finden Sie unter RFC7231, Abschnitt 6.5.9

411: Länge erforderlich

Der Fehlerstatuscode 411 Length Required gibt an, dass der Server die Anforderung vom Client aufgrund eines vordefinierten Anforderungstexts content length nicht zulässt. Die Anforderung kann vom Client wiederholt werden, wenn in der nachfolgenden Ressourcenanforderung ein gültiger Content-Length-Header angegeben ist. Weitere Informationen zum Fehlercode 411 Length Required finden Sie unter RFC7231, Abschnitt 6.5.10

412: Vorbedingung fehlgeschlagen

Bedingte Anforderungen an den Server sind als Teil des HTTP-Protokolls zulässig. Wenn die rechte Bedingungen in der Anforderung erfüllt sind, wird die Anforderung vom Serverausgeführt undverarbeitet. Ein 412 Precondition Failed Error Statuscode bedeutet, dass eine oder mehrere Bedingungen im Anforderungsheader fehlgeschlagensind. Dies kann z. B. in GET-Anforderungs- and a bedingte Anforderung ist Genutzt An Drehen Sie die Ressource nur dann um, wenn diese Ressource geändert. Weitere Informationen zum Fehlercode 412 Precondition Failed finden Sie unter RFC7232, Abschnitt 4.2

413: Anforderungsentität zu groß

das 413 Anforderungsentität zu groß Fehler Statuscode Angibt dass der Server wkrank nicht die Anfrage zu akzeptieren und zu bearbeiten,e zur Anfrage Körper Größer als der Server ist zulassen oder können Prozess. Zu diesen Beispielen gehört das Hochladen einer Datei, in der die Datei überschreitet die Maximale Upload-Größe Vom Server festgelegt oder wenn die maximale Anzahl von Uploads überschritten wurde. In Fällen, in denen diee 413 Anforderungsentität zu großer Fehler kann der Server die Verbindung vollständig schließen, um zu verhindern, dass der weiterhin die Anforderung zu senden. In einigen Fällen, Es Ichs wahrscheinlich die Server Würde es dem Client ermöglichen, die Anforderung erneut zu versuchen, wenn esIchs eine vorübergehende Bedingung, Und sollte diese Nachricht an den Client zurücksenden. However, es IchS möglich, dass die Anforderung dazu führen könnte, dass der Server selbst keine physischen Speicherplatz. In diesem Fall ist der Fehler 507 Unzureichender Speicher die Antwort, die der Client zurück erhalten soll. See RFC7231, Abschnitt 6.5.11 für weitere Informationen.

414: URI zu lang

Der Fehlerstatuscode 414 URI Too Long ist keine sehr häufige Serverantwort, sondern bedeutet, dass der Server die Clientanforderung aufgrund der DIE URL ist länger, als der Server verarbeiten kann. Bruderwsers und Suchmaschinen setzen Grenzen für die Länge von URLs, teilweise um DDoS-Angriffe oder Codefehlerzuvermeiden, aber der Pfad einer URL oder HTTP nicht haben explizite Grenzen. Also, wenn limit überschreitet, was vom Server festgelegt wird, tritt der 414 URI Too Long-Fehler auf. Weitere Informationen zum Fehlercode 414 URI Too Long finden Sie unter RFC7231, Abschnitt 6.5.12

415: Nicht unterstützter Medientyp

Der 415 Nicht unterstützte Medientyp-Fehlerstatuscode gibt an, dass der Server denAnforderungstext oder einen Teil des Anforderungstexts aufgrund einesnicht unterstützten Medienformats nicht verarbeiten kann. Auch wenn die Anforderung vom Client unterstützt wird, kann der 415-Fehler zurückgegeben, wenn der Inhalt der Anforderung nicht unterstützt wird. Ein 415 Nicht unterstützter Medientyp-Fehlercode ähnelt dem Statuscode 406 Not Acceptable. Der Unterschied besteht darin, dass ein 406 Not Acceptable Fehlercode ist nicht auf den Inhalt in der Kopfzeile oder Codierung zurückzuführen, sondern aufgrund des wertes, der innerhalb des HTTP-Headers festgelegt ist. Wenn Sichergestellt wird, dass der Server das definierte Format zusammen mit dem Senden der Anforderung mit dem richtigen Formular verarbeiten kann, wird verhindert, dass ein 415 nicht unterstützter Medientyp-Fehlerstatuscode ausgeführt wird. See RFC7231, Abschnitt 6.5.13 für weitere Informationen.

416: Bereich nicht befriedigt

Wie bereits mit dem Statuscode 206 Partial Request erwähnt, ist es für Clients/Browser möglich, eine partielle Antwort von der Serve r anzufordern,ob sie iz. B. einen bestimmten Teil einer Datei oder eines Videos. Clients und Server verwenden so genannte Bereichsanforderungen an diese Anforderungen auszuführen. Wenn der Server jedoch diese Art von Anfragen nicht unterstützen, wird es einfach die gesamte resouzusammen mit einer 200 OK-Antwort. Wenn der Server Bereichsanforderungen unterstützt,t ist wo die 416 Teilantrag Fehler Statuscode gibt das Bild ein und gibt zurück, was der Kunde verlangt. In einer Situation, in der der Server Bereichsanforderungen unterstützt, Serverdoes nicht mit den Anfrage erhalten, weil es Nicht innerhalb des Bereichs Oder möglicherweise über die den angegebenen Bereich, den 416 Bereich nicht befriedigt Fehler Statuscode wird zurückgegeben. SEe RFC7233, Abschnitt 4.4 für weitere Informationen.

417: Erwartung fehlgeschlagen

Clients können einen Expect-Header verwenden, um anzugeben, dass er ein bestimmtes Verhalten vom Server erwartet. Wie im Statuscode 100 Continue beschrieben, können Clients beim Server überprüfen, ob er eine Anforderung akzeptiert. Wenn dies der Vorgang der Falle ist, antwortet der Server mit dem Statuscode 100 Continue.. Wenn nicht, the 417 Erwartung fehlgeschlagen Fehler Statuscode Angibt das der Server tat Nicht verstehen die Erwarten Header oder unterstützen, so kann esNicht die Clien verarbeitenT Anfrage. Weitere Informationen zum Fehlercode 417 Expectation Failed finden Sie unter RFC7231, Abschnitt 6.5.14

418-420:Nicht zugewiesen

Fehler status Codes 418-421 sind derzeit nicht zugewiesen, jedoch Statuscode 418 Ich bin eine kleine Teekanne wird in einigen Fällen verwendet. Erstellt als Aprilscherz, hat es etwas Anklang gewonnen und ist manchmal als Witz oder Osterei und nicht für tatsächliche alltägliche Zwecke verwendet. Die meisten Browser ignorieren es, da es keinoffizieller Statuscode ist. Ein weiterer in dieser Kategorie ist der 420 Enhance Your Calm-Fehlerstatuscode, der von Twitter eingeführt. Es i s an Fehlercode, der Clients mitteilt, dass sie die Rate begrenzt haben, isteine Beschränkung für die Anzahl derAnfragen, die sie innerhalb eines bestimmten Zeitraums stellen können. Seit 1989wird der RFC Editor die humorvolleren RFCsveröffentlichen. Wikipedia hat eine vollständige Ableitung der humorvolleren April fool es RFCs.

421: Irre gesteuerte Anfrage

Eingeführt mit dem HTTP/2-Protokoll, das 421 Fehlgeleitete Anfrage Fehler Statuscode bedeutet, dass die Server-Receine Anfrage, die Nicht für diesen bestimmten Server und kann nicht richtig reagieren. Dies kann passieren, wenn das DNS (Domain Name System) auf die falsche IP-Adresse festgelegt ist. Kunden erforderlich sind, um ein Host Header in der Anforderung. Dies kann auch bei Standorten auftreten, die über eine Ssl Zertifikat aus mehreren Domänen. Dies kann durch eineN Problem mit dem Hosting-Provider und/oder einem bestimmten Browser verwendet, so kann es eine Menge Arbeit erfordern, um wirklich zu verstehen, wo das Problem liegt. Wenn ein Server weiß, dass eine Domäne nicht auf dem Req konfiguriert istuest, wird es mit der 421 Fehlgesteuerte Anfrage antworten Fehlerantwort. SEe RFC7540, Abschnitt 9.1.2 für weitere Informationen.

422: Unverarbeitbare Entität

A 422 Unverarbeitbar Entität Fehler Statuscode Angibt ein Problem mit der Inhalt der Syntax einer Anforderung. das Anordnung des Antrags wurde vom Server verstandenAber das Felder innerhalb der Anforderung sind ungültig oder tut Nicht entsprechen dem, was der Server erwartet. mögen die 102 Processing und 207 Multi-Statusstatuscodes, ein 422 Unverarbeitbar Entität Fehler Code ist Teil des WebDAV-Protokolls und wird häufig mit Webdiensten/APIs verwendet. Im Allgemeinen ist ein 400 Bad Request ist die empfohlene Antwort, aber wenn WebDAV unterstützt wird, dann the 422 Unverarbeitbar Entität sollte verwendet werden. SEe RFC4918, Abschnitt 11.2 für weitere Informationen.

423: Gesperrt

Wie der Fehlerstatuscode 422 Unprocessable Entity wird der 423 Locked-Fehler Statuscode ist auch Teil des WebDAV-Protokolls. Der Statuscode 423 Gesperrt gibt an, dass eine, Ressource oder direkt, z. B. nicht bearbeitet werden kann. Sein Zweck ist es, zu vermeiden, dass mehrere Benutzer eine Datei, Ressource usw. gleichzeitig aktualisieren. Diese Ressourcen können dann für die Bearbeitung entsperrt werden, wHenne notwendig. Weitere Informationen zum Fehlercode 423 Gesperrt finden Sie unter RFC4918, Abschnitt 11.3

424: Fehlgeschlagene Abhängigkeit

Ein weiterer Statuscode, der vom WebDav unterstützt wird Protokoll; die 424 fehlgeschlagene Abhängigkeit Fehlerstatuscode gibt an, dass Die Anforderung des Clients ist aufgrund einer Abhängigkeit von einer anderen Anforderung fehlgeschlagen, die ebenfalls fehlgeschlagen ist. WebDAV nutzt eine Methode bekannt als PROPPATCH , um bestimmte resource-Eigenschaften zu aktualisieren. An geben Anteilen an, ob eine Ressource erfolgreich aktualisiert wurde oder nicht, WebDAV verwendet standardmäßige HTTP-Statuscodeantworten. Darüber hinaus wird der Statuscode 424 “Fehlgeschlagene Abhängigkeit” nur in Fällen verwendet, in denen die Antwort im HTTP-Text die 207 Multi-Status-Antwort. So, wenn PROPPATCH verwendet wird und die Ressource nicht aktualisiert werden kann, sendet es einen 4xx-Statuscode, der Beim Aktualisieren der Ressource ist ein Fehler aufgetreten, der Fehlercode 424 fehlgeschlagene Abhängigkeit wird zusammen mit den anderen Anforderungen gesendet, die davon abhängig waren, dass diese Aktualisierung erfolgreich war, aber fehlgeschlagenist. See RFC4918, Abschnitt 11.4 für weitere Informationen.

425: Zu früh

Der 425 Too Early Fehlerantwortcode wird nicht als häufiger HTTP-Statuscode verwendet, der heute verwendet wird, wenn ein HTTP-Client eine Verbindung mit einem HTTPS-Client herstellt. Während des Prozesses kann es lange dauern, eine Verbindung zwischen Server und Client. Dieser Vorgang kann ein Sicherheitsproblem darstellen, sodass der Server den Client anfordert, die Anforderung erneut zu versuchen. bis die sichere TLS-Verbindung (Transport Layer Security) gemacht. In diesem Fall wird der Statuscode 425 Too Early zurückgegeben. Weitere Informationen zum Fehlercode 425 Too Early finden Sie unter RFC8470, Abschnitt 5.2

426: Upgrade erforderlich

Der Fehlerstatuscode 426 Upgrade Erforderlich gibt dem Client an, dass er ein neueres Protokoll verwenden muss. um Anforderungen an den Server senden. Der Client verwendet z. B. eine ältere Version von HTTP, z. B. HTTP/1.0, aber der Server Erfordert HTTP2.0. Der Server akzeptiert die Anfrage, aber reagiert zurück auf die ClienT Anzeige welche Protokolle oder Protokolle akzeptabel sind. Sobald der Client ein Upgrade auf die erforderlichen Protokoll(en), nimmt der Server Anforderungen vom Client an. Weitere Informationen zum Fehlercode 426 Upgrade Required finden Sie unter RFC7231, Abschnitt 6.5.15

427: Nicht zugewiesen

Fehler tatuscode 427 ist derzeit nicht zugewiesen.

428: Voraussetzung erforderlich

Der Fehlerstatuscode 428 Precondition Required gibt dem Client an, dass die Anforderung an den Server eine bedingte Anforderung sein muss. Wie in der 304 Nicht geänderter Statuscode, ein Client kann eine bedingte Anforderung senden zum ServerWie If-Match, If-None-Match, If-Modified-Since, If-Unmodified-SinceOder If-Range. Diese bedingten Anforderungen sind jedoch nicht Erforderlich. Wenn sie vom Server benötigt werden, Angibt indem Sie mit dem Fehlercode 428 Precondition Required antworten. Das ist ein bisschen ähnlich wie 412 Precondition Failed Fehlercode, aber die 412 Vorbedingung fehlgeschlagen Fehlercode wird nur zurückgegeben, wenn der Client eine bedingte Anforderung in den Header tut Nicht MAtch den Status der Ressource auf dem Servers Seite. Indem Benutzer darüber informiert werden, dass Anforderungen bedingt sein müssen, stellt dies sicher, dass benutzerisch mit den richtigen Dateien oder Ressourcen arbeiten und hilft, Benutzer, die möglicherweise Änderungen überschreiben. SEe RFC6585, Abschnitt 3 für weitere Informationen.

429: Zu viele Anfragen

Genau wie der Name des Fehlers Code gibt an,dass derFehlerstatuscode 429 Too Many Request bedeutet, dass die client über das Limit für die Art und Weise, wie viele Anfragen es kann machen in einem bestimmten Zeitraum. Zusammen mit der Fehlerantwort 429 Too Many Requests sollte Angegeben wie lange zu warten, bevor Initiieren Eine neue Anforderung an den Server, aber es ist nicht Früher Erforderlich um dies zu tun. Weitere Informationen zum Fehlercode Too Many Requests finden Sie unter RFC6585, Abschnitt 4

430: Nicht zugewiesen

Der 430-Fehlerstatuscode ist derzeit nicht zugewiesen, wurde jedoch einmal als 430 Would Block-Fehlercode innerhalb des HTTP/1.1-Protokolls vorgeschlagen.. Die Absicht war, als Antwort auf das zu dienen, was bekannt als Pipelining. Dadurch konnten Clients mehrere Anforderungen senden., über eine TCP-Verbindung, während es darauf gewartet hat, dass der Server . Icht schaffte es nie offiziell in die Standard, da der HTTP-Prototypauf HTTP/2.0 aktualisiert wurdeund die Unterstützung für Pipelining nie weit verbreitet war.

431 Anforderungsheader zu groß

Der Fehlerstatuscode 431 Request Headers Too Large gibt an, dass der Client eine Header-r-equest gesendet hat,die das zulässige Limit überschreitet. Verschiedene Webserver haben unterschiedliche zulässige Größenbeschränkungen, wenn es um Header geht. Dies kann daran zurückzuführen sein, dass eine einzelne Headeranforderung zu groß ist. oder aufgrund der gesamten kombinierten Größe aller die Headeranforderungen. In den meisten Fällen kann dies leicht zu beheben sein, da es inder Regel durch das Senden von zu vielen Cookies oder Cookies, die zu groß in der Dateigröße sind. Weitere Informationen zum Fehlercode 431 Request Headers Too Large finden Sie unter RFC6585, Abschnitt 5

432-450: Nicht zugewiesen

Fehlerstatuscodes 432 bis 450 sind derzeit nicht zugewiesen.

451: Aus rechtlichen Gründen nicht verfügbar

Fehler sTatus-Code 451 Aus rechtlichen Gründen nicht verfügbar Angibt Der Server weigert sich, den angeforderten Inhalt bereitzustellen aufgrund Rechtlich Gründe und sollte auch den Grund für den Fehler in der Antwort an den Benutzer enthalten. Gründe für die Verwendung des Fehlerstatuscodes 451 Nicht verfügbar aus rechtlichen Gründen Regierungen, die bestimmte Inhalte zensieren,Inhalte, die gegen Urheberrechtsgesetze verstoßen, wie die DMCA (Digital Millennium Copyright Acts)oder Inhalte, die gegen Gesetze oder Gerichtsbeschlüsse verstoßen. Die 403 Verbotenen und 404 Not Found error Statuscodes werden manchmal anstelle des 451 Fehlerstatuscodes verwendet, aber der 451 Fehlerstatuscode bietet weitere Informationen oder Erläuterungen in why der Fehler auftritt. Benutzer haben in der Regel rund um the 451 Fehler durch Implementieren von VPNs für den Zugriff auf den Inhalt. See RFC7725, Abschnitt 3 für weitere Informationen.

452-499: Nicht zugewiesen

Fehlercodes 452-499 sind derzeit nicht zugewiesen.

 

5xx: Serverfehler

Wie die 4xx Statuscodes zeigen die 5xx Statuscodes an, dass ein Fehler vorliegt,derfragliche Fehler ist jedoch wahrscheinlich nicht auf eine fehlerhafte Verbindung oder den Browser selbst zurückzuführen. 5xx Statuscodes anzeigen es gibt ein Problem auf Serverebene und kann die Anforderung vom Client. Zusammen mit dem Fehler sollte der Server mit einer Erklärung des Fehlers antworten, ob es sich um einen vorübergehenden oder dauerhaften Zustandhandelt und wie es behobenwerden kann.

 

500: Interner Serverfehler

Der Statuscode 500 Internal Server Error bedeutet einfach, dass der Server ein Problem und kann die Anforderung nicht verarbeiten. Normalerweise, der 500 Internal Server Error Code wird eher als generischer Serverfehlercode verwendet, wenn das genaue Problem nichtin den anderen 5xx Server Fehlerstatuscode fällt Spezifikationen. T500 Interner Server-Fehlercode ist wahrscheinlich der am häufigsten von den 5xx Server Error Klassifizierungscodes verwendet. Weitere Informationen finden Sie unter RFC7231, Abschnitt 6.6.

501: Nicht implementiert

A 501 Nicht implementiert Fehlerstatuscodes treten auf, wenn der Server Nicht die Methode des Antrags zu erkennen und kann daheroder verarbeiten Sie die Anforderung. Es Ichs mögen der 405-Methode nicht zulässige ClientfehlerstatuscodeAber ein 501 Not Implemented Fehlerstatuscode Anzugeben dass die Anforderungsmethode vom Client gültig ist, nur nicht vom Server unterstützt wird. Der Fehlerstatus 405 Method Not Allowed würde Anzugeben dass die vom Client aufgerufene Methode Nicht Unterstützt und sollte Nicht War Genutzt. Siehe RFC7231, Abschnitt 6.6.2 für weitere Informationen.

502: Schlechtes Tor

Der Fehlerstatuscode 502 Bad Gateway bedeutet, dass ein Server einen Proxy ausgibt und eine Antwort von einem Ursprungsserver erhalten hat, der als ungültig zurückkam. Es Ichs möglich es Ichs aufgrund eines überlasteten Servers und der Client kann die Anforderung erneut senden, in den meisten Fällen, Es Ichs es ist an der Zeit An Ein Problem mit dem Webserver Oder CDN (Content Distribution Network) zwischen Client und Server sitzen und Erfordern Zusätzliche Fehlerbehebung beim Hostinganbieter, um zu verstehen, warum der Fehler ausgelöst wird. Siehe RFC7231, Abschnitt 6.6.3 für weitere Informationen.

503: Dienst nicht verfügbar

Der Fehlerstatuscode 503 Service Unavailable gibt an, dass der Server derzeit mit Anforderungen oder ressourcenfreiüberlastetist, derzeit in Wartung, oder möglicherweise ist die Anwendung, aufdie sie zugreifen möchten, nicht verfügbar, und der Server kann die Anforderung aufgrund des aktuellen Status nicht abschließen. Clients sehen manchmal eine Meldung zusammen mit dem Fehlerstatuscode 503 Service Unavailable, der sie auffordert, die Anforderung erneut zu versuchen. Später. Sie ist jedoch möglicherweise keine endgültige Erklärung dafür, wann oder wie lange der Fehlerstatuscodefür denDienst nicht verfügbar dauernkann. Weitere Informationen finden Sie unter RFC7231, Abschnitt 6.6.4.

504: Gateway-Timeout

Wie der Fehlerstatuscode 502 Bad Gateway wird der Fehlerstatuscode 504 Gateway Timeout verwendet, wenn der Server als Proxy fungiert, aber mit einem 504 Gateway Timeout antwortet. Fehlerstatuscode wenn die Antwort einesN Der Ursprungsserver benötigt zu lange, um zu reagieren. Ein 502 Bad Gateway-Fehlerstatuscode sollte in Fällen verwendet werden, in denen die Antwort ungültig war. oder nicht vom Proxyserver empfangen Überhaupt. Die Botschaft zusammen mit dem 504 GatEWeg Timeout kann anzeigen und empfehlen dass der Client versucht, die Anforderung erneut zu senden. Siehe RFC7231, Abschnitt 6.6.5 für weitere Informationen.

505: HTTP-Version wird nicht unterstützt

Ein Fehlerstatuscode für die 505 HTTP-Version wird nicht unterstützt, d. h., der Server unterstützt die Version des HTTP-Protokolls, das in der Nachricht der Anforderung verwendet wird,nicht und kann dahernicht verarbeitet werden. die Anforderung. Zusammen mit der 505 HTTP Version Nicht unterstützter Fehlerstatuscode, die Antwort vom Server sollte eine Meldung enthalten, warum dieses bestimmte HTTP-Protokoll nicht unterstützt wird und welche Protokolle unterstützt werden. Weitere Informationen finden Sie unter RFC7231, Abschnitt 6.6.6.

506: Variante verhandelt auch

Der 506 Variant Also Negotiates ist ein experimenteller HTTP-Statuscode und ist heute nicht Teil des Standards. Eine 506 Variant Auch negotiates zeigt an, dass es in einem internen Konfigurationsproblem mit dem Server aufgrund von inhaltlichen Verhandlungsproblemen. Die Inhaltsaushandlung ermöglicht Clients das Senden mehrere akzeptieren Header und teilt dem Server mit, welche spezifische Darstellung einer Ressource gemäß Browser. Dies könnte für Die richtige Sprache, das Dokument auseinemt usw. . Auch wenn der Fehlerstatuscode 506 Variant auch aushandelt, Eine Experimenteller Status und nicht offiziell Teil des HTTP-Standards, wird in seltenen Fällen verwendet. Einige Google Play-Nutzertraten dieses Problem in der Vergangenheit auf, als sie versuchten, mehrere Versionen einer Anwendung herunterzuladen, was dazu führte, dass dieir-Geräte ständig versuchten, die App in einem geschlossenen Schleifenprozess herunterzuladen. Weitere Informationen finden Sie unter RFC2295, Abschnitt 8.1.

507: Unzureichender Speicher

Ein 507 Unzureichender Speicherserver-Fehlerstatuscode ist auch Teil des WebDAV-Protokolls. Der Statuscode 507 Unzureichender Speicherfehler zeigt dem client that die Anforderungan, z. B. ein PUT oder POST Anforderung, war zu groß in der Dateigröße. Es kann auch darauf hinweisen, dass der Server vorübergehend nicht mehr im Speicher. Weitere Informationen finden Sie unter RFC4981, Abschnitt 11.5.

508: Schleife erkannt

Die 508 Loop Detected Server Fehlerstatuscode, wie der Fehlercode 507 Unzureichender Speicherserver, ist Teil des WebDAV-Protokolls. Innerhalb des WebDAV-Protokolls Es Ichs möglich, dass der Client eine Anforderung an einen Server stellen kann für ein ganzes Verzeichnis und erstellen Sie ein Ziel einigeWo das gleiche Verzeichnis, was zu einer unendlichen Anforderungs-/Antwortschleife führt. Der 508 Loop Detected Server-Fehlerstatuscode Angibt dass der Server Endete die ClientanforderungSpeziell Tiefe: InFinity, Weil die server Identifiziert die Anfrage als was zu einem infinite Schleife, wiederholt auf sich selbst zurückrufen. Siehe RFC5842, Abschnitt 7.2 für mehr Informationen.

509: Nicht zugewiesen

Der Statuscode 509-Serverfehler ist derzeit nicht zugewiesen.

510: Nicht erweitert

Ein 510 Not Extended Server-Fehlerstatuscode befindet sich derzeit im vorgeschlagenen/experimentellen Status und ist nicht Teil der Standard-HTTP-Statuscodespezifikation. Die 510 Not Extended gibt dem Client an, dass die Anforderung eine erweiterte HTTP-Anforderung erfordert. Wenn der Server mit dem Fehlerstatuscode 510 Not Extended Server antwortet, sollte er auch folgendes beinhalten, wie diesollte remEdy ihre Anfrage, aber die Spezifikation tut Nicht Explizit Staat das. dort‘s debate ob tseine ssollte unter die 5xx-Serverfehlerklassifizierung fallen, da sie als 4xx-Clientfehler angesehen werden könnte, Es ist nicht formal Teil der Norm, Ichs nicht relevAnt und wird nur selten für den täglichen Gebrauch verwendet. Siehe RFC2774, Abschnitt 7 für weitere Informationen.

511: Netzwerkautorisierung erforderlich

Der 511 Network Authorization Erforderlicher Serverfehlerstatuscode, der den Client zur Selbstauthentifizierung benötigt, um Zugriff auf ein Netzwerk zu erhalten. Dies wird benutzern z. B. beim Versuch, eine Verbindung mit einem öffentlichen WLAN-Netzwerk in einem Unternehmen herzustellen, angezeigt. und die Nutzer müssen ihren Geschäftsbedingungen zustimmen, bevor ihnen der Zugang gewährt wird. Zusammen mit der 511 Netzwerkautorisierung erforderlich Serverfehlerantwort sollten Benutzer auch an die Stelle weitergeleitet werden, an der sie sich anmelden können. Weitere Informationen finden Sie unter RFC6585, Abschnitt 6 .

512-599: Nicht zugewiesen

Die Serverfehlerstatuscodes 512-599 sind derzeit nicht zugewiesen, aber einige Unternehmen können diese als benutzerdefinierte Serverfehlermeldungen für Clients verwenden.

 

Überwachen von HTTP-Statuscodeantworten

Um eine Liste der Statuscodes für eine bestimmte URL aus erster Hand anzuzeigen, können Sie die Registerkarte Entwicklertools in Ihrem Browse überprüfen.R. Zusammen mit den Metriken zum Laden der Seitenkönnen können Sie auch alle Serverantworten sowie alle zugehörigen HTTP-Statuscodes anzeigen, um sicherzustellen, dass alles auf Ihrer Seite geladen und Rendering Richtig.

Für einen proaktiveren und automatisierteren Überwachungsansatz können die professionellen Überwachungslösungen von Dotcom-Monitor sicherstellen, dass, wenn ein bestimmter HTTP-Fehlercode von einem Benutzer gefunden wird, Sier Teams benachrichtigtwerden. sofort so können sie das Problem schnell beheben. Sie können auch die Filterfunktion zum Entfernen einzelne HTTP-Statuscodes aus Aufgaben, Warnungen und Berichten, sodass Sie alle HTTP-Statuscodes ignorieren, die für Ihre spezifischen Anforderungen nicht relevant sind.