Was bedeutet HTTP-Code 200. Liste der HTTP-Statuscodes

Beim Anfordern von Informationen von einem Remote-Webserver kann ein Fehler auftreten, dann sendet der Webserver zurück HTTP-Fehlercode. Zum Beispiel 404- nicht gefunden(Die Quelle kann nicht gefunden werden).
Codes HTTP-Zustände bestehen aus drei Ziffern von 100 bis 510. Sie werden in folgende Gruppen eingeteilt:

1. Informativ (100-105)
2. Erfolgreich (200-226)
3. Umleitung (300-307)
4. Clientfehler (400-499)
5. Serverfehler (500-510)

Bitte geben Sie die drei, die Sie interessieren, in das Feld unten ein. Zeichencode und erhalten Sie seine Beschreibung:

Suche

Beschreibung

Weiter Der Server ist mit den ersten Informationen über die Anfrage zufrieden, der Client kann weiterhin Header senden. Eingeführt in HTTP/1.1.

Wechseln von Protokollen Der Server bietet an, zu einem geeigneteren Protokoll für die angegebene Ressource zu wechseln; Der Server muss die Liste der vorgeschlagenen Protokolle im Feld Update-Header angeben. Wenn der Client daran interessiert ist, sendet er eine neue Anfrage, die ein anderes Protokoll angibt. Eingeführt in HTTP/1.1.

Bearbeitung Die Anfrage wurde akzeptiert, aber die Bearbeitung wird lange dauern. Wird vom Server verwendet, um zu verhindern, dass der Client die Verbindung aufgrund einer Zeitüberschreitung beendet. Der Client muss beim Empfang einer solchen Antwort den Zeitgeber zurücksetzen und auf den nächsten Befehl im normalen Modus warten. Erschienen in WebDAV.

OK Erfolgreiche Anfrage. Wenn vom Client Daten angefordert wurden, befinden sich diese im Header und/oder Body der Nachricht. Eingeführt in HTTP/1.0.

Erstellt Eine neue Ressource wurde als Ergebnis einer erfolgreichen Anforderung erstellt. Der Server muss seinen Standort im Location-Header angeben. Es wird empfohlen, dass der Server [Quelle nicht angegeben 336 Tage] auch die Merkmale der erstellten Ressource im Header (z. B. im Feld Content-Type) angibt. Wenn der Server nicht sicher ist, dass die Ressource tatsächlich existiert, wenn der Client diese Nachricht erhält, dann ist es besser, eine 202-Antwort zu verwenden.Eingeführt in HTTP/1.0.

Akzeptiert Die Anfrage wurde zur Bearbeitung angenommen, aber noch nicht abgeschlossen. Der Client muss nicht auf die endgültige Übertragung der Nachricht warten, da ein sehr langer Prozess gestartet werden kann. Eingeführt in HTTP/1.0.

Nicht maßgebliche Informationen Ähnlich wie bei der 200-Antwort, aber in diesem Fall stammen die übermittelten Informationen nicht aus der Primärquelle ( Sicherung, ein anderer Server usw.) und kann daher veraltet sein. Eingeführt in HTTP/1.1.

Kein Inhalt Der Server hat die Anforderung erfolgreich verarbeitet, aber in der Antwort wurden nur Header ohne Nachrichtentext gesendet. Der Client muss den Inhalt des Dokuments nicht aktualisieren, kann aber die erhaltenen Metadaten darauf anwenden. Eingeführt in HTTP/1.0.

Inhalt zurücksetzen Der Server weist den Client an, die Eingabe des Benutzers zurückzusetzen. Der Server überträgt den Nachrichtentext nicht, und das Dokument muss nicht aktualisiert werden. Eingeführt in HTTP/1.1.

Partial Content Der Server hat eine partielle GET-Anforderung erfolgreich abgeschlossen und nur einen Teil der Nachricht zurückgegeben. Im Content-Range-Header gibt der Server die Byte-Bereiche des Inhalts an. Bei der Arbeit mit solchen Antworten sollte dem Caching besondere Aufmerksamkeit geschenkt werden. Eingeführt in HTTP/1.1. (mehr...)

Multi-Status Der Server überträgt die Ergebnisse mehrerer unabhängiger Operationen auf einmal. Sie werden im Nachrichtentext selbst als XML-Dokument mit einem Multistatus-Objekt platziert. Es wird aufgrund der Sinnlosigkeit und Redundanz nicht empfohlen, Status aus der 1xx-Serie in diesem Objekt zu platzieren. Erschienen in WebDAV.

IM Used Der A-IM-Header vom Client wurde erfolgreich empfangen und der Server gibt den Inhalt mit den angegebenen Parametern zurück. Eingeführt in RFC 3229 zur Ergänzung HTTP-Protokoll Unterstützung für Delta-Codierung.

Mehrere Auswahlmöglichkeiten Der angegebene URI hat mehrere Auswahlmöglichkeiten für die Bereitstellung der Ressource nach MIME-Typ, nach Sprache oder nach anderen Merkmalen. Der Server sendet mit der Nachricht eine Liste von Alternativen, die eine automatische Auswahl durch den Client oder den Benutzer ermöglicht. Eingeführt in HTTP/1.0.

Dauerhaft verschoben Das angeforderte Dokument wurde dauerhaft an den neuen URI verschoben, der im Header-Feld Location angegeben ist. Einige Clients verhalten sich bei der Verarbeitung dieses Codes falsch. Eingeführt in HTTP/1.0.

Gefunden, vorübergehend verschoben Das angeforderte Dokument ist vorübergehend unter einem anderen URI verfügbar, wie im Feld Location des Headers angegeben. Dieser Code kann beispielsweise bei der servergesteuerten Inhaltsaushandlung verwendet werden. Einige Clients verhalten sich bei der Verarbeitung dieses Codes falsch. Eingeführt in HTTP/1.0.

See Other Das Dokument mit dem angeforderten URI muss unter der Adresse im Location-Feld des Headers mit der GET-Methode angefordert werden, obwohl ersteres mit einer anderen Methode angefordert wurde. Dieser Code wurde zusammen mit 307 eingeführt, um Mehrdeutigkeiten zu vermeiden, damit der Server sicher ist, dass die nächste Ressource mit der GET-Methode angefordert wird. Beispielsweise hat eine Webseite ein Texteingabefeld für schneller Übergang und suchen. Nach Eingabe der Daten stellt der Browser eine Anfrage mit der POST-Methode, einschließlich des eingegebenen Textes im Hauptteil der Nachricht. Wenn ein Dokument mit dem eingegebenen Titel gefunden wird, antwortet der Server mit einem 303-Code, der seine permanente Adresse im Location-Header angibt. Dann wird der Browser es garantiert mit der GET-Methode anfordern, um den Inhalt zu erhalten. Andernfalls gibt der Server einfach die Suchergebnisseite an den Client zurück. Eingeführt in HTTP/1.1.

Not Modified Der Server gibt diesen Code zurück, wenn der Client das Dokument mit der GET-Methode angefordert hat, den If-Modified-Since- oder If-None-Match-Header verwendet hat und das Dokument seit der angegebenen Zeit nicht geändert wurde. In diesem Fall darf die Servernachricht keinen Body enthalten. Eingeführt in HTTP/1.0.

Proxy verwenden Die Anforderung an die angeforderte Ressource muss über einen Proxy-Server erfolgen, dessen URI im Header-Feld „Location“ angegeben ist. Dieser Antwortcode kann nur von Ursprungs-HTTP-Servern (nicht Proxys) verwendet werden. Eingeführt in HTTP/1.1.

(reserviert) zuvor verwendeter Antwortcode, zur Zeit reserviert. Erwähnt in RFC 2616 (HTTP/1.1-Update).

Temporäre Umleitung Die angeforderte Ressource ist kurzzeitig unter einem anderen URI verfügbar, wie im Location-Header-Feld angegeben. Dieser Code wurde zusammen mit 303 anstelle von 302 eingeführt, um Mehrdeutigkeiten zu vermeiden. Eingeführt in RFC 2616 (HTTP/1.1-Update).

Ungültige Anfrage Der Server hat einen Syntaxfehler in der Anfrage des Clients festgestellt. Eingeführt in HTTP/1.0.

Der nicht autorisierte Zugriff auf die angeforderte Ressource erfordert eine Authentifizierung. Der Antwortheader muss das WWW-Authenticate-Feld mit einer Liste von Authentifizierungsbedingungen enthalten. Der Client KANN die Anfrage wiederholen, indem er das Autorisierungsfeld in den Nachrichtenkopf mit den für die Authentifizierung erforderlichen Daten aufnimmt.

Zahlung erforderlich Wird voraussichtlich in Zukunft verwendet. Derzeit nicht in Gebrauch. Dieser Code gilt für kostenpflichtige Benutzerdienste, nicht für Hosting-Unternehmen. Dies bedeutet, dass dieser Fehler vom Hosting-Provider im Falle einer überfälligen Zahlung für seine Dienste nicht ausgegeben wird. Reserviert seit HTTP/1.1.

Verboten Der Server hat die Anforderung verstanden, weigert sich jedoch, sie zu erfüllen, da der Zugriff des Clients auf die angegebene Ressource eingeschränkt ist. Wenn für den Zugriff auf eine Ressource eine HTTP-Authentifizierung erforderlich ist, gibt der Server bei Verwendung eines Proxys eine 401- oder 407-Antwort zurück. Andernfalls wurden die Einschränkungen vom Serveradministrator oder dem Entwickler der Webanwendung festgelegt und können je nach den Fähigkeiten des Benutzers beliebig sein Software. In jedem Fall sollten dem Kunden die Gründe für die Ablehnung der Bearbeitung des Antrags mitgeteilt werden. Die wahrscheinlichsten Gründe für die Einschränkung sind ein Versuch, auf Systemressourcen des Webservers (z. B. .htaccess- oder .htpasswd-Dateien) zuzugreifen, oder Dateien, denen der Zugriff verweigert wurde Konfigurationsdateien, die beispielsweise eine Nicht-HTTP-Authentifizierung erfordert, um auf ein Content-Management-System oder einen Bereich für registrierte Benutzer zuzugreifen, oder der Server ist beispielsweise mit der IP-Adresse des Clients nicht zufrieden, wenn er blockiert wird. Eingeführt in HTTP/1.0.

Not Found Der häufigste Fehler bei der Nutzung des Internets, der Hauptgrund ist ein Fehler beim Schreiben der Adresse einer Webseite. Der Server hat die Anfrage verstanden, aber keine übereinstimmende Ressource unter der angegebenen URI gefunden. Wenn der Server weiß, dass an dieser Adresse ein Dokument vorhanden war, ist es wünschenswert, den Code 410 zu verwenden. Die 404-Antwort kann anstelle von 403 verwendet werden, wenn Sie sich sorgfältig davor verstecken möchten neugierige Blicke bestimmte Ressourcen. Eingeführt in HTTP/1.0.

Methode nicht zulässig Die vom Client angegebene Methode kann nicht auf die aktuelle Ressource angewendet werden. In der Antwort MUSS der Server die verfügbaren Methoden im Allow-Header angeben, getrennt durch ein Komma. Der Server sollte diesen Fehler zurückgeben, wenn ihm die Methode bekannt ist, aber nicht speziell auf die in der Anfrage angegebene Ressource anwendbar ist, aber wenn die angegebene Methode nicht auf dem gesamten Server anwendbar ist, dann sollte der Client den Code 501 zurückgeben ( Nicht implementiert). Eingeführt in HTTP/1.1.

Nicht akzeptabel Der angeforderte URI kann die im Header übergebenen Merkmale nicht erfüllen. Wenn die Methode nicht HEAD war, MUSS der Server eine Liste gültiger Merkmale für die angegebene Ressource zurückgeben. Eingeführt in HTTP/1.1.

Proxy-Authentifizierung erforderlich Die Antwort ähnelt einem 401, außer dass die Authentifizierung für einen Proxy-Server erfolgt. Der Mechanismus ähnelt der Authentifizierung auf dem Ursprungsserver. Eingeführt in HTTP/1.1.

Zeitüberschreitung bei Anforderung Zeitüberschreitung des Servers beim Warten auf eine Übertragung vom Client. Der Client kann die Anfrage jederzeit ähnlich der vorherigen wiederholen. Eine solche Situation kann beispielsweise auftreten, wenn eine große Datei mit der POST- oder PUT-Methode auf den Server hochgeladen wird. Irgendwann während der Übertragung reagierte die Datenquelle nicht mehr, beispielsweise aufgrund einer Beschädigung der CD oder eines Kommunikationsverlusts mit einem anderen Computer in lokales Netzwerk. Solange der Client nichts sendet und auf eine Antwort von ihm wartet, wird die Verbindung zum Server aufrechterhalten. Nach einiger Zeit kann der Server die Verbindung auf seiner Seite schließen, damit andere Clients eine Anfrage stellen können. Diese Antwort wird nicht zurückgegeben, wenn der Client die Übertragung auf Befehl des Benutzers zwangsweise beendet hat oder die Verbindung aus einem anderen Grund unterbrochen wurde, da die Antwort nicht mehr gesendet werden kann. Eingeführt in HTTP/1.1.

Konflikt Die Anfrage konnte aufgrund eines Ressourcenkonflikts nicht abgeschlossen werden. Dies ist beispielsweise möglich, wenn zwei Clients versuchen, eine Ressource mit der PUT-Methode zu ändern, eingeführt in HTTP/1.1.

Gone Der Server sendet eine solche Antwort, wenn sich die Ressource früher unter der angegebenen URL befand, aber entfernt wurde und jetzt nicht verfügbar ist. Der Server kennt in diesem Fall auch nicht den Ort des alternativen Dokuments, beispielsweise einer Kopie). Wenn der Server den Verdacht hat, dass das Dokument in naher Zukunft wiederhergestellt werden kann, dann besser für den Kunden Passcode 404. Eingeführt in HTTP/1.1.

Erforderliche Länge Für die angegebene Ressource muss der Client eine Inhaltslänge im Anforderungsheader angeben. Ohne Angabe dieses Felds sollten Sie die Anforderung an den Server für diesen URI nicht wiederholen. Diese Antwort ist für POST- und PUT-Anforderungen natürlich. Zum Beispiel, wenn Dateien unter dem angegebenen URI heruntergeladen werden und ihr Volumen auf dem Server begrenzt ist. Dann wäre es klüger, gleich zu Beginn den Content-Length-Header zu prüfen und den Download sofort zu verweigern, als durch einen Verbindungsabbruch eine sinnlose Last zu provozieren, wenn der Client wirklich eine zu große Nachricht sendet. Eingeführt in HTTP/1.1.

Vorbedingung fehlgeschlagen Wird zurückgegeben, wenn keines der Bedingungsfelder im Header [unbekannter Begriff] der Anfrage erfüllt wurde. Eingeführt in HTTP/1.1.

Anforderungsentität zu groß Wird zurückgegeben, wenn der Server die Verarbeitung der Anforderung ablehnt, weil der Anforderungstext zu groß ist. Der Server KANN die Verbindung schließen, um die weitere Übertragung der Anfrage zu stoppen. Wenn das Problem vorübergehend ist, wird empfohlen, einen Retry-After-Header in die Serverantwort aufzunehmen, der die Zeit angibt, nach der eine ähnliche Anfrage wiederholt werden kann. Eingeführt in HTTP/1.1.

Anfrage-URL zu lang Der Server kann die Anfrage nicht verarbeiten, da die angegebene URL zu lang ist. Ein solcher Fehler kann beispielsweise provoziert werden, wenn der Client versucht, lange Parameter über die GET-Methode statt über POST zu übergeben. Eingeführt in HTTP/1.1.

Nicht unterstützter Medientyp Aus irgendeinem Grund weigert sich der Server, mit dem angegebenen Medientyp zu arbeiten, wenn diese Methode. Eingeführt in HTTP/1.1.

Angeforderter Bereich nicht erfüllt Das Range-Feld des Anforderungsheaders war ein Bereich außerhalb der Ressource und es fehlt ein If-Range-Feld. Wenn der Client einen Byte-Bereich gesendet hat, kann der Server die tatsächliche Größe im Content-Range-Header-Feld zurückgeben. Diese Antwort sollte nicht verwendet werden, wenn multipart/byteranges übergeben werden [Quelle nicht angegeben 336 Tage]. Eingeführt in RFC 2616 (HTTP/1.1-Update).

Erwartung fehlgeschlagen Aus irgendeinem Grund kann der Server den Wert des Erwartungsfelds im Anforderungsheader nicht erfüllen. Eingeführt in RFC 2616 (HTTP/1.1-Update).

Nicht verarbeitbare Entität Der Server hat die Anfrage erfolgreich akzeptiert, kann mit dem angegebenen Datentyp arbeiten, das XML-Dokument im Hauptteil der Anfrage hat die richtige Syntax, aber es gibt einen logischen Fehler, aufgrund dessen es unmöglich ist, eine Operation auszuführen auf der Ressource. Eingeführt in WebDAV.

Gesperrt Die Zielressource aus der Anforderung ist für die Anwendung der angegebenen Methode gesperrt. Eingeführt in WebDAV.

Fehlgeschlagene Abhängigkeit Die Implementierung der aktuellen Anforderung kann vom Erfolg einer anderen Operation abhängen. Wenn es nicht ausgeführt wird und es daher unmöglich ist, die aktuelle Anfrage auszuführen, gibt der Server diesen Code zurück. Eingeführt in WebDAV.

Ungeordnete Sammlung - Wird gesendet, wenn der Client eine Anfrage gesendet hat, die eine Position in einer unsortierten Sammlung angibt oder eine andere Reihenfolge als der Server verwendet [angeben]. Eingeführt im Entwurf von WebDAV Advanced Collections Protocol.

Upgrade erforderlich Der Server weist den Client an, das Protokoll zu aktualisieren. Der Antwortheader muss wohlgeformte Upgrade- und Verbindungsfelder enthalten. Eingeführt in RFC 2817, um den Übergang zu TLS über HTTP zu ermöglichen.

Wiederholen mit Wird vom Server zurückgegeben, wenn nicht genügend Informationen vom Client vorliegen, um die Anforderung zu verarbeiten. Dadurch wird das Ms-Echo-Request-Feld in den Antwortheader eingefügt. Eingeführt von Microsoft für WebDAV. Aktuell zumindest im Einsatz Microsoft-Programm Geld.

Nicht behebbarer Fehler Wird vom Server zurückgegeben, wenn die Abfrageverarbeitung nicht behebbare Fehler in Datenbanktabellen verursacht [Quelle nicht angegeben 336 Tage]. Eingeführt von Microsoft für WebDAV.

Der HTTP-Statuscode ist dreistellig verschlüsselt. Die erste Ziffer gibt die Statusklasse (Gruppe von Codes) an. Die zweite und dritte Ziffer sind die Seriennummer des Antwortcodes.

Der HTTP-Statuscode wird vom Server zurückgegeben. Es ist Teil der ersten Zeile der Antwort des Servers auf HTTP-Anforderungen und zeigt an, ob eine bestimmte HTTP-Anforderung erfolgreich abgeschlossen wurde.

Die Codes sind in 5 Klassen eingeteilt: informativ (1xx), erfolgreich (2xx), Weiterleitungen (3xx), Clientfehler (4xx) und Serverfehler (5xx).

Kurzbeschreibung der Klassen:

• 1xx (Informational): Dieser Klasse sind Codes zugeordnet, die über den Übertragungsvorgang informieren
• 2xx (successful): Nachrichten dieser Klasse informieren über Fälle der erfolgreichen Annahme und Bearbeitung einer Client-Anfrage
• 3xx (Weiterleitungen): Codes dieser Klasse teilen dem Client mit, dass eine weitere Anfrage gestellt werden muss (normalerweise an einem anderen URI), damit die Operation erfolgreich ist.
• 4xx (Client Errors): Codes in dieser Klasse sollen Fehler auf der Clientseite anzeigen.
• 5xx (Serverfehler): Antwortcodes dieser Klasse sind für Fälle reserviert, in denen die Operation aufgrund eines Fehlers des Servers fehlgeschlagen ist

Nachfolgend finden Sie eine Tabelle, die folgende Informationen in Form eines Spickzettels enthält: Alle digitalen Bezeichnungen von Statuscodes, dem Namen des Codes ist ein erklärender Satz beigefügt Englische Sprache mit Übersetzung ins Russische und Kurzbeschreibung jede Serverantwort.

Gruppe	Antwortcode	Code Name	Beschreibung der Serverantwort
Informativ	100	Fortsetzen	Der Server ist mit den ersten Informationen über die Anfrage zufrieden, der Client kann weiterhin Header senden. Eingeführt in der HTTP/1.1-Version.
	101	Vermittlungsprotokoll	Der Server bietet an, auf ein geeigneteres Protokoll für die angegebene Ressource umzuschalten; Der Server muss die Liste der vorgeschlagenen Protokolle im Feld des Upgrade-Headers angeben. Wenn der Client daran interessiert ist, sendet er eine neue Anfrage, die ein anderes Protokoll angibt.
	102	wird bearbeitet	Die Anfrage wurde vom Server akzeptiert, aber die Verarbeitung dauert lange. Diese Antwort wird verwendet, um zu verhindern, dass der Client die Verbindung aufgrund einer Zeitüberschreitung beendet. Der Client muss beim Empfang einer solchen Antwort den Zeitgeber zurücksetzen und auf den nächsten Befehl im normalen Modus warten. Erschienen in WebDAV.
Erfolgreich	200	OK	Anfrage erfolgreich verarbeitet. "Erfolg" hängt von der angeforderten HTTP-Methode ab: ERHALTEN: "ERHALTEN". Die angeforderte Ressource wurde gefunden und im Text der Antwort übergeben. KOPF: "TITEL". Der Header wird in der Antwort gesendet. POST: "PAKET". Eine Ressource, die das Ergebnis der Aktion des Servers auf die Anfrage beschreibt und im Hauptteil der Antwort übergeben wird. SPUR: SPUR. Der Response-Body enthält den Body der vom Server empfangenen Anfrage.
	201	Erstellt	Die Anfrage wurde erfolgreich abgeschlossen und als Ergebnis wurde eine neue Ressource erstellt. Dieser Code wird normalerweise als Antwort auf eine PUT-PUT-Anforderung gesendet.
	202	akzeptiert	Anfrage akzeptiert, aber noch nicht bearbeitet. Der Client muss nicht auf die endgültige Übertragung der Nachricht warten, da ein sehr langer Prozess gestartet werden kann.
	203	Nicht maßgebliche Informationen (Informationen sind nicht maßgeblich)	Dieser Antwortcode bedeutet, dass die zurückgegebenen Informationen nicht vom Server, sondern von einer anderen Quelle stammen. Ähnlich wie bei der 200-Antwort, aber in diesem Fall stammen die übermittelten Informationen nicht aus der Primärquelle und sind daher möglicherweise nicht aktuell.
	204	Kein Inhalt	Der Server hat die Anforderung erfolgreich verarbeitet, aber in der Antwort wurden nur Header ohne Nachrichtentext gesendet. Der Client muss den Inhalt des Dokuments nicht aktualisieren, kann aber die erhaltenen Metadaten darauf anwenden. Der Client kann sie verwenden, um zwischengespeicherte Header für vorherige Ressourcen zu aktualisieren.
	205	Inhalt zurücksetzen	Mit diesem Code verpflichtet der Server den Client, die vom Benutzer eingegebenen Daten zurückzusetzen. Der Server überträgt den Nachrichtentext nicht, und das Dokument muss nicht aktualisiert werden.
	206	Teilinhalt	Der Server hat die partielle GET-Anforderung erfolgreich abgeschlossen und nur einen Teil des Inhalts zurückgegeben. Im Content-Range-Header gibt der Server die Byte-Bereiche des Inhalts an. Bei der Arbeit mit solchen Antworten sollte dem Caching besondere Aufmerksamkeit geschenkt werden.
Weiterleitungen
	300	Mehrfachauswahl	Dieser Antwortcode wird gesendet, wenn eine Anfrage mehr als eine der möglichen Antworten hat (nach MIME-Typ, nach Sprache oder nach anderen Merkmalen). Der Server sendet mit der Nachricht eine Liste von Alternativen, die eine automatische Auswahl durch den Client oder den Benutzer ermöglicht.
	301	Dauerhaft verschoben (Dauerhaft verschoben)	Dieser Antwortcode gibt an, dass der URI der angeforderten Ressource geändert wurde. Der neue URI wird im Feld Location des Headers angegeben.
	302	Gefunden (Gefunden); Vorübergehend verschoben (vorübergehend verschoben)	Dieser Antwortcode gibt an, dass die angeforderte Ressource vorübergehend unter einem anderen URI verfügbar ist, der im Header-Feld „Location“ angegeben ist.
	303	Siehe Sonstiges	Der Server hat diese Antwort gesendet, um den Client anzuweisen, die angeforderte Ressource unter einem anderen URI mithilfe der GET-Methode abzurufen. Der andere URI wird im Location-Feld des Headers angegeben.
	304	Nicht modifiziert	Diese Antwort wird für das Caching verwendet. Es teilt dem Client mit, dass die Antwort nicht geändert wurde. Auf diese Weise kann der Client weiterhin dieselbe zwischengespeicherte Version der Antwort verwenden. In diesem Fall darf die Servernachricht keinen Body enthalten.
	305	Proxy verwenden (Proxy verwenden)	Die Anforderung an die angeforderte Ressource muss über einen Proxy-Server erfolgen, dessen URI im Header-Feld Location angegeben ist. Dieser Antwortcode wird hauptsächlich aus Sicherheitsgründen nicht unterstützt.
	306	ungebraucht	Dieser Antwortcode wird nicht mehr verwendet und ist derzeit reserviert.
	307	Temporäre Umleitung	Die angeforderte Ressource ist kurzzeitig unter einem anderen URI verfügbar, der im Header-Feld Location angegeben ist. Hat dieselbe Semantik wie der HTTP-Antwortcode 302 Found, außer dass der Client sollte nicht
	308	Permanente Weiterleitung	Das bedeutet, dass sich die Ressource jetzt dauerhaft unter einem anderen URI befindet, wie im Header-Feld „Location“ angegeben. Hat dieselbe Semantik wie der HTTP-Antwortcode 301 Moved Permanently, außer dass der Client sollte nichtÄndern Sie die verwendete HTTP-Methode: Wenn POST in der ersten Anfrage verwendet wurde, sollte POST auch in der zweiten Anfrage verwendet werden.
Client-Fehler
	400	Ungültige Anforderung	Diese Antwort weist darauf hin, dass der Server die Clientanforderung aufgrund eines Syntaxfehlers nicht verstehen konnte.
	401	Nicht autorisiert (Nicht autorisiert)	Die Authentifizierung ist erforderlich, um die angeforderte Antwort zu erhalten. Dies ähnelt einer 403-Antwort, aber eine Authentifizierung ist in diesem Fall möglich. Der Antwortheader muss das WWW-Authenticate-Feld mit einer Liste von Authentifizierungsbedingungen enthalten.
	402	Zahlung erforderlich	Dieser Antwortcode ist für die zukünftige Verwendung reserviert. Der ursprüngliche Zweck der Erstellung dieses Codes bestand darin, ihn für digitale Zahlungssysteme zu verwenden, er wird jedoch derzeit nicht verwendet.
	403	Verboten (Verboten)	Der Server hat die Anforderung verstanden, weigert sich jedoch, sie zu erfüllen, da der Zugriff des Clients auf die angegebene Ressource eingeschränkt ist. Der Client hat keine Zugriffsrechte auf den Inhalt, daher weigert sich der Server, eine korrekte Antwort zu geben. Der wahrscheinlichste Grund für die Einschränkung ist ein Versuch, auf Systemressourcen des Webservers zuzugreifen (z. B. .htaccess- oder .htpasswd-Dateien) oder Dateien, denen der Zugriff mithilfe von Konfigurationsdateien verweigert wurde.
	404	Nicht gefunden (nicht gefunden)	Der Server kann die angeforderte Ressource nicht finden. Der Hauptgrund ist ein Fehler in der Schreibweise der Webseitenadresse. Dieser Antwortcode ist aufgrund seiner Verbreitung im Internet wahrscheinlich der bekannteste.
	405	Methode nicht erlaubt	Die Anforderungsmethode ist dem Server bekannt, wurde jedoch deaktiviert und kann nicht verwendet werden. In der Antwort muss der Server die verfügbaren Methoden im Allow-Header angeben, getrennt durch ein Komma. Die beiden erforderlichen Methoden GET und HEAD dürfen niemals deaktiviert werden und dürfen diesen Fehlercode nicht zurückgeben.
	406	Inakzeptabel	Der angeforderte URI kann die im Header übergebenen Merkmale nicht erfüllen. Wenn die Methode nicht HEAD war, MUSS der Server eine Liste gültiger Merkmale für die angegebene Ressource zurückgeben.
	407	Proxy-Authentifizierung erforderlich	Diese Antwort ähnelt 401 , aber hier erfolgt die Authentifizierung gegenüber dem Proxyserver.
	408	Zeitüberschreitung der Anforderung	Der Server hat beim Warten auf eine Übertragung vom Client das Zeitlimit überschritten. Das bedeutet, dass der Server diese ungenutzte Verbindung trennen möchte. Beachten Sie, dass einige Server die Verbindung einfach schließen, ohne diese Nachricht zu senden.
	409	Konflikt (Konflikt)	Diese Antwort wird gesendet, wenn eine Anfrage mit dem aktuellen Status des Servers in Konflikt steht. Dies ist beispielsweise möglich, wenn zwei Clients versuchen, eine Ressource mit der PUT-Methode zu ändern.
	410	Weg (entfernt)	Diese Antwort wird gesendet, wenn der angeforderte Inhalt unter der angegebenen URL vom Server entfernt wurde. In diesem Fall kennt der Server auch nicht den Ort des alternativen Dokuments (beispielsweise einer Kopie).
	411	Länge erforderlich	Der Server hat die Anfrage zurückgewiesen, weil das Header-Feld Content-Length nicht definiert ist und der Server es benötigt. Diese Antwort ist für POST- und PUT-Anforderungen natürlich. Zum Beispiel, wenn Dateien unter dem angegebenen URI heruntergeladen werden und der Server eine Größenbeschränkung hat.
	412	Vorbedingung fehlgeschlagen	Der Client hat bedingte Felder in den Anforderungsheadern angegeben (z. B. If-Match usw.), die der Server nicht erfüllt.
	413	Nutzlast zu groß. Früher – Anforderungsentität zu groß	Das Anforderungsobjekt ist größer als die auf dem Server definierten Grenzwerte. Der Server KANN die Verbindung schließen, um die weitere Übertragung der Anfrage zu stoppen, oder ein Retry-After-Header-Feld zurückgeben, das die Zeit angibt, nach der eine ähnliche Anfrage wiederholt werden kann.
	414	URI zu lang. Früher - Anforderungs-URI zu lang	Der vom Client angeforderte URI ist zu lang, um vom Server verarbeitet zu werden. Ein solcher Fehler kann beispielsweise provoziert werden, wenn der Client versucht, lange Parameter über die GET-Methode statt über POST zu übergeben.
	415	Nicht unterstützter Medientyp	Das Format der angeforderten Datentypen wird vom Server nicht unterstützt, daher lehnt der Server die Anforderung ab. Aus irgendeinem Grund weigert sich der Server, mit dieser Methode mit dem angegebenen Datentyp zu arbeiten.
	416	Bereich nicht erfüllbar. Zuvor - Angeforderter Bereich nicht erfüllbar	Der durch das Range-Header-Feld in der Anforderung angegebene Bereich kann nicht erfüllt werden; Es ist möglich, dass der Bereich außerhalb der Datengröße des Ziel-URI liegt und das Feld „If-Range“ fehlt.
	417	Erwartung fehlgeschlagen	Dieser Antwortcode zeigt an, dass die Wartezeit, die durch das Kopfzeilenfeld „Expect“ der Anforderung angegeben wird, vom Server nicht erfüllt werden konnte.
	421	Fehlgeleitete Anfrage	Die Anfrage wurde an einen Server umgeleitet, der nicht antworten konnte.
	451	Aus rechtlichen Gründen nicht verfügbar (Aus rechtlichen Gründen nicht verfügbar)	Der Zugriff auf die Ressource wird aus rechtlichen Gründen gesperrt (z. B. auf Antrag von Behörden oder auf Antrag des Urheberrechtsinhabers im Falle einer Urheberrechtsverletzung). Eingeführt in einem IETF-Entwurf von Google, wobei der Fehlercode ein Verweis auf Ray Bradburys Roman Fahrenheit 451 ist. Es wurde am 21. Dezember 2015 in den Standard aufgenommen.
Serverfehler
	500	interner Serverfehler	Der Server ist auf eine Situation gestoßen, in der er nicht weiß, was er tun soll. Jeder interne Serverfehler, der nicht von den restlichen Klassenfehlern abgedeckt wird.
	501	Nicht implementiert	Die Anfragemethode wird vom Server nicht unterstützt und kann nicht verarbeitet werden. Eine typische Antwort für Fälle, in denen der Server die in der Anfrage angegebene Methode nicht versteht. Die einzigen Methoden, die vom Server unterstützt werden müssen (und daher diesen Code nicht zurückgeben sollten), sind GET und HEAD .
	502	Schlechtes Tor	Diese Fehlerantwort bedeutet, dass der Server, der als Gateway fungiert, um die zur Verarbeitung der Anforderung erforderliche Antwort zu erhalten, eine ungültige Antwort erhalten hat. Der als Gateway oder Proxy fungierende Server hat eine ungültige Antwortnachricht von einem Upstream-Server erhalten.
	503	Dienst nicht verfügbar	Der Server ist nicht bereit, die Anfrage zu verarbeiten. Der Server kann Anfragen aus technischen Gründen (Wartung, Überlastung etc.) vorübergehend nicht bearbeiten. Bitte beachten Sie, dass zusammen mit dieser Antwort eine benutzerfreundliche Seite gesendet werden sollte, auf der das Problem erläutert wird. Diese Antworten sollten für vorübergehende Bedingungen verwendet werden, und der Retry-After-HTTP-Header sollte nach Möglichkeit eine geschätzte Zeit bis zur Wiederherstellung des Dienstes enthalten. Der Webmaster sollte auch die Caching-bezogenen Header im Auge behalten, die mit dieser Antwort gesendet werden, da diese temporären Antworten normalerweise nicht zwischengespeichert werden.
	504	Gateway Timeout (Gateway antwortet nicht)	Diese Fehlerantwort wird bereitgestellt, wenn der Server als Gateway fungiert und nicht rechtzeitig eine Antwort erhalten kann. Der Server in der Rolle des Gateways oder Proxys hat nicht auf eine Antwort vom Upstream-Server gewartet, um die aktuelle Anfrage abzuschließen.
	505	HTTP-Version wird nicht unterstützt	Die in der Anforderung verwendete Version des HTTP-Protokolls wird vom Server nicht unterstützt (oder der Server verweigert die Unterstützung der angegebenen Version).
	509	Bandbreitenlimit überschritten	Dieser Code wird verwendet, wenn die Website ihre Verkehrsverbrauchsgrenze überschreitet. IN dieser Fall Der Websitebesitzer sollte sich an seinen Hosting-Provider wenden. Derzeit ist dieser Code in keinem RFC beschrieben und wird nur vom „bw/limited“-Modul verwendet, das im cPanel-Hosting-Control-Panel enthalten ist, wo es eingeführt wurde.

-server (Apache oder Nginx) an eine Client-Anfrage besteht aus zwei Teilen: Headern und dem eigentlichen Nachrichtentext.
Um Probleme mit Sites zu diagnostizieren, kann es hilfreich sein, sich speziell die Header anzusehen, da sie einige der Dienstinformationen darüber enthalten, wie der Server funktioniert und die Seite an den Client weitergibt. HTTP/1.1 200 OK Server: nginx Datum: Samstag, 15. Mai 2010 06:04:26 GMT Inhaltstyp: text/html; charset=UTF-8 Connection: close Cache-Control: no-cache,no-store,max-age=0,must-revalidate Inhaltslänge: 6426 Läuft ab: Sa, 15. Mai 06:04:26 2010 GMT Letzte Änderung: Sa 15. Mai 06:04:26 2010 GMT Set-Cookie: S=; Pfad=/; läuft ab=Mittwoch, 17. Mai 2000 06:04:26 GMT Set-Cookie: S=; domain=.ya.ru; Pfad=/; verfällt=Mittwoch, 17. Mai 2000 06:04:26 GMT X-XRDS-Standort: http://openid.yandex.ru/server_xrds/

…

Header werden durch eine Leerzeile vom Nachrichtentext getrennt.
Der HTTP-Server in der ersten Zeile des Headers gibt den Statuscode der Anfrage an.
Anhand des Statuscodes können Sie das Ergebnis der Arbeit des Servers bei der Bearbeitung der Anfrage des Clients beurteilen.

Response-Code-Klassen:

1xx Informativ

Diese Klasse enthält Codes, die über den Übertragungsvorgang informieren.

2xx Erfolg

Nachrichten dieser Klasse informieren über Fälle der erfolgreichen Annahme und Bearbeitung einer Client-Anfrage. Abhängig vom Status sendet der Server möglicherweise auch Header und einen Nachrichtentext.

3xx-Umleitung

Die 3xx-Klassencodes informieren den Client darüber, dass eine weitere Anfrage gestellt werden muss, um die Operation erfolgreich abzuschließen (normalerweise über einen anderen Link). Von dieser Klasse beziehen sich fünf Codes 301, 302, 303, 305 und 307 direkt auf Weiterleitungen. Die Adresse, an die der Client die Anfrage stellen soll, wird vom Server im Location-Header angegeben.

Sie können den Server-Antwortcode für eine bestimmte Anfrage mit dem Dienstprogramm herausfinden kräuseln indem Sie es mit dem Schalter -I aufrufen.
Der Curl-Befehl kann von verwendet werden Befehlszeile*nixartig Betriebssystem, indem Sie sich beispielsweise über beim Server anmelden.
Lassen Sie uns damit yandex.ru anfordern:

curl -ich http://yandex.ru

und bekomme folgende Antwort:

HTTP/1.1 301 Permanent verschoben Datum: Samstag, 15. Mai 2010 05:39:40 GMT Server: Apache/2.2.9 (Unix) mod_perl/2.0.4 Perl/v5.8.8 Ort: http://www.yandex.ru / Variieren: Accept-Encoding Connection: close Content-Type: text/html; Zeichensatz=iso-8859-1

Der Yandex-Server hat auf die Anfrage von yandex.ru mit dem Code „301 Moved Permanently“ geantwortet, was, wie oben erwähnt, bedeutet, dass die Anfrage an der vom Server vorgeschlagenen Adresse abgeschlossen werden muss (diese Adresse ist im Header „Location“ angegeben). , und in diesem Fall ist es www.yandex.ru) .
Der Server teilt uns mit, dass wir nicht yandex.ru, sondern www.yandex.ru kontaktieren müssen.

Anfrage www.yandex.ru:

Curl -Ich http://www.yandex.ru

wir bekommen die antwort:

HTTP/1.1 200 OK Server: nginx Datum: Samstag, 15. Mai 2010 06:01:26 GMT Inhaltstyp: text/html; charset=UTF-8 Connection: close Cache-Control: no-cache,no-store,max-age=0,must-revalidate Content-Length: 73507 Läuft ab: Sa, 15. Mai 06:01:27 2010 GMT Letzte Änderung: Sa 15. Mai 06:01:27 2010 GMT Set-Cookie: S=; Pfad=/; läuft ab=Mittwoch, 17. Mai 2000 06:01:26 GMT Set-Cookie: S=; domain=.yandex.ru; Pfad=/; läuft ab=Mittwoch, 17. Mai 2000 06:01:26 GMT Set-Cookie: yandexuid=3572906971273903287; domain=.yandex.ru; Pfad=/; verfällt=Di, 12. Mai 2020 06:01:26 GMT X-XRDS-Standort: http://openid.yandex.ru/server_xrds/

Antwortcode "200 OK". Der Server hat die Anfrage korrekt ausgeführt und das Ergebnis an den Benutzer zurückgegeben.

4xx-Client-Fehler

Die Codeklasse 4xx soll Fehler auf der Client-Seite anzeigen.

400 Ungültige Anfrage

Die Anfrage wurde vom Server aufgrund eines Syntaxfehlers nicht akzeptiert. Der Client sollte mit der geänderten Anforderung erneut auf die Ressource zugreifen.

401 nicht Autorisiert

Die Anfrage erfordert eine Benutzerautorisierung. Der Server sollte den Benutzer nach einem Benutzernamen und einem Passwort fragen. Wenn falsche Daten angegeben wurden, gibt der Server denselben Status erneut zurück. Beispielsweise erfordert unser Überwachungssystem die Bereitstellung eines Logins und eines Passworts, um auf das System zugreifen zu können.
Beim Anfordern einer Überwachungsseite gibt der Server die folgenden Header zurück:

curl -I http://monitoring.z8.ru

Der Server antwortet, dass er kein Ergebnis zurückgeben wird, bis der Benutzername/das Passwort bereitgestellt wird:

HTTP/1.1 401 Autorisierung erforderlich Server: nginx/0.5.7 Datum: Samstag, 15. Mai 2010 06:16:23 GMT Inhaltstyp: text/html; charset=iso-8859-1 Transfer-Encoding: chunked Connection: keep-alive WWW-Authenticate: Basic realm="Nagios Access"

403 Verboten

Der Server hat beim Versuch, ein Verzeichnis zu durchsuchen, dem der Zugriff verweigert wurde, einen 403-Fehler zurückgegeben. Der Server hat die Anforderung verstanden, weigert sich jedoch, sie zu erfüllen, da der Zugriff des Clients auf die angegebene Ressource eingeschränkt ist. Wenn für den Zugriff auf die Ressource eine HTTP-Authentifizierung erforderlich ist, gibt der Server die Antwort 401 zurück. Andernfalls wurden die Einschränkungen vom Serveradministrator oder dem Entwickler der Webanwendung festgelegt und können je nach den Fähigkeiten der verwendeten Software beliebig sein. Die wahrscheinlichsten Gründe für die Einschränkung sind:

• Es wurde versucht, auf Systemressourcen des Webservers (z. B. .htaccess- oder .htpasswd-Dateien) oder auf Dateien zuzugreifen, denen der Zugriff durch Serverzugriffseinstellungen verweigert wurde.
• Der Zugriff erfordert eine Nicht-HTTP-Authentifizierung (z. B. für den Zugriff auf das CMS oder den Bereich für registrierte Benutzer).
• Der Server ist mit der IP-Adresse des Clients nicht zufrieden (z. B. vorübergehende Sperrung aufgrund häufiger Zugriffe oder in der Entwicklungsphase der Anwendung wird der Zugriff nur auf bestimmte IPs erlaubt).
• Im angeforderten Verzeichnis ist keine Indexdatei vorhanden.

404 Nicht gefunden

Der Server hat die Anfrage verstanden, aber die entsprechende Ressource unter dem angegebenen Link nicht gefunden. Fordern Sie eine nicht vorhandene Seite an:

curl -I http://yandex.ru/instr/index.php

Und wir bekommen eine 404-Antwort:

HTTP/1.1 404 Not Found Datum: Samstag, 15. Mai 2010 06:56:24 GMT Server: Apache/2.2.9 (Unix) mod_perl/2.0.4 Perl/v5.8.8 Accept-Ranges: bytes Vary: Accept-Encoding Connection : schließen Inhaltstyp: text/html

405-Methode nicht zulässig

Die vom Client angegebene Anforderungsmethode kann nicht auf die aktuelle Ressource angewendet werden.

499 Client-Closed-Request (Nginx)

Dieser Fehler bedeutet, dass der Client die Verbindung geschlossen hat, bevor der Server etwas an ihn gesendet hat. In vielen Fällen ist 499 in Ordnung. Angenommen, der Client hat den Browser geschlossen, bevor die gerade geöffnete Seite geladen werden konnte (oder Bilder von der gerade geöffneten Seite heruntergeladen hat). Seite öffnen). Es ist jedoch erwähnenswert, dass Yandex.Metrica beim Empfang von Code 499 davon ausgeht, dass der Server nicht verfügbar ist.

5xx-Serverfehler

5xx-Codes werden für Fälle von erfolglosem Betrieb aufgrund eines Fehlers des Servers vergeben.

500 Interner Serverfehler

Jeder interne Serverfehler, der nicht von den anderen Fehlern der 5xx-Klasse abgedeckt wird. Es kann hauptsächlich in folgenden Fällen auftreten:

• Benutzerfehler in der .htaccess-Datei.
• Fehler in Benutzerskripten.
• Probleme auf dem Server

502 Bad Gateway

Der Server in der Rolle des Gateways oder Proxys hat eine Nachricht erhalten, dass eine Zwischenoperation fehlgeschlagen ist. Normalerweise tritt das Problem auf, wenn der HTTP-Server aufgrund von nicht verfügbar ist Technische Probleme, oder Client-Skripts verfügen nicht über genügend Arbeitsspeicher/Zeit, um die Anforderung abzuschließen.

503 Dienst nicht verfügbar

Der Server kann Anfragen aus technischen Gründen vorübergehend nicht verarbeiten. Auf unserem Hosting zeigt dieser Fehler an, dass der Benutzer das Limit für die Anzahl der HTTP-Server-Handler oder die Gesamtzahl der Prozesse pro Konto überschritten hat.

Die Einführung neuer Codes sollte nur nach Rücksprache mit der IETF erfolgen. Es werden jedoch zwei bekannte Codes verwendet, die im RFC nicht erwähnt werden: 449 Retry With . Der erläuternde Ausdruck "Antworten mit" wird auch in der Spezifikation für erwähnt webdav in Microsoft-Entwicklernetzwerk, eingeführt Microsoft und 509 Bandwidth Limit Exceeded eingeführt in cPanel. Gesellschaft Google schlug dem IETF-Komitee vor, den HTTP-Code 451 zu verwenden, um die absichtliche Sperrung von Portalen zu melden.

Der Client kennt möglicherweise nicht alle Statuscodes, aber er muss entsprechend der Codeklasse reagieren. Derzeit gibt es fünf Klassen von Statuscodes.

Webserver Internet-Informationsdienste In seinen Protokolldateien verwendet es zusätzlich zu den Standardstatuscodes Untercodes, die mit einem Punkt nach dem Hauptcode geschrieben werden. Gleichzeitig wird dieser Subcode nicht in Antworten vom Server eingefügt – er wird vom Serveradministrator benötigt, damit er die Ursachen von Problemen genauer bestimmen kann.

Übersichtsliste

Nachfolgend finden Sie eine Übersichtsliste aller in diesem Artikel beschriebenen Antwortcodes:

• (informativ):
• (erfolgreich):
• (umleiten):
• (Client-Fehler):
• (Serverfehler):

Beschreibung der Codes

Informativ

Diese Klasse enthält Codes, die über den Übertragungsvorgang informieren. Beim Durcharbeiten der Protokollversion 1.0 sollten Nachrichten mit solchen Codes ignoriert werden. In Version 1.1 muss der Client darauf vorbereitet sein, diese Nachrichtenklasse als normale Antwort zu akzeptieren, aber der Server muss nichts senden. Die Nachrichten vom Server selbst enthalten nur die Response-Startzeile und ggf. einige Response-spezifische Header-Felder. Proxy-Server sollten solche Nachrichten weiter vom Server zum Client senden.

• 100 Weiter - Der Server ist mit den anfänglichen Informationen über die Anfrage zufrieden, der Client kann weiterhin Header senden. Eingeführt in HTTP/1.1.
• 101 Switching Protocols – der Server bietet an, zu einem geeigneteren Protokoll für die angegebene Ressource zu wechseln; Der Server muss die Liste der vorgeschlagenen Protokolle im Feld Update-Header angeben. Wenn der Client daran interessiert ist, sendet er eine neue Anfrage, die ein anderes Protokoll angibt. Eingeführt in HTTP/1.1.
• 102 Processing - Die Anfrage wurde akzeptiert, aber die Bearbeitung dauert lange. Wird vom Server verwendet, um zu verhindern, dass der Client die Verbindung aufgrund einer Zeitüberschreitung beendet. Der Client muss beim Empfang einer solchen Antwort den Zeitgeber zurücksetzen und auf den nächsten Befehl im normalen Modus warten. Erschien in webdav.

Erfolg

Nachrichten dieser Klasse informieren über Fälle der erfolgreichen Annahme und Bearbeitung einer Client-Anfrage. Abhängig vom Status sendet der Server möglicherweise auch Header und einen Nachrichtentext.

umleiten

Codes in dieser Klasse teilen dem Client mit, dass eine weitere Anforderung gestellt werden muss, damit die Operation erfolgreich ist, normalerweise unter einem anderen URI . Von dieser Klasse beziehen sich fünf Codes , , und direkt auf Weiterleitungen. Die Adresse, an die der Client die Anfrage stellen soll, wird vom Server im Location-Header angegeben. Dadurch können Fragmente im Ziel-URI verwendet werden.

Nach neuesten Standards kann der Client nur dann ohne Rückfrage des Benutzers umleiten, wenn die zweite Ressource mit der GET- oder HEAD-Methode angefordert wird. Frühere Spezifikationen besagten, dass der Benutzer nach der 5. Weiterleitung in Folge gefragt werden sollte, um Roundtrips zu vermeiden. Wenn die Anfragemethode nicht HEAD war, sollte bei allen Weiterleitungen eine kurze Hypertext-Nachricht mit der Zieladresse im Antworttext enthalten sein, damit der Benutzer im Fehlerfall selbst navigieren kann.

HTTP-Entwickler stellen fest, dass viele Clients beim Umleiten mit 301- und 302-Codes fälschlicherweise die GET-Methode auf die zweite Ressource anwenden, obwohl die erste Anfrage mit einer anderen Methode (meistens PUT) erfolgte. Um Verwirrung zu vermeiden, wurden 303 und 307 in HTTP/1.1 eingeführt und es wird empfohlen, sie anstelle von 302 zu verwenden. Sie müssen die Methode nur ändern, wenn der Server mit 303 geantwortet hat. In anderen Fällen erfolgt die nächste Anfrage mit der ursprünglichen Methode.

Das Verhalten von Clients für verschiedene Redirects ist in der Tabelle beschrieben:

• 300 Multiple Choices – Unter dem angegebenen URI gibt es mehrere Optionen zum Bereitstellen einer Ressource nach MIME-Typ, nach Sprache oder nach anderen Merkmalen. Der Server sendet mit der Nachricht eine Liste von Alternativen, die eine automatische Auswahl durch den Client oder den Benutzer ermöglicht. Eingeführt in HTTP/1.0.
• 301 Moved Permanently – Das angeforderte Dokument wurde dauerhaft an den neuen URI verschoben, der im Kopfzeilenfeld „Location“ angegeben ist. Einige Clients verhalten sich bei der Verarbeitung dieses Codes falsch. Eingeführt in HTTP/1.0.
• 302 gefunden, 302 vorübergehend verschoben – Das angeforderte Dokument ist vorübergehend unter einem anderen URI verfügbar, der in der Kopfzeile im Feld Standort angegeben ist. Dieser Code kann beispielsweise bei der servergesteuerten Inhaltsaushandlung verwendet werden. Einige Clients verhalten sich bei der Verarbeitung dieses Codes falsch. Eingeführt in HTTP/1.0.
• 303 See Other – Das Dokument mit dem angeforderten URI muss unter der Adresse im Location-Feld des Headers mit der GET-Methode angefordert werden, obwohl ersteres mit einer anderen Methode angefordert wurde. Dieser Code wurde zusammen mit 307 eingeführt, um Mehrdeutigkeiten zu vermeiden, damit der Server sicher sein kann, dass die nächste Ressource mit der GET-Methode angefordert wird. Beispielsweise verfügt eine Webseite über ein Texteingabefeld für die schnelle Navigation und Suche. Nach Eingabe der Daten stellt der Browser eine Anfrage mit der POST-Methode, einschließlich des eingegebenen Textes im Hauptteil der Nachricht. Wenn ein Dokument mit dem eingegebenen Titel gefunden wird, antwortet der Server mit einem 303-Code, der seine permanente Adresse im Location-Header angibt. Dann wird der Browser es garantiert mit der GET-Methode anfordern, um den Inhalt zu erhalten. Andernfalls gibt der Server einfach die Suchergebnisseite an den Client zurück. Eingeführt in HTTP/1.1.
• 304 Not Modified – Der Server gibt diesen Code zurück, wenn der Client das Dokument mit der GET-Methode angefordert hat, den If-Modified-Since- oder If-None-Match-Header verwendet hat und das Dokument seit dem angegebenen Zeitpunkt nicht geändert wurde. In diesem Fall darf die Servernachricht keinen Body enthalten. Eingeführt in HTTP/1.0.
• 305 Proxy verwenden – Die Anforderung an die angeforderte Ressource muss über einen Proxy-Server erfolgen, dessen URI im Header-Feld „Location“ angegeben ist. Dieser Antwortcode kann nur von Ursprungs-HTTP-Servern (nicht Proxys) verwendet werden. Eingeführt in HTTP/1.1.
• 306 (reserviert) - Der zuvor verwendete Antwortcode ist derzeit reserviert. Erwähnt in RFC 2616 (HTTP/1.1-Update).
• 307 Temporäre Umleitung – Die angeforderte Ressource ist kurzzeitig unter einem anderen URI verfügbar, der im Header-Feld „Location“ angegeben ist. Dieser Code wurde zusammen mit 303 anstelle von 302 eingeführt, um Mehrdeutigkeiten zu vermeiden. Eingeführt in RFC 2616 (HTTP/1.1-Update).

Client-Fehler

Die Codeklasse 4xx soll Fehler auf der Client-Seite anzeigen. Wenn alle Methoden außer HEAD verwendet werden, muss der Server eine Hypertext-Erklärung für den Benutzer im Hauptteil der Nachricht zurückgeben.

• 400 Bad Request – Der Server hat einen Syntaxfehler in der Client-Anfrage festgestellt. Eingeführt in HTTP/1.0.
• 401 Nicht autorisiert – Die Anforderung erfordert eine Benutzeridentifikation. Der Server sollte einen Benutzernamen und ein Passwort vom Benutzer anfordern, der sie bei der nächsten Anfrage im WWW-Authenticate-Header weitergibt. Wenn falsche Daten angegeben wurden, gibt der Server denselben Status erneut zurück. Eingeführt in HTTP/1.0.
• 402 Zahlung erforderlich – wird voraussichtlich in Zukunft verwendet. Derzeit nicht in Gebrauch. Dieser Code gilt für kostenpflichtige Benutzerdienste, nicht für Hosting-Unternehmen. Dies bedeutet, dass dieser Fehler vom Hosting-Provider im Falle einer überfälligen Zahlung für seine Dienste nicht ausgegeben wird. Reserviert seit HTTP/1.1.

Der Server hat einen 403-Fehler zurückgegeben, als er versuchte, das Verzeichnis „cgi-bin“ zu durchsuchen, auf das der Zugriff verweigert wurde.

• 403 Forbidden – Der Server hat die Anforderung verstanden, weigert sich jedoch, sie zu erfüllen, da der Zugriff des Clients auf die angegebene Ressource eingeschränkt ist. Wenn der Zugriff auf eine Ressource eine HTTP-Authentifizierung erfordert, gibt der Server eine Antwort zurück oder wenn ein Proxy verwendet wird. Andernfalls wurden die Grenzwerte vom Serveradministrator oder dem Entwickler der Webanwendung festgelegt und können je nach den Fähigkeiten der verwendeten Software variieren . In jedem Fall sollten dem Kunden die Gründe für die Ablehnung der Bearbeitung des Antrags mitgeteilt werden. Die wahrscheinlichsten Gründe für die Einschränkung können ein Versuch sein, auf die Systemressourcen des Webservers zuzugreifen (z. B. .htaccess- oder .htpasswd-Dateien) oder Dateien, denen der Zugriff mithilfe von Konfigurationsdateien verweigert wurde, die eine Nicht-HTTP-Authentifizierung erfordern, z B. um auf das System-Content-Management oder den Bereich für registrierte Benutzer zuzugreifen, oder der Server ist beispielsweise beim Sperren nicht mit der IP-Adresse des Clients zufrieden. Eingeführt in HTTP/1.0.
• 404 Not Found ist der häufigste Fehler bei der Nutzung des Internets, der Hauptgrund ist ein Fehler beim Schreiben der Adresse einer Webseite. Der Server hat die Anfrage verstanden, aber keine übereinstimmende Ressource unter der angegebenen URI gefunden. Wenn der Server weiß, dass an dieser Adresse ein Dokument vorhanden war, ist es wünschenswert, den Code zu verwenden. Die 404-Antwort kann stattdessen verwendet werden, wenn Sie bestimmte Ressourcen sorgfältig vor neugierigen Blicken verbergen möchten. Eingeführt in HTTP/1.0.
• 405 Methode nicht erlaubt – Die vom Client angegebene Methode kann nicht auf die aktuelle Ressource angewendet werden. In der Antwort muss der Server die verfügbaren Methoden im Allow-Header angeben, getrennt durch ein Komma. Der Server sollte diesen Fehler zurückgeben, wenn ihm die Methode bekannt ist, aber nicht speziell auf die in der Anfrage angegebene Ressource anwendbar ist, aber wenn die angegebene Methode nicht auf dem gesamten Server anwendbar ist, muss der Client den Code zurückgeben. Eingeführt in HTTP/1.1.
• 406 Not Acceptable – Der angeforderte URI kann die im Header übergebenen Merkmale nicht erfüllen. Wenn die Methode nicht HEAD war, MUSS der Server eine Liste gültiger Merkmale für die angegebene Ressource zurückgeben. Eingeführt in HTTP/1.1.
• 407 Proxy-Authentifizierung erforderlich – Die Antwort ähnelt dem Code, außer dass die Authentifizierung für einen Proxyserver durchgeführt wird. Der Mechanismus ähnelt der Authentifizierung auf dem Ursprungsserver. Eingeführt in HTTP/1.1.
• 408 Request Timeout – Der Server hat beim Warten auf eine Übertragung vom Client eine Zeitüberschreitung. Der Client kann die Anfrage jederzeit ähnlich der vorherigen wiederholen. Eine solche Situation kann beispielsweise auftreten, wenn eine große Datei mit der POST- oder PUT-Methode auf den Server hochgeladen wird. Irgendwann während der Übertragung reagierte die Datenquelle nicht mehr, beispielsweise aufgrund einer Beschädigung der CD oder eines Kommunikationsverlusts mit einem anderen Computer im lokalen Netzwerk. Solange der Client nichts sendet und auf eine Antwort von ihm wartet, wird die Verbindung zum Server aufrechterhalten. Nach einiger Zeit kann der Server die Verbindung auf seiner Seite schließen, damit andere Clients eine Anfrage stellen können. Diese Antwort wird nicht zurückgegeben, wenn der Client die Übertragung auf Befehl des Benutzers zwangsweise beendet hat oder die Verbindung aus einem anderen Grund unterbrochen wurde, da die Antwort nicht mehr gesendet werden kann. Eingeführt in HTTP/1.1.
• 409 Konflikt – Die Anforderung kann aufgrund einer widersprüchlichen Ressourcenanforderung nicht abgeschlossen werden. Dies ist beispielsweise möglich, wenn zwei Clients versuchen, eine Ressource mit der PUT-Methode zu ändern, eingeführt in HTTP/1.1.
• 410 Gone - Der Server sendet eine solche Antwort, wenn sich die Ressource früher unter der angegebenen URL befand, aber gelöscht wurde und jetzt nicht verfügbar ist. Der Server kennt in diesem Fall auch nicht den Ort des alternativen Dokuments, beispielsweise einer Kopie). Wenn der Server den Verdacht hat, dass das Dokument in naher Zukunft wiederhergestellt werden kann, ist es besser, die . Eingeführt in HTTP/1.1.
• 411 Länge erforderlich – Für die angegebene Ressource muss der Client eine Inhaltslänge im Anforderungsheader angeben. Ohne Angabe dieses Felds sollten Sie die Anforderung an den Server für diesen URI nicht wiederholen. Diese Antwort ist für POST- und PUT-Anforderungen natürlich. Zum Beispiel, wenn Dateien unter dem angegebenen URI heruntergeladen werden und ihr Volumen auf dem Server begrenzt ist. Dann wäre es klüger, gleich zu Beginn den Content-Length-Header zu prüfen und den Download sofort zu verweigern, als durch einen Verbindungsabbruch eine sinnlose Last zu provozieren, wenn der Client wirklich eine zu große Nachricht sendet. Eingeführt in HTTP/1.1.
• 412 Vorbedingung fehlgeschlagen – Wird zurückgegeben, wenn keines der bedingten Header-Felder [ unbekannter Begriff] Anfrage wurde nicht abgeschlossen. Eingeführt in HTTP/1.1.
• 413 Anforderungsentität zu groß – wird zurückgegeben, wenn der Server die Verarbeitung der Anforderung ablehnt, weil der Anforderungstext zu groß ist. Der Server KANN die Verbindung schließen, um die weitere Übertragung der Anfrage zu stoppen. Wenn das Problem vorübergehend ist, wird empfohlen, einen Retry-After-Header in die Serverantwort aufzunehmen, der die Zeit angibt, nach der eine ähnliche Anfrage wiederholt werden kann. Eingeführt in HTTP/1.1.
• 414 Anfrage-URL zu lang – Der Server kann die Anfrage nicht verarbeiten, da die angegebene URL zu lang ist. Ein solcher Fehler kann beispielsweise provoziert werden, wenn der Client versucht, lange Parameter über die GET-Methode statt über POST zu übergeben. Eingeführt in HTTP/1.1.
• 415 Nicht unterstützter Medientyp - Aus irgendeinem Grund weigert sich der Server, mit dieser Methode mit dem angegebenen Medientyp zu arbeiten. Eingeführt in HTTP/1.1.
• 416 Angeforderter Bereich nicht erfüllbar – Im Bereichsfeld des Anforderungsheaders wurde ein Bereich außerhalb der Ressource angegeben, und es gibt kein If-Range-Feld. Wenn der Client einen Byte-Bereich gesendet hat, kann der Server die tatsächliche Größe im Content-Range-Header-Feld zurückgeben. Diese Antwort sollte nicht verwendet werden, wenn multipart/byteranges übergeben werden. Eingeführt in RFC 2616 (HTTP/1.1-Update).
• 417 Expectation Failed – Aus irgendeinem Grund kann der Server den Wert des Expect-Felds im Anforderungsheader nicht erfüllen. Eingeführt in RFC 2616 (HTTP/1.1-Update).
• 422 Unprocessable Entity – Der Server hat die Anfrage erfolgreich akzeptiert, kann mit dem angegebenen Datentyp arbeiten, das XML-Dokument im Hauptteil der Anfrage hat die richtige Syntax, aber es gibt einen logischen Fehler, aufgrund dessen dies nicht möglich ist Ausführen einer Operation für die Ressource. Eingeführt in webdav.
• 423 Gesperrt – Die Zielressource aus der Anforderung ist daran gehindert, die angegebene Methode darauf anzuwenden. Eingeführt in webdav.
• 424 Fehlgeschlagene Abhängigkeit – Die Implementierung der aktuellen Anforderung kann vom Erfolg einer anderen Operation abhängen. Wenn es nicht ausgeführt wird und es daher unmöglich ist, die aktuelle Anfrage auszuführen, gibt der Server diesen Code zurück. Eingeführt in webdav.
• 425 Ungeordnete Sammlung - gesendet, wenn der Client eine Anfrage gesendet hat, durch Festlegen einer Position in einer unsortierten Sammlung oder durch Verwenden einer anderen Reihenfolge von Elementen als auf der Serverseite [klären] . Eingeführt im Entwurf von WebDAV Advanced Collections Protocol .
• 426 Upgrade erforderlich – Der Server weist den Client an, das Protokoll zu aktualisieren. Der Antwortheader muss wohlgeformte Upgrade- und Verbindungsfelder enthalten. Eingeführt in RFC 2817, um den Übergang zu TLS über HTTP zu ermöglichen.
• 449 Retry With – wird vom Server zurückgegeben, wenn nicht genügend Informationen vom Client empfangen wurden, um die Anfrage zu verarbeiten. Dadurch wird das Ms-Echo-Request-Feld in den Antwortheader eingefügt. Eingeführt von der Gesellschaft Microsoft zum webdav. Derzeit zumindest vom Programm verwendet Microsoft Money.
• 456 Nicht behebbarer Fehler – Wird vom Server zurückgegeben, wenn die Abfrageverarbeitung nicht behebbare Abstürze in Datenbanktabellen verursacht. Eingeführt von der Gesellschaft Microsoft zum webdav.

Serverfehler

5xx-Codes werden für Fälle von erfolglosem Betrieb aufgrund eines Fehlers des Servers vergeben. Für alle anderen Situationen als die Verwendung der HEAD-Methode MUSS der Server eine Erklärung in den Text der Nachricht aufnehmen, die der Client dem Benutzer anzeigt.

siehe auch

Anmerkungen

Verknüpfungen

Die wichtigsten Dokumente zum HTTP-Protokoll (in absteigender Reihenfolge des Veröffentlichungsdatums):

• HTTP-Statuscoderegistrierung (Hypertext Transfer Protocol). IANA (17. Oktober 2007). - Registrierung von HTTP-Statuscodes. Archiviert vom Original am 17. Februar 2012. Abgerufen am 30. Juli 2009.
• RFC 2616 Standardentwurf "" (Englisch) (Russisch) ); IETF, Juni 1999; Fielding Roy (Englisch) Russisch (UC Irvine (Englisch) Russisch ), Gettys Jim (Englisch) Russisch (Compaq /W3C), Mogul J. (Compaq), Frystyk Henrik (Englisch) Russisch (MIT/W3C), Masinter L. (Xerox), Leach P. (Microsoft), Berners-Lee Tim (W3C/MIT)- Aktualisierung des HTTP-Protokolls Version 1.1.
• RFC 2068 Vorgeschlagener Standard "Hypertext Transfer Protocol - HTTP/1.1" (Englisch) (Russisch) "Hypertext-Übertragungsprotokoll - HTTP/1.1"); IETF, Januar 1997; Fielding Roy (Englisch) Russisch (UC Irvine (Englisch) Russisch ), Gettys Jim (Englisch) Russisch (DEZ), Mogul J. (DEZ), Frystyk Henrik (Englisch) Russisch (MIT/LCS), Berners-Lee Tim (MIT/LCS)- frühe Spezifikation für HTTP-Version 1.1.
• RFC 1945 Informativ

Wenn der Browser auf die Web-Browsing-Seite zugreift, sendet der Browser eine Anfrage an den Server, wo das Web. Wenn der Browser die erste Seite empfängt und anzeigt, enthält der Server, auf den diese Seite zurückkehrt (Server-Header), im HTTP-Header den Statuscode, um auf die Anfrage zu antworten, den Browser.

HTTP-Statuscodes in Englisch für den HTTP-Statuscode.

Hier sind einige allgemeine HTTP-Statuscodes:

• 200-- Anforderung war erfolgreich
• 301-- Ressourcen (Webseiten usw.) werden ständig auf eine andere URL umgeleitet
• 404 - Angeforderte Ressourcen (Webseiten usw.) sind nicht vorhanden
• 500 - Interner Serverfehler

HTTP-Zustandsklassifizierungscode

Der HTTP-Statuscode besteht aus drei Dezimalziffern, der ersten Dezimalzahl bestimmt die Art der Statuscodes, die letzten beiden Ziffern sind nicht klassifiziert wirksam. Der HTTP-Statuscode ist in fünf Typen unterteilt:

Liste der HTTP-Statuscodes:

Liste der HTTP-Statuscodes

Statuscode	Statuscode Englischer Name	Chinesische Beschreibung
100	fortsetzen	Vorgehen. Der Client muss seine Anfrage fortsetzen
101	Protokollwechsel	Protokolle wechseln. Server-Switching-Protokoll basierend auf Client-Anfrage. Kann nur zu einem fortgeschritteneren Protokoll wechseln, z. B. um auf eine neue Version des HTTP-Protokolls zu aktualisieren
200	In Ordnung	Die Anfrage war erfolgreich. Wird hauptsächlich für GET- und POST-Anforderungen verwendet
201	erstellt	Es wurde kreiert. Erfolgreiche Anfragen und neue Ressource erstellt
202	Empfangen	Empfangen. Wir haben diese Anfrage akzeptiert, aber den Vorgang nicht abgeschlossen
203	Nicht verbindliche Informationen	Unbefugter Zugriff auf Informationen. Die Anfrage war erfolgreich. Allerdings nicht in den vom Server zurückgegebenen Original-Metainformationen, sondern in einer Kopie
204	Kein Inhalt	Leer. Der Server hat den Inhalt erfolgreich verarbeitet, aber nicht zurückgegeben. Wenn keine aktualisierten Seiten vorhanden sind, um sicherzustellen, dass der Browser weiterhin das aktuelle Dokument anzeigt
205	Inhalt zurücksetzen	Inhalt zurücksetzen. Der Verarbeitungsserver ist erfolgreich, das Benutzerendgerät (z. B. Browser) sollte in den Dokumentenansichtsmodus zurückkehren. Dieser Rückgabecode kann die Formularfelder Ihres Browsers löschen
206	Teilinhalt	Teil. Der Server hat einen Teil der GET-Anforderung erfolgreich verarbeitet
300	Mehrfachauswahl	Vielzahl von Optionen. Die Ressourcenanforderung kann eine Vielzahl von Elementen enthalten, die der Rückgabe einer Liste von Ressourceneigenschaften und Adressen für das Benutzerendgerät (zum Beispiel: Browser) entsprechen
301	dauerhaft umgezogen	Dauerhaft umgezogen. Die angeforderte Ressource wurde dauerhaft auf einen neuen URI verschoben, gibt Informationen einschließlich des neuen URI zurück, der Browser wird automatisch zum neuen URI geleitet. Jede zukünftige neue Anforderung muss durch den neuen URI ersetzt werden
302	gefunden	Temporärer Umzug. Wie 301. Aber die Ressource wurde vorübergehend verschoben. Der Client muss weiterhin den ursprünglichen URI verwenden
303	Siehe Andere	Sehen Sie sich eine andere Adresse an. Ähnlich wie 301. Verwenden Sie GET und POST-Anfragen Ansicht
304	Nicht modifiziert	unverändert. Die angeforderte Ressource bleibt unverändert, der Server gibt diesen Statuscode zurück, er gibt keine Ressourcen zurück. Der Client speichert besuchte Ressourcen typischerweise zwischen, indem er einen Header bereitstellt, der angibt, dass der Client erst nach dem angegebenen Datum der modifizierten Ressource zurückkehren möchte
305	Verwenden Sie einen Proxy-Server	Verwenden Sie einen Proxy-Server. Die angeforderte Ressource muss über einen Proxyserver verfügbar sein
306	ungebraucht	Es wurde ein unbeaufsichtigter HTTP-Statuscode hinterlassen
307	Temporäre Umleitung	Temporäre Umleitung. Ähnlich wie 302. Anfrage mit GET wird umgeleitet
400	Ungültige Anforderung	Syntaxfehler in Client-Anforderungen, Server kann nicht verstehen
401	unbefugt	Die Anforderung erfordert eine Benutzerauthentifizierung
402	Zahlung erforderlich	Reserviert für zukünftige Verwendung
403	verboten	Der Server hat die Anfrage des Clients verstanden, sich aber geweigert, diese Anfrage zu erfüllen
404	Nicht gefunden	Der Server kann die vom Client angeforderten (Web-)Ressourcen nicht finden. Mit diesem Code können Website-Entwickler die persönliche Seite „Die von Ihnen angeforderte Ressource kann nicht gefunden werden“ festlegen
405	Methode nicht erlaubt	Kunde weist an, verbotene Methoden
406	Inakzeptabel	Der Server kann die Anforderung basierend auf den vom Client angeforderten Inhaltsmerkmalen nicht erfüllen
407	Erfordert Proxy-Authentifizierung	Die Anfrage erfordert eine Proxy-Authentifizierung wie 401, aber der Absender muss eine Proxy-Autorisierung verwenden
408	Zeitüberschreitung der Anforderung	Der Server wartet zu lange darauf, dass der Client eine Anfrage sendet, Timeout
409	Konflikt	Die Client-PUT-Anforderung zur Ausführung einer Serverkollision kann diesen Code zurückgeben, wenn der Server die Anforderung verarbeitet
410	bestanden	Die vom Client angeforderte Ressource existiert nicht mehr. Anders als bei 410 404 kann der Webdesigner, wenn die Ressource jetzt dauerhaft gelöscht wird, bevor Sie den 410-Code verwenden können, die Ressourcen mit dem neuen Standortcode 301 angeben
411	Länge erforderlich	Der Server konnte die vom Client gesendete Anforderungsnachricht ohne Content-Length nicht verarbeiten
412	Vorbedingung fehlgeschlagen	Voraussetzungen Der Client fordert Fehlerinformationen an
413	Anforderungsgröße zu groß	Da das Anforderungsobjekt zu groß ist, kann der Server es nicht verarbeiten, sodass die Anforderung abgelehnt wird. Um eine kontinuierliche Client-Anfrage zu verhindern, kann der Server die Verbindung schließen. Wenn der Server vorübergehend nicht nur verarbeiten kann, enthält er Informationen über die Retry-After-Antwort
414	Anforderungs-URI zu groß	Der Anforderungs-URI ist zu lang (der URI ist normalerweise eine URL), der Server kann ihn nicht verarbeiten
415	Nicht unterstützter Medientyp	Der Server konnte die mit den Medienformaten gelieferte Anfrage nicht verarbeiten
416	Der angeforderte Bereich ist nicht realisierbar	Client-Anforderungsbereich ungültig
417	Erwartungsfehler	Der Server kann die Anforderung des Expect-Headers nicht erfüllen
500	interner Serverfehler	Interner Serverfehler und die Anfrage konnte nicht abgeschlossen werden
501	Nicht implementiert	Der Server unterstützt die angeforderte Funktion nicht, kann die Anforderung nicht erfüllen
502	Schlechtes Tor	B. ein Gateway-Server oder Proxy-Server erhalten entfernter Server für eine ungültige Anfrage
503	Dienst ist nicht verfügbar	Aufgrund von Überlastung oder Wartung des Systems kann der Server die Anfrage des Clients vorübergehend nicht verarbeiten. Die Länge der Verzögerung kann in den Retry-After-Informationen des Server-Headers enthalten sein
504	Gateway-Zeitüberschreitung	Agieren als Gateway oder Proxy anstelle einer rechtzeitigen Zugriffsanfrage von einem Remote-Server
505	HTTP-Version wird nicht unterstützt	Der Server unterstützt die angeforderte Version des HTTP-Protokolls nicht und beendet die Verarbeitung nicht