Liste der HTTP-Statuscodes - List of HTTP status codes

Dies ist eine Liste von HTTP-Antwortstatuscodes ( Hypertext Transfer Protocol ). Statuscodes werden von einem Server als Reaktion auf eine Anforderung eines Clients an den Server ausgegeben . Es enthält Codes von IETF Request for Comments (RFCs), andere Spezifikationen und einige zusätzliche Codes, die in einigen gängigen Anwendungen des HTTP verwendet werden. Die erste Ziffer des Statuscodes gibt eine von fünf Standardklassen von Antworten an. Die gezeigten Nachrichtenphrasen sind typisch, aber jede von Menschen lesbare Alternative kann bereitgestellt werden. Sofern nicht anders angegeben, ist der Statuscode Bestandteil des HTTP/1.1-Standards (RFC 7231).

Die Internet Assigned Numbers Authority (IANA) verwaltet das offizielle Register der HTTP-Statuscodes.

Alle HTTP-Antwortstatuscodes sind in fünf Klassen oder Kategorien unterteilt. Die erste Ziffer des Statuscodes definiert die Klasse der Antwort, während die letzten beiden Ziffern keine klassifizierende oder kategorisierende Rolle haben. Der Standard definiert fünf Klassen:

  • 1xx Informationsantwort – die Anfrage wurde empfangen, Prozess wird fortgesetzt
  • 2xx erfolgreich – die Anfrage wurde erfolgreich empfangen, verstanden und akzeptiert
  • 3xx-Weiterleitung – Es müssen weitere Maßnahmen ergriffen werden, um die Anfrage abzuschließen
  • 4xx Client-Fehler – die Anfrage enthält eine falsche Syntax oder kann nicht erfüllt werden
  • 5xx Serverfehler – der Server hat eine scheinbar gültige Anfrage nicht erfüllt

1xx Informationsantwort

Eine Informationsantwort zeigt an, dass die Anfrage empfangen und verstanden wurde. Sie wird vorläufig ausgestellt, während die Antragsbearbeitung fortgesetzt wird. Es weist den Client darauf hin, auf eine endgültige Antwort zu warten. Die Nachricht besteht nur aus der Statuszeile und optionalen Header-Feldern und wird mit einer Leerzeile abgeschlossen. Da der HTTP/1.0-Standard keine 1xx-Statuscodes definiert, dürfen Server außer unter experimentellen Bedingungen keine 1xx-Antwort an einen HTTP/1.0-kompatiblen Client senden.

100 Weiter
Der Server hat die Anforderungsheader empfangen und der Client sollte mit dem Senden des Anforderungstexts fortfahren (im Falle einer Anforderung, für die ein Textkörper gesendet werden muss, zum Beispiel eine POST- Anforderung). Das Senden eines großen Anfragetexts an einen Server, nachdem eine Anfrage für ungeeignete Header abgelehnt wurde, wäre ineffizient. Damit ein Server die Header der Anfrage überprüft, muss ein Client Expect: 100-continuein seiner anfänglichen Anfrage als Header senden und als 100 ContinueAntwort einen Statuscode erhalten, bevor er den Hauptteil sendet. Wenn der Client einen Fehlercode wie 403 (Forbidden) oder 405 (Method Not Allowed) erhält, sollte er den Hauptteil der Anfrage nicht senden. Die Antwort 417 Expectation Failedgibt an, dass die Anfrage ohne ExpectHeader wiederholt werden soll, da der Server die Erwartungen nicht unterstützt (dies ist beispielsweise bei HTTP/1.0-Servern der Fall).
101 Umschaltprotokolle
Der Anforderer hat den Server gebeten, Protokolle zu wechseln, und der Server hat dem zugestimmt.
102 Verarbeitung ( WebDAV ; RFC 2518)
Eine WebDAV-Anfrage kann viele Unteranfragen enthalten, die Dateioperationen beinhalten und die lange Zeit benötigen, um die Anfrage abzuschließen. Dieser Code zeigt an, dass der Server die Anfrage empfangen hat und verarbeitet, aber noch keine Antwort verfügbar ist. Dadurch wird verhindert, dass der Client eine Zeitüberschreitung verursacht und davon ausgeht, dass die Anforderung verloren gegangen ist.
103 frühe Hinweise (RFC 8297)
Wird verwendet, um einige Antwortheader vor der endgültigen HTTP-Nachricht zurückzugeben.

2xx Erfolg

Diese Klasse von Statuscodes zeigt an, dass die vom Client angeforderte Aktion empfangen, verstanden und akzeptiert wurde.

200 OK
Standardantwort für erfolgreiche HTTP-Anfragen. Die tatsächliche Antwort hängt von der verwendeten Anfragemethode ab. In einer GET-Anfrage enthält die Antwort eine Entität, die der angeforderten Ressource entspricht. In einer POST-Anfrage enthält die Antwort eine Entität, die das Ergebnis der Aktion beschreibt oder enthält.
201 Erstellt
Die Anfrage wurde erfüllt, was zur Erstellung einer neuen Ressource führte.
202 Akzeptiert
Die Anfrage wurde zur Bearbeitung angenommen, aber die Bearbeitung wurde noch nicht abgeschlossen. Die Anfrage kann eventuell bearbeitet werden oder auch nicht und kann bei der Verarbeitung abgelehnt werden.
203 Nicht-autoritative Informationen (seit HTTP/1.1)
Der Server ist ein transformierender Proxy (zB ein Web-Beschleuniger ), der von seinem Ursprung 200 OK erhalten hat, aber eine modifizierte Version der Antwort des Ursprungs zurückgibt.
204 Kein Inhalt
Der Server hat die Anfrage erfolgreich verarbeitet und gibt keinen Inhalt zurück.
205 Inhalt zurücksetzen
Der Server hat die Anfrage erfolgreich verarbeitet, fordert den Anforderer auf, seine Dokumentansicht zurückzusetzen, und gibt keinen Inhalt zurück.
206 Teilinhalt (RFC 7233)
Der Server liefert aufgrund eines vom Client gesendeten Range-Headers nur einen Teil der Ressource ( Byte Serving ). Der Bereichsheader wird von HTTP-Clients verwendet, um die Wiederaufnahme unterbrochener Downloads zu ermöglichen oder einen Download in mehrere gleichzeitige Streams aufzuteilen.
207 Multistatus (WebDAV; RFC 4918)
Der folgende Nachrichtentext ist standardmäßig eine XML- Nachricht und kann eine Reihe von separaten Antwortcodes enthalten, je nachdem, wie viele Unteranforderungen gestellt wurden.
208 bereits gemeldet (WebDAV; RFC 5842)
Die Mitglieder einer DAV-Bindung wurden bereits in einem vorhergehenden Teil der (Multistatus-)Antwort aufgezählt und werden nicht wieder aufgenommen.
226 IM verwendet (RFC 3229)
Der Server hat eine Anforderung für die Ressource erfüllt, und die Antwort ist eine Darstellung des Ergebnisses einer oder mehrerer Instanzmanipulationen, die auf die aktuelle Instanz angewendet wurden.

3xx-Weiterleitung

Diese Statuscodeklasse gibt an, dass der Client zusätzliche Maßnahmen ergreifen muss, um die Anforderung abzuschließen. Viele dieser Statuscodes werden bei der URL-Umleitung verwendet .

Ein Benutzeragent kann die zusätzliche Aktion ohne Benutzerinteraktion nur dann ausführen, wenn die in der zweiten Anforderung verwendete Methode GET oder HEAD ist. Ein Benutzeragent kann eine Anfrage automatisch umleiten. Ein User-Agent sollte erkennen und eingreifen, um zyklische Weiterleitungen zu verhindern.

300 Multiple Choices
Gibt mehrere Optionen für die Ressource an, aus denen der Client auswählen kann (über agentengesteuerte Inhaltsverhandlung ). Dieser Code könnte beispielsweise verwendet werden, um mehrere Videoformatoptionen anzuzeigen, Dateien mit unterschiedlichen Dateinamenerweiterungen aufzulisten oder um eine eindeutige Begriffsklärung vorzuschlagen .
301 dauerhaft verschoben
Diese und alle zukünftigen Anfragen sollten an die angegebene URI gerichtet werden .
302 gefunden (zuvor "vorübergehend verschoben")
Weist den Client an, sich eine andere URL anzusehen (zu suchen). Die HTTP/1.0-Spezifikation (RFC 1945) verlangte vom Client, eine temporäre Weiterleitung mit derselben Methode durchzuführen (der ursprüngliche beschreibende Ausdruck war "Moved Temporarily"), aber gängige Browser implementierten 302 Weiterleitungen, indem sie die Methode in GET änderten. Daher hat HTTP/1.1 die Statuscodes 303 und 307 hinzugefügt, um zwischen den beiden Verhaltensweisen zu unterscheiden.
303 Siehe Sonstiges (seit HTTP/1.1)
Die Antwort auf die Anfrage kann mit der Methode GET unter einem anderen URI gefunden werden. Wenn er als Antwort auf einen POST (oder PUT/DELETE) empfangen wird, sollte der Client davon ausgehen, dass der Server die Daten empfangen hat, und sollte eine neue GET-Anforderung an den angegebenen URI ausgeben.
304 nicht geändert (RFC 7232)
Gibt an, dass die Ressource seit der in den Anforderungsheadern If-Modified-Since oder If-None-Match angegebenen Version nicht geändert wurde . In einem solchen Fall besteht keine Notwendigkeit, die Ressource erneut zu übertragen, da der Client noch über eine zuvor heruntergeladene Kopie verfügt.
305 Proxy verwenden (seit HTTP/1.1)
Die angeforderte Ressource ist nur über einen Proxy verfügbar, dessen Adresse in der Antwort angegeben ist. Aus Sicherheitsgründen befolgen viele HTTP-Clients (wie Mozilla Firefox und Internet Explorer ) diesen Statuscode nicht.
306 Switch-Proxy
Nicht mehr verwendet. Ursprünglich bedeutete "Folgende Anfragen sollten den angegebenen Proxy verwenden".
307 Temporäre Weiterleitung (seit HTTP/1.1)
In diesem Fall sollte die Anfrage mit einer anderen URI wiederholt werden; Zukünftige Anforderungen sollten jedoch weiterhin den ursprünglichen URI verwenden. Im Gegensatz zur historischen Implementierung von 302 darf die Anfragemethode bei der erneuten Ausgabe der ursprünglichen Anfrage nicht geändert werden. Beispielsweise sollte eine POST-Anfrage mit einer anderen POST-Anfrage wiederholt werden.
308 Permanente Weiterleitung (RFC 7538)
Diese und alle zukünftigen Anfragen sollten an die angegebene URI gerichtet werden . 308 entspricht dem Verhalten von 301, lässt jedoch keine Änderung der HTTP-Methode zu . So kann beispielsweise das Senden eines Formulars an eine dauerhaft umgeleitete Ressource reibungslos fortgesetzt werden.

4xx-Client-Fehler

Eine Nachricht aus der Wikimedia 404
404-Fehler bei Wikipedia

Diese Klasse von Statuscodes ist für Situationen gedacht, in denen der Fehler anscheinend vom Client verursacht wurde. Außer , wenn auf eine HEAD - Anforderung reagiert, wobei der Server sollte eine Entität umfassen eine Erklärung der Fehlersituation enthält, und ob es sich um eine temporäre oder permanente Zustand. Diese Statuscodes gelten für jede Anforderungsmethode. Benutzeragenten sollten dem Benutzer alle enthaltenen Entitäten anzeigen.

400 Schlechte Anfrage
Der Server kann oder wird die Anforderung aufgrund eines offensichtlichen Clientfehlers (z. B. fehlerhafte Anforderungssyntax, zu große Größe, ungültiges Nachrichten-Framing der Anforderung oder betrügerisches Anforderungsrouting) nicht verarbeiten.
401 Nicht autorisiert (RFC 7235)
Ähnlich wie 403 Forbidden , aber speziell für die Verwendung, wenn eine Authentifizierung erforderlich ist und fehlgeschlagen ist oder noch nicht bereitgestellt wurde. Die Antwort muss ein WWW-Authenticate-Header-Feld enthalten, das eine Abfrage enthält, die auf die angeforderte Ressource anwendbar ist. Siehe Standard-Zugriffsauthentifizierung und Digest-Zugriffsauthentifizierung . 401 bedeutet semantisch "nicht autorisiert", der Benutzer hat keine gültigen Authentifizierungsdaten für die Zielressource.
Hinweis: Einige Websites geben fälschlicherweise HTTP 401 aus, wenn eine IP-Adresse von der Website (normalerweise die Website-Domain) gesperrt wird und dieser bestimmten Adresse die Berechtigung zum Zugriff auf eine Website verweigert wird.
402 Zahlung erforderlich
Reserviert für zukünftige Verwendung. Die ursprüngliche Absicht war, dass dieser Code als Teil eines digitalen Bargeld- oder Mikrozahlungssystems verwendet werden könnte, wie es beispielsweise von GNU Taler vorgeschlagen wurde , aber das ist noch nicht geschehen, und dieser Code wird nicht weit verbreitet. Die Google Developers API verwendet diesen Status, wenn ein bestimmter Entwickler das Tageslimit für Anfragen überschritten hat. Sipgate verwendet diesen Code, wenn ein Konto nicht über ausreichende Mittel verfügt, um einen Anruf zu starten. Shopify verwendet diesen Code, wenn der Shop seine Gebühren nicht bezahlt hat und vorübergehend deaktiviert ist. Stripe verwendet diesen Code für fehlgeschlagene Zahlungen, bei denen die Parameter korrekt waren, beispielsweise blockierte betrügerische Zahlungen.
403 Verboten
Die Anfrage enthielt gültige Daten und wurde vom Server verstanden, aber der Server lehnt eine Aktion ab. Dies kann daran liegen, dass der Benutzer nicht über die erforderlichen Berechtigungen für eine Ressource verfügt oder ein Konto irgendeiner Art benötigt oder eine verbotene Aktion versucht (z. B. das Erstellen eines doppelten Datensatzes, bei dem nur einer zulässig ist). Dieser Code wird normalerweise auch verwendet, wenn die Anforderung eine Authentifizierung durch Beantworten der Abfrage des WWW-Authenticate-Header-Felds bereitgestellt hat, der Server diese Authentifizierung jedoch nicht akzeptiert hat. Die Aufforderung sollte nicht wiederholt werden.
404 Nicht gefunden
Die angeforderte Ressource konnte nicht gefunden werden, ist aber möglicherweise in Zukunft verfügbar. Nachforderungen des Auftraggebers sind zulässig.
405 Methode nicht erlaubt
Eine Anforderungsmethode wird für die angeforderte Ressource nicht unterstützt; B. eine GET-Anforderung in einem Formular, die die Präsentation von Daten über POST erfordert , oder eine PUT-Anforderung an eine schreibgeschützte Ressource.
406 Nicht akzeptabel
Die angeforderte Ressource kann nur Inhalte generieren, die gemäß den in der Anforderung gesendeten Accept-Headern nicht akzeptabel sind. Siehe Inhaltsverhandlung .
407 Proxy-Authentifizierung erforderlich (RFC 7235)
Der Client muss sich zunächst beim Proxy authentifizieren .
408 Anfrage timeout
Der Server hat eine Zeitüberschreitung beim Warten auf die Anforderung. Laut HTTP-Spezifikationen: "Der Client hat innerhalb der Wartezeit des Servers keine Anfrage erstellt. Der Client KANN die Anfrage ohne Änderungen zu einem späteren Zeitpunkt wiederholen."
409 Konflikt
Gibt an, dass die Anforderung aufgrund eines Konflikts im aktuellen Status der Ressource nicht verarbeitet werden konnte, z. B. eines Bearbeitungskonflikts zwischen mehreren gleichzeitigen Aktualisierungen.
410 weg
Gibt an, dass die angeforderte Ressource nicht mehr verfügbar ist und nicht wieder verfügbar ist. Dies sollte verwendet werden, wenn eine Ressource absichtlich entfernt wurde und die Ressource bereinigt werden sollte. Nach Erhalt eines 410-Statuscodes sollte der Client die Ressource in Zukunft nicht mehr anfordern. Clients wie Suchmaschinen sollten die Ressource aus ihren Indizes entfernen. In den meisten Anwendungsfällen ist es nicht erforderlich, dass Clients und Suchmaschinen die Ressource bereinigen, und stattdessen kann "404 Not Found" verwendet werden.
411 Erforderliche Länge
Die Anforderung hat die Länge ihres Inhalts nicht angegeben, die von der angeforderten Ressource benötigt wird.
412 Vorbedingung fehlgeschlagen (RFC 7232)
Der Server erfüllt eine der Vorbedingungen, die der Anforderer in die Anfrage-Header-Felder gestellt hat, nicht.
413 Nutzlast zu groß (RFC 7231)
Die Anfrage ist größer, als der Server verarbeiten will oder kann. Früher als "Anforderungsentität zu groß" bezeichnet.
414 URI zu lang (RFC 7231)
Der angegebene URI war zu lang für die Verarbeitung durch den Server. Oft das Ergebnis, dass zu viele Daten als Abfragezeichenfolge einer GET-Anfrage codiert werden, in diesem Fall sollte sie in eine POST-Anfrage umgewandelt werden. Vorher "Anfrage-URI zu lang" genannt.
415 Nicht unterstützter Medientyp (RFC 7231)
Die Anforderungsinstanz hat einen Medientyp, den der Server oder die Ressource nicht unterstützt. Der Client lädt beispielsweise ein Bild als image/svg+xml hoch , der Server erfordert jedoch, dass Bilder ein anderes Format verwenden.
416 Bereich nicht erfüllbar (RFC 7233)
Der Client hat einen Teil der Datei angefordert ( Byte Serving ), aber der Server kann diesen Teil nicht liefern. Zum Beispiel, wenn der Kunde nach einem Teil der Datei gefragt hat, der jenseits des Endes der Datei liegt. Vorher "Angeforderter Bereich nicht erfüllbar" genannt.
417 Erwartung fehlgeschlagen
Der Server kann die Anforderungen des Felds Request-Header erwarten nicht erfüllen.
418 Ich bin eine Teekanne (RFC 2324, RFC 7168)
Dieser Code wurde 1998 als einer der traditionellen Aprilscherze der IETF in RFC 2324, Hyper Text Coffee Pot Control Protocol , definiert und wird voraussichtlich nicht von tatsächlichen HTTP-Servern implementiert. Der RFC gibt an, dass dieser Code von Teekannen zurückgegeben werden sollte, die zum Aufbrühen von Kaffee angefordert werden. Dieser HTTP - Status wird als verwendet Osterei in einigen Websites wie Google.com ist Ich bin eine Teekanne Osterei.
421 fehlgeleitete Anfrage (RFC 7540)
Die Anfrage wurde an einen Server gerichtet, der keine Antwort produzieren kann (zB wegen Verbindungswiederverwendung).
422 Nicht verarbeitbare Entität (WebDAV; RFC 4918)
Die Anfrage war wohlgeformt, konnte aber aufgrund semantischer Fehler nicht befolgt werden.
423 gesperrt (WebDAV; RFC 4918)
Die Ressource, auf die zugegriffen wird, ist gesperrt.
424 fehlgeschlagene Abhängigkeit (WebDAV; RFC 4918)
Die Anfrage ist fehlgeschlagen, weil sie von einer anderen Anfrage abhing und diese Anfrage fehlgeschlagen ist (zB ein PROPPATCH).
425 zu früh (RFC 8470)
Zeigt an, dass der Server nicht bereit ist, die Verarbeitung einer möglicherweise wiederholten Anforderung zu riskieren.
426 Upgrade erforderlich
Der Client sollte zu einem anderen Protokoll wie TLS/1.3 wechseln , das im Upgrade-Header- Feld angegeben ist.
428 Vorbedingung erforderlich (RFC 6585)
Der Ursprungsserver erfordert, dass die Anforderung bedingt ist. Beabsichtigt, das Problem des "verlorenen Updates" zu verhindern, bei dem ein Client den Zustand einer Ressource GET, ihn ändert und an den Server zurückgibt, wenn zwischenzeitlich ein Dritter den Zustand auf dem Server geändert hat, was zu einem Konflikt führt.
429 zu viele Anfragen (RFC 6585)
Der Benutzer hat in einer bestimmten Zeit zu viele Anfragen gesendet. Zur Verwendung mit ratenbegrenzenden Schemata vorgesehen.
431 Request-Header-Felder zu groß (RFC 6585)
Der Server ist nicht bereit, die Anfrage zu verarbeiten, da entweder ein einzelnes Header-Feld oder alle Header-Felder zusammen zu groß sind.
451 Aus rechtlichen Gründen nicht verfügbar (RFC 7725)
Ein Serverbetreiber hat eine rechtliche Aufforderung erhalten, den Zugriff auf eine Ressource oder auf einen Satz von Ressourcen zu verweigern, der die angeforderte Ressource enthält. Der Code 451 wurde als Verweis auf den Roman Fahrenheit 451 gewählt (siehe die Danksagungen im RFC).

5xx Serverfehler

Der Server konnte eine Anfrage nicht erfüllen.

Antwortstatuscodes, die mit der Ziffer "5" beginnen, zeigen Fälle an, in denen dem Server bekannt ist, dass er auf einen Fehler gestoßen ist oder anderweitig nicht in der Lage ist, die Anforderung auszuführen. Außer , wenn auf eine HEAD - Anforderung reagiert, wobei der Server sollte eine Entität umfasst eine Erklärung der Fehlersituation enthält, und zeigt an, ob es dich um einen temporärer oder permanenter Zustand ist. Ebenso User Agents sollte dem Benutzer eine beliebige enthalten Einheit anzuzeigen. Diese Antwortcodes gelten für jede Anforderungsmethode.

500 Interner Serverfehler
Eine generische Fehlermeldung, die ausgegeben wird, wenn eine unerwartete Bedingung aufgetreten ist und keine spezifischere Nachricht geeignet ist.
501 nicht implementiert
Entweder erkennt der Server die Anforderungsmethode nicht oder er kann die Anforderung nicht erfüllen. Dies impliziert normalerweise eine zukünftige Verfügbarkeit (zB ein neues Feature einer Web-Service-API).
502 Bad Gateway
Der Server fungierte als Gateway oder Proxy und hat eine ungültige Antwort vom Upstream-Server erhalten.
503 Dienst nicht verfügbar
Der Server kann die Anfrage nicht verarbeiten (weil er überlastet oder wegen Wartung ausgefallen ist). Im Allgemeinen ist dies ein vorübergehender Zustand.
504 Gateway-Zeitüberschreitung
Der Server fungierte als Gateway oder Proxy und erhielt keine rechtzeitige Antwort vom Upstream-Server.
505 HTTP-Version nicht unterstützt
Der Server unterstützt die in der Anfrage verwendete HTTP-Protokollversion nicht.
506-Variante verhandelt auch (RFC 2295)
Eine transparente Inhaltsverhandlung für die Anfrage führt zu einem Zirkelbezug .
507 Unzureichender Speicher (WebDAV; RFC 4918)
Der Server ist nicht in der Lage, die zum Vervollständigen der Anforderung erforderliche Darstellung zu speichern.
508-Schleife erkannt (WebDAV; RFC 5842)
Der Server hat während der Verarbeitung der Anfrage eine Endlosschleife erkannt (gesendet anstelle von 208 Bereits gemeldet ).
510 nicht verlängert (RFC 2774)
Weitere Erweiterungen der Anfrage sind erforderlich, damit der Server sie erfüllen kann.
511 Netzwerkauthentifizierung erforderlich (RFC 6585)
Der Client muss sich authentifizieren, um Zugriff auf das Netzwerk zu erhalten. Vorgesehen für die Verwendung durch das Abfangen von Proxys, die verwendet werden, um den Zugriff auf das Netzwerk zu kontrollieren (z. B. " Captive Portale ", die verwendet werden, um die Zustimmung zu den Nutzungsbedingungen zu erfordern, bevor der vollständige Internetzugang über einen Wi-Fi-Hotspot gewährt wird ).

Inoffizielle Codes

Die folgenden Codes werden von keinem Standard spezifiziert.

218 Das ist in Ordnung ( Apache Webserver )
Wird als Catch-All-Fehlerbedingung verwendet, damit Antworttexte durch Apache fließen können, wenn ProxyErrorOverride aktiviert ist. Wenn ProxyErrorOverride in Apache aktiviert ist, werden Antworttexte, die einen Statuscode von 4xx oder 5xx enthalten, automatisch von Apache zugunsten einer generischen Antwort oder einer benutzerdefinierten Antwort verworfen, die durch die ErrorDocument-Direktive angegeben wird. Der Satz " Das ist in Ordnung " ist ein Internet-Mem, das sich darauf bezieht, die Situation zu ignorieren oder trotz offensichtlicher Hinweise auf eine anhaltende Katastrophe keine Maßnahmen zu ergreifen.
419 Seite abgelaufen ( Laravel Framework )
Wird vom Laravel Framework verwendet, wenn ein CSRF-Token fehlt oder abgelaufen ist.
420 Methodenfehler ( Spring Framework )
Eine veraltete Antwort, die vom Spring Framework verwendet wird, wenn eine Methode fehlgeschlagen ist.
420 Verbessern Sie Ihre Ruhe ( Twitter )
Wird von Version 1 der Twitter Search and Trends API zurückgegeben, wenn die Rate des Clients begrenzt ist; Versionen 1.1 und höher verwenden stattdessen den Antwortcode 429 Too Many Requests . Der Satz "Verbessere deine Ruhe" stammt aus dem Film Demolition Man von 1993 und seine Verbindung mit dieser Zahl ist wahrscheinlich ein Hinweis auf Cannabis .
430 Anfrage-Header-Felder zu groß ( Shopify )
Wird von Shopify anstelle des Antwortcodes 429 Too Many Requests verwendet, wenn innerhalb eines bestimmten Zeitraums zu viele URLs angefordert werden.
450 durch die Windows-Kindersicherung blockiert (Microsoft)
Der Microsoft-Erweiterungscode, der angezeigt wird, wenn die Windows-Kindersicherung aktiviert ist und den Zugriff auf die angeforderte Webseite blockiert.
498 Ungültiges Token (Esri)
Wird von ArcGIS for Server zurückgegeben . Code 498 zeigt ein abgelaufenes oder anderweitig ungültiges Token an.
499 Token erforderlich (Esri)
Wird von ArcGIS for Server zurückgegeben . Code 499 gibt an, dass ein Token erforderlich ist, aber nicht übermittelt wurde.
509 Bandbreitenlimit überschritten ( Apache Webserver / cPanel )
Der Server hat die vom Serveradministrator angegebene Bandbreite überschritten; Dies wird häufig von Shared-Hosting-Anbietern verwendet, um die Bandbreite der Kunden zu begrenzen.
529 Website ist überlastet
Wird von Qualys in der SSLLabs-Servertest-API verwendet, um zu signalisieren, dass die Site die Anfrage nicht verarbeiten kann.
530 Seite ist eingefroren
Wird von der Pantheon- Webplattform verwendet, um eine Website anzuzeigen, die aufgrund von Inaktivität eingefroren wurde.
598 (Informelle Konvention) Netzwerklese-Timeout-Fehler
Wird von einigen HTTP-Proxys verwendet, um einem Client vor dem Proxy eine Netzwerklesezeitüberschreitung hinter dem Proxy zu signalisieren.

Internet-Informationsdienste

Der Webserver Internet Information Services (IIS) von Microsoft erweitert den 4xx-Fehlerbereich, um Fehler mit der Anfrage des Clients zu signalisieren.

440 Anmeldezeitüberschreitung
Die Sitzung des Clients ist abgelaufen und muss sich erneut anmelden.
449 Wiederholen mit
Der Server kann der Anforderung nicht nachkommen, da der Benutzer die erforderlichen Informationen nicht bereitgestellt hat.
451 Weiterleitung
Wird in Exchange ActiveSync verwendet, wenn entweder ein effizienterer Server verfügbar ist oder der Server nicht auf das Postfach der Benutzer zugreifen kann. Es wird erwartet, dass der Client den HTTP-AutoDiscover-Vorgang erneut ausführt, um einen geeigneteren Server zu finden.

IIS verwendet manchmal zusätzliche dezimale Untercodes für spezifischere Informationen, diese Untercodes erscheinen jedoch nur in der Antwortnutzlast und in der Dokumentation, nicht anstelle eines tatsächlichen HTTP-Statuscodes.

nginx

Die nginx -Webserver-Software erweitert den 4xx-Fehlerbereich, um Probleme mit der Anfrage des Clients zu signalisieren.

444 Keine Antwort
Wird intern verwendet, um den Server anzuweisen, keine Informationen an den Client zurückzugeben und die Verbindung sofort zu schließen.
494 Request-Header zu groß
Der Client hat eine zu große Anfrage oder eine zu lange Kopfzeile gesendet.
495 SSL-Zertifikatfehler
Eine Erweiterung des Antwortcodes 400 Bad Request , die verwendet wird, wenn der Client ein ungültiges Clientzertifikat bereitgestellt hat .
496 SSL-Zertifikat erforderlich
Eine Erweiterung des Antwortcodes 400 Bad Request , die verwendet wird, wenn ein Clientzertifikat erforderlich, aber nicht bereitgestellt wird.
497 HTTP-Anfrage an HTTPS-Port gesendet
Eine Erweiterung des Antwortcodes 400 Bad Request , die verwendet wird, wenn der Client eine HTTP-Anfrage an einen Port gestellt hat, der auf HTTPS-Anfragen lauscht.
499 Kundenanfrage geschlossen
Wird verwendet, wenn der Client die Anfrage geschlossen hat, bevor der Server eine Antwort senden konnte.

Wolkenflare

Der Reverse-Proxy-Dienst von Cloudflare erweitert die 5xx-Reihe von Fehlern, um Probleme mit dem Ursprungsserver zu signalisieren.

520 Webserver hat einen unbekannten Fehler zurückgegeben
Der Ursprungsserver hat eine leere, unbekannte oder unerwartete Antwort an Cloudflare zurückgegeben.
521 Webserver ist ausgefallen
Der Ursprungsserver hat Verbindungen von Cloudflare abgelehnt. Sicherheitslösungen am Ursprung blockieren möglicherweise legitime Verbindungen von bestimmten Cloudflare-IP-Adressen.
522 Verbindungszeitüberschreitung
Cloudflare hat beim Kontaktieren des Ursprungsservers eine Zeitüberschreitung festgestellt.
523 Ursprung ist nicht erreichbar
Cloudflare konnte den Ursprungsserver nicht erreichen; B. wenn die DNS-Einträge für den Ursprungsserver falsch sind oder fehlen.
524 Ein Timeout ist aufgetreten
Cloudflare konnte eine TCP-Verbindung zum Ursprungsserver herstellen, erhielt jedoch keine zeitnahe HTTP-Antwort.
525 SSL-Handshake fehlgeschlagen
Cloudflare konnte keinen SSL/TLS-Handshake mit dem Ursprungsserver aushandeln .
526 Ungültiges SSL-Zertifikat
Cloudflare konnte das SSL-Zertifikat auf dem Ursprungswebserver nicht validieren. Wird auch vom gorouter von Cloud Foundry verwendet.
527 Railgun-Fehler
Fehler 527 weist auf eine unterbrochene Verbindung zwischen Cloudflare und dem Railgun-Server des Ursprungsservers hin.
530
Fehler 530 wird zusammen mit einem 1xxx-Fehler zurückgegeben.

AWS Elastic Load Balancer

Amazon ‚s Elastic Load Balancing fügt ein paar benutzerdefinierte Rückgabecodes

460
Der Client hat die Verbindung mit dem Load Balancer vor Ablauf des Leerlaufzeitlimits geschlossen. Normalerweise, wenn das Client-Timeout vor dem Timeout des Elastic Load Balancer liegt.
463
Der Load Balancer hat einen X-Forwarded-For-Anfrageheader mit mehr als 30 IP-Adressen erhalten.
561 Nicht autorisiert
Ein Fehler bei der Authentifizierung, der von einem Server zurückgegeben wurde, der bei einem Load Balancer registriert ist. Sie haben eine Listener-Regel zum Authentifizieren von Benutzern konfiguriert, aber der Identitätsanbieter (IdP) hat beim Authentifizieren des Benutzers einen Fehlercode zurückgegeben.

Zwischenspeichern von Warncodes

Die folgenden Caching- bezogenen Warnungscodes sind unter RFC 7234 spezifiziert. Im Gegensatz zu den anderen oben genannten Statuscodes werden diese nicht als Antwortstatus im HTTP-Protokoll, sondern als Teil des HTTP-Headers "Warning" gesendet. Da dieser Header oft weder von Servern gesendet noch von Clients bestätigt wird, wird er bald von der HTTP Working Group obsolet .

110 Antwort ist veraltet
Die von einem Cache bereitgestellte Antwort ist veraltet (das Alter des Inhalts überschreitet ein maximales Alter, das durch einen Cache-Control-Header oder eine heuristisch gewählte Lebensdauer festgelegt wird).
111 Revalidierung fehlgeschlagen
Der Cache konnte die Antwort nicht validieren, da der Ursprungsserver nicht erreicht werden konnte.
112 Getrennter Betrieb
Der Cache wird absichtlich vom Rest des Netzwerks getrennt.
113 Heuristischer Ablauf
Der Cache hat heuristisch eine Frischelebensdauer von mehr als 24 Stunden und ein Alter der Antwort von mehr als 24 Stunden gewählt.
199 Sonstiges Warnung
Willkürliche, unspezifische Warnung. Der Warntext kann protokolliert oder dem Benutzer angezeigt werden.
214 Transformation angewendet
Wird von einem Proxy hinzugefügt, wenn er eine Transformation auf die Darstellung anwendet, z. B. durch Ändern der Inhaltscodierung, des Medientyps oder dergleichen.
299 Verschiedenes Dauerwarnung
Wie 199, zeigt jedoch eine anhaltende Warnung an.

Siehe auch

Anmerkungen

Verweise

Externe Links