In der Webentwicklung spielen HTTP-Fehlercodes eine entscheidende Rolle für die Benutzerfreundlichkeit und Reputation einer Website. In diesem Artikel betrachten wir eine vollständige Liste der Server-Fehlercodes, analysieren ihre Bedeutung und lernen, wie man Server-Antwortcodes effektiv interpretiert, um Probleme zu lösen und die Leistung von Web-Apps zu optimieren.
Was ist ein HTTP-Antwortcode
Der HTTP-Antwortcode ist die Sprache von Webservern, die Browseranfragen in verständliche Anweisungen übersetzt. Er ist wie ein Dichter, der virtuelle Fragen beantwortet und ihnen Bedeutung und Richtung gibt. Antwortcodes sind nicht immer HTTP-Fehlercodes. Beispielsweise bedeutet „200 OK“ alles in Ordnung, während der HTTP-Fehler „404 Not Found“ bedeutet, dass die Seite im virtuellen Raum verloren gegangen ist. Jeder Code ist ein eindeutiger Ausdruck des Serverstatus, dessen Dekodierung es uns ermöglicht zu verstehen, was auf der anderen Seite der virtuellen Welt passiert.
1xx-Codes (Informationen)
1xx-Statuscodes im HTTP-Protokoll sind eine Art erstes Bindeglied im Dialog zwischen Server und Client. Anstatt eine vollständige Antwort auf eine Anfrage zu liefern, liefern sie Informationen über den aktuellen Status und machen den Datenaustausch so effizienter. Schauen wir sie uns genauer an:
100 Continue . HTTP-Antwortcode, mit dem der Server dem Benutzer grünes Licht gibt und ihm erlaubt, eine große Anfrage sicher fortzusetzen.
101. Protokollwechsel . Der Server teilt dem Client mit, dass sich die Kommunikationsregeln ändern, beispielsweise durch den Wechsel von HTTP zum sichereren HTTPS. In diesem Fall wird der „Upgrade“-Header für den Protokollwechsel verwendet.
102 Verarbeitung . Dieser Code ist wie eine Meldung, dass der Server die Anfrage angenommen hat, aber noch mit einer komplexen Operation beschäftigt ist.
103 Frühe Hinweise . Hier sendet der Server vor der eigentlichen Antwort mehrere Hinweis-Header an den Client, die auf etwas hinweisen, das in naher Zukunft relevant sein könnte.
2xx-Code (Erfolgreich)
HTTP-Fehlercodes der Gruppe 2xx signalisieren eine erfolgreiche Anfrage vom Server. Sie fungieren quasi als „grünes Licht“ in der Webkommunikation und bestätigen, dass alles nach Plan läuft und erfolgreich abgeschlossen wurde.
200 OK . Dieser Status wird verwendet, wenn der Server eine GET-Anfrage problemlos verarbeitet und die angeforderten Daten als Antwort zurückgibt. Der Header „Content-Type“ gibt den Inhaltstyp der Antwort an. Er informiert den Client lediglich darüber, dass die Anfrage erfolgreich war.
201 erstellt . Hier verkündet der Server die Erstellung einer neuen Ressource.
202 Akzeptiert . Der Server teilt dem Benutzer mit, dass die Anfrage akzeptiert wurde, benötigt aber etwas Zeit für die Antwort.
203 Nicht-autoritative Informationen . Dieser Code stellt dem Kunden Daten zur Verfügung, die möglicherweise nicht offiziell sind, aber zum Vergleich verwendet werden können.
204 Kein Inhalt . Der Server hat die Anfrage verarbeitet, liefert aber keine weiteren Inhalte zurück.
205 Inhalt zurücksetzen . Hier wird der Client angewiesen, die aktuelle Ansicht oder die Daten nach dem Senden zurückzusetzen.
206 Teilinhalt . Dieser Fall bedeutet, dass die Antwort nur einen Teil des angeforderten Inhalts enthält. Der „Content-Range“-Header gibt den Bereich des Teilinhalts an.
207 Multi-Status. Der Server hat eine Multi-Operations-Anfrage des Clients erfolgreich abgeschlossen, und die Antwort enthält Informationen über den Status jeder einzelnen Operation.
226 IM verwendet . Dieser Code zeigt an, dass der Server die Methode der inkrementellen Metadaten (IM) verwendet und dem Client nur die geänderten Ressourcenteile übermittelt hat.
3xx-Codes (Weiterleitungen)
3xx-Codes im HTTP-Protokoll dienen als Zeiger, die den Benutzer zu einer neuen Ressource führen. Sie informieren den Client darüber, dass weitere Schritte erforderlich sind, um den angeforderten Inhalt abzurufen oder zu einer anderen Ressource weitergeleitet zu werden. Sehen wir uns die Details zu jedem einzelnen Code an:
300 Mehrfachauswahlmöglichkeiten . Der Client erhält ein Signal, dass mehrere mögliche Speicherorte für die Ressource existieren, und kann daraufhin eine Auswahl treffen. Unter den gegebenen Umständen kann der Header „Location“ alternative Optionen für die Ressource angeben.
301 Dauerhaft verschoben. Der Server meldet dem Benutzer, dass die Ressource dauerhaft an einen anderen Speicherort verschoben wurde.
302 Gefunden . Dieser HTTP-Code entspricht einer temporären Weiterleitung. Der Server informiert den Client darüber, dass die Ressource vorübergehend unter einer anderen URL verfügbar ist. Der „Location“-Header verweist auf die neue URL für die temporäre Weiterleitung.
303 See Other . Dem Client wird mitgeteilt, dass die Ressource unter einer anderen URL verfügbar ist und er eine GET-Anfrage an diese neue Adresse senden muss.
304 Nicht verändert . Dieser Status signalisiert dem Client, dass die Ressource seit der letzten Anfrage unverändert geblieben ist und nicht erneut heruntergeladen werden muss. Bei einer Anfrage wird der „If-Modified-Since“-Header verwendet, um zu prüfen, ob die Ressource geändert wurde.
305 Use Proxy. Als Antwort meldet der Server, dass er den angegebenen Proxy verwenden soll, um auf die angeforderte Ressource zuzugreifen.
306 (reserviert) — Der Code ist reserviert, wird aber tatsächlich nicht verwendet.
307 Temporäre Weiterleitung . Dieser Code ähnelt 302 Found, erfordert jedoch, dass der Client die Anfragemethode beibehält, die in der ursprünglichen Anfrage verwendet wurde.
308 Permanente Weiterleitung . Zeigt an, dass die Ressource dauerhaft auf eine neue URI umgezogen ist und der Client die neue URI für alle zukünftigen Anfragen verwenden sollte.
4xx HTTP-Fehler (Client-Fehler)
HTTP 4xx-Fehlercodes weisen auf Clientfehler hin. Das bedeutet, dass das Problem auf der Benutzerseite liegt, beispielsweise beim Webbrowser oder der App.
400 Bad Request . Der Server kann die Anfrage aufgrund von Syntaxfehlern, ungültigen Daten oder anderen Fehlern auf Clientseite nicht verarbeiten.
401 Nicht autorisiert. Der Server kann die Anfrage aufgrund von Syntaxfehlern, ungültigen Daten oder anderen Fehlern auf Clientseite nicht verarbeiten.
Fehler 402: Zahlung erforderlich . Der Code ist momentan nicht aktiv und für die zukünftige Verwendung reserviert. Möglicherweise ist in Zukunft eine Zahlung erforderlich, um auf die Ressource zugreifen zu können.
HTTP-Fehler 403: Verboten. Der Client verfügt nicht über ausreichende Berechtigungen für den Zugriff auf die angeforderte Ressource.
Fehler 404: Die angeforderte Ressource ist auf dem Server nicht vorhanden. Dies ist einer der häufigsten Benutzerfehler.
405 Methode nicht zulässig . Der Server unterstützt die angegebene Anfragemethode für diese Ressource nicht. Der „Allow“-Header gibt die für die Ressource zulässigen Methoden an. Mit diesem Code
406 Nicht akzeptabel. Der Server kann keine Daten in einem vom Client akzeptierten Format bereitstellen.
407 Proxy-Authentifizierung erforderlich . Für den Zugriff auf die angeforderte Ressource ist eine Authentifizierung auf dem Proxy-Server erforderlich.
408 Anfrage-Timeout . Der Server wartete auf eine Anfrage des Clients, aber es trat ein Timeout auf. Der „Retry-After“-Header kann die Zeit angeben, nach der die Anfrage erneut versucht werden kann.
409 Konflikt. Die Anfrage kann aufgrund eines Konflikts mit dem aktuellen Ressourcenstatus nicht abgeschlossen werden.
410 Nicht mehr verfügbar . Die angeforderte Ressource existierte zuvor, wurde aber gelöscht und ihre Wiederherstellung ist nicht zu erwarten.
411 Länge erforderlich . Der Server verlangt die Angabe der Inhaltslänge in der Anfrage; das Fehlen dieser Information wird als Fehler gewertet.
412 Vorbedingung nicht erfüllt . Eine Vorbedingung der Anfrage ist nicht erfüllt, weshalb die Ausführung verhindert wird.
413 Nutzdaten zu groß . Die Größe der angeforderten Daten überschreitet die Servergrenzen.
414 URI zu lang . Die URI-Länge in der Anfrage überschreitet die zulässigen Grenzwerte.
415 Nicht unterstützter Medientyp . Der Server kann den in der Anfrage angegebenen Datentyp nicht verarbeiten.
416 Bereich nicht erfüllbar . HTTP-Fehler, bei dem der angeforderte Bereich nicht mit den aktuellen Serverdaten übereinstimmt.
417 Erwartung fehlgeschlagen . Die erwartete Bedingung im "Expect"-Header wurde nicht erfüllt.
418 Ich bin eine Teekanne . Dieser Code ist als Scherz gedacht und hat keine Auswirkungen auf Benutzer oder Server. Er stellt keinen echten Fehler dar. Er bedeutet lediglich, dass der Server eine Teekanne ist und keinen Kaffee kochen kann.
421 Fehlgeleitete Anfrage . Der Server kann die Anfrage aufgrund eines Fehlers in der Anfrage oder der Serverkonfiguration nicht verarbeiten.
422 Unprocessable Entity . Der Server versteht die Anfrage, kann sie aber aufgrund von Datenfehlern nicht verarbeiten.
423 Gesperrt. Die Ressource ist blockiert und kann nicht verarbeitet werden.
424 Fehlgeschlagene Abhängigkeit . Die Anfrage ist von einer anderen, noch nicht ausgeführten Anfrage abhängig.
425 Zu früh. Der Server ist aufgrund der frühen Anfrage noch nicht bereit, diese zu bearbeiten.
426 Upgrade erforderlich . Der Server benötigt ein moderneres Protokoll zur Verarbeitung der Anfrage.
428 Vorbedingung erforderlich . Der Server verlangt, dass bestimmte Vorbedingungen in der Anfrage angegeben werden.
429 Zu viele Anfragen . Der Client hat innerhalb kurzer Zeit zu viele Anfragen gesendet und damit die Servergrenzen überschritten.
431 Anfrage-Header-Felder zu groß . Die Anfrage-Header überschreiten die maximal zulässige Größe.
449 Wiederholungsversuch. Zeigt an, dass die Anfrage vom aktuellen Server nicht ausgeführt werden kann, aber von einem anderen Server erfolgreich verarbeitet werden kann. Der Client sollte die Anfrage mit einer neuen URI wiederholen.
451 Aus rechtlichen Gründen nicht verfügbar . Die Ressource ist aus rechtlichen Gründen nicht verfügbar.
499 Client hat die Anfrage geschlossen . Der Server hat die Anfrage empfangen, aber die Verbindung wurde vom Client vor Abschluss der Verarbeitung geschlossen.
HTTP 5xx-Fehler (Serverfehler)
HTTP 5xx-Fehlercodes weisen auf Serverprobleme hin. Diese Codes weisen auf serverseitige Probleme hin, die dazu führen, dass der Server die Benutzeranfrage nicht ordnungsgemäß verarbeiten kann. Sehen wir sie uns genauer an:
HTTP-Fehler 500: Interner Serverfehler . Der Server ist auf unerwartete Umstände gestoßen, die die Bearbeitung der Anfrage verhindern. Der „Server“-Header kann den Server angeben, auf dem der Fehler aufgetreten ist.
501 Nicht implementiert . Der Server unterstützt die zur Verarbeitung der Clientanfrage erforderlichen Funktionen nicht. Der „Via“-Header kann auf den Proxy-Server hinweisen, über den der Fehler aufgetreten ist.
502 Bad Gateway . Dieser Code bedeutet, dass der als Proxy fungierende Server eine fehlerhafte Antwort von einem anderen Server erhalten hat.
HTTP- Fehler 503: Dienst nicht verfügbar . Der Server kann Anfragen vorübergehend nicht verarbeiten.
504 Gateway-Timeout . Der als Proxy fungierende Server hat keine rechtzeitige Antwort von einem anderen Server erhalten.
505 HTTP-Version nicht unterstützt . Der Server unterstützt die in der Anfrage angegebene HTTP-Protokollversion nicht. Alternativ kann der „Upgrade“-Header unterstützte Protokolle angeben.
Die Variante 506 verhandelt ebenfalls . Dieser Status wird in HTTP/1.1 nicht verwendet; sollte der Server jedoch eine interne Konfiguration feststellen, die zu einer Mehrdeutigkeit bei der Inhaltsverhandlung führt, kann er diese Antwort verwenden.
507 Unzureichender Speicherplatz . Der Server kann die Anfrage aufgrund unzureichenden Speicherplatzes nicht bearbeiten.
508 Schleife erkannt . Der Server hat bei der Bearbeitung der Anfrage eine Schleife festgestellt und verweigert die Bearbeitung der Anfrage, um eine Endlosschleife zu vermeiden.
509 Bandbreitenlimit überschritten . Dieser Fehler tritt auf, wenn die Bandbreite des Servers aufgrund eines hohen Anfrageaufkommens oder Datenverkehrs überschritten wird.
510 Nicht erweitert . Der Client muss zusätzliche Erweiterungen übertragen, um die Anfrage fortzusetzen.
511 Netzwerkauthentifizierung erforderlich . Der Client muss sich authentifizieren, um Zugriff auf das Netzwerk zu erhalten.
So überprüfen Sie den Seitenstatuscode
In diesem Abschnitt betrachten wir drei Hauptmethoden zur Überprüfung des Seitenstatuscodes: über die Befehlszeile, über einen Webbrowser und über unabhängige Onlinedienste. Jede dieser Methoden hat ihre eigenen Vorteile und kann in unterschiedlichen Situationen nützlich sein.
Überprüfen der Serverantwort über die Befehlszeile
Die Kommandozeile bietet eine bequeme Möglichkeit, den Seitenstatuscode zu überprüfen, ohne einen Webbrowser verwenden zu müssen. Dazu öffnen Sie die Kommandozeile und geben den folgenden Befehl ein:
curl -I http://page-address
Dieser Befehl sendet eine HEAD-Anfrage (Headers Only Request) an die angegebene URL und zeigt Informationen einschließlich des HTTP-Statuscodes an:
Das obige Beispiel zeigt einen erfolgreichen Antwortcode. Bei einer Antwort mit einem Fehlercode, z. B. „404 Not Found“, sieht das Ergebnis ähnlich aus:
Überprüfen der Serverantwort über die Browserkonsole
Die Entwicklerkonsole des Webbrowsers bietet Tools für verschiedene Vorgänge, einschließlich der Überprüfung des Seitenstatuscodes. Um den HTTP-Code in der Serverantwort anzuzeigen, öffnen Sie die Entwicklerkonsole (Strg+Umschalt+K) oder (Strg+Umschalt+J), je nach verwendetem Browser. Wählen Sie anschließend den Bereich „Netzwerk“ und laden Sie die gewünschte Seite:
Überprüfen der Serverantwort mit unabhängigen Tools
Es gibt zahlreiche unabhängige Online-Dienste, die Tools zur Überprüfung des Statuscodes von Webseiten bereitstellen. Diese Dienste ermöglichen in der Regel einen schnellen Überblick über die Verfügbarkeit und Leistung Ihrer Ressource. Sie alle funktionieren nach demselben Prinzip. Als Beispiel betrachten wir den bekanntesten Dienst: httpstatus.io.
Zuerst müssen Sie den Dienst selbst öffnen, dann die Adresse der Seite eingeben, deren Antwort Sie herausfinden möchten, und eine Bestätigung anfordern:
Das Ergebnis wird unten auf der Seite angezeigt:
Fazit
Abschließend sei betont, dass das Verstehen und Lesen von HTTP-Fehlercodes eine Schlüsselkompetenz für alle ist, die in der Webentwicklung und Serverwartung tätig sind. Wenn wir jeden Fehler identifizieren und die Tools zu seiner Erkennung erkunden, erkennen wir, warum es so wichtig ist, diese Aspekte der Webdienste effektiv zu verwalten.