HTTP-Status-Referenz

HTTP Status Reference ist ein durchsuchbares, farbkodiertes Verzeichnis der Antwortcodes, die Ihnen in Logs und APIs tatsächlich begegnen. Statt Spezifikationstext zu durchblättern, finden Sie in Sekunden heraus, was 307 oder 429 bedeutet. Es richtet sich an Entwickler, die einen fehlerhaften Endpunkt debuggen, an Betriebsingenieure, die Proxy-Logs lesen, und an alle, die Fehlerbehandlung schreiben, die auf den richtigen Code verzweigen muss.

Was die Referenz tatsächlich auflistet

Die Liste ist bewusst kuratiert, nicht erschöpfend. Sie umfasst 38 Codes, und die Menge zu kennen verhindert Verwirrung, wenn ein erwarteter Code fehlt.

Klasse	Anzahl	Enthaltene Codes
1xx	4	100, 101, 102, 103
2xx	7	200, 201, 202, 203, 204, 205, 206
3xx	7	300, 301, 302, 303, 304, 307, 308
4xx	15	400, 401, 403, 404, 405, 408, 409, 410, 413, 414, 415, 418, 422, 429, 451
5xx	5	500, 501, 502, 503, 504

Bemerkenswerte Lücken sind 305 Use Proxy und 306, 402 Payment Required, die übrigen 4xx-Codes wie 406, 407, 411, 412, 416, 417, 426, 428 und 431 sowie jeder 5xx-Code oberhalb von 504. Die Referenz beschreibt übliches Verhalten, nicht das vollständige IANA-Register.

Suchen und Filtern

Das Suchfeld akzeptiert drei Arten von Abfragen. Eine vollständige dreistellige Zahl wird exakt gematcht, 404 liefert also nur Not Found. Eine kürzere Ziffernfolge matcht als Präfix, 40 listet also alle sieben Codes, die mit 40 beginnen, und 5 listet die fünf Serverfehler. Alles andere wird ohne Rücksicht auf Groß-/Kleinschreibung sowohl gegen den Codenamen als auch gegen seine Beschreibung gematcht, teapot findet also 418 und rate findet 429.

Die Kategorie-Reiter wirken neben der Suche, statt sie zu ersetzen. Die Auswahl von 4xx beschränkt die Liste auf Client-Fehler, und eine Eingabe im Suchfeld grenzt diese Teilmenge weiter ein. Eine Kategorie zu wählen blendet die nicht durchsuchten Codes aus, was das Durchsehen einer einzelnen Klasse erleichtert.

Die verwechselten Codes

401 vs. 403. 401 Unauthorized bedeutet, dass der Anfrage gültige Authentifizierungsnachweise fehlen; 403 Forbidden bedeutet, dass die Nachweise verstanden werden, aber keinen Zugang gewähren. 403 zu senden, wenn der Client sich einfach nicht angemeldet hat, verrät weniger Informationen, führt den Aufrufer aber in die Irre.

301 vs. 302. 301 ist eine dauerhafte Verschiebung und weist Crawler und Browser an, ihre Aufzeichnungen zu aktualisieren. 302 ist vorübergehend und bewahrt die ursprüngliche URL für künftige Anfragen. Die Geschwistercodes 307 und 308 bedeuten vorübergehende und dauerhafte Weiterleitung unter Beibehaltung der ursprünglichen HTTP-Methode, anders als 301 und 302, die historisch Methodenänderungen zuließen.

502 vs. 503 vs. 504. Alle drei stammen von einem Vermittler oder einem überlasteten Ursprung. 502 ist eine fehlerhafte Upstream-Antwort, 503 eine absichtliche Ablehnung und 504 ein Timeout. Der Header Retry-After ist bei 503 und 429 am aussagekräftigsten.

204 vs. 200. 204 No Content bestätigt Erfolg mit leerem Body, was nach einem DELETE üblich ist. 200 mit leerem Body zurückzugeben ist legal, aber weniger präzise.

Woher die Codes stammen

Die Kerncodes sind in der HTTP-Semantikspezifikation und verwandten Dokumenten definiert. Einige Einträge haben eine konkrete Herkunft: 102 Processing und 422 Unprocessable Entity sind WebDAV-Erweiterungen, 103 Early Hints unterstützt das Vorladen, 451 Unavailable For Legal Reasons wurde für rechtlich gesperrte Inhalte ergänzt, und 418 geht auf einen Aprilscherz-RFC zurück. Die Referenz vermerkt diese Ursprünge in den Beschreibungen, damit Sie Standardarbeit von Erweiterungen und Scherzen unterscheiden können. Weil die Menge kuratiert ist, bedeutet ein Code, der im IANA-Register steht, hier aber fehlt, nicht zwangsläufig, dass er ungültig ist; er liegt einfach außerhalb der Alltagsliste, die diese Seite pflegt.

Eine Antwort im Kontext lesen

Wenn Sie einen Statuscode sehen, lautet die nützliche nächste Frage, wer die Behebung verantwortet. Ein 4xx gehört dem Aufrufer: Anfrage ändern, Nachweise ergänzen, langsamer werden oder den Body korrigieren. Ein 5xx gehört dem Server oder seinen Betreibern: später erneut versuchen, den Upstream-Dienst prüfen oder Logs ansehen. Diese eine Trennung sagt Ihnen, ob eine Wiederholungsschleife sinnvoll ist.

Auch Methode und Semantik sind wichtig. Ein erfolgreiches DELETE lässt sich oft besser als 204 No Content ausdrücken als als 200 mit leerem Body, und ein 201 Created sollte einen Location-Header mit Verweis auf die neue Ressource mitbringen. Ein 405 Method Not Allowed sollte zulässige Methoden in einem Allow-Header auflisten, und ein 429 sollte Retry-After tragen. Diese Header-Hinweise sind nicht Teil der Referenz, aber Teil des korrekten Einsatzes jedes Codes.

Der Code ist außerdem nur die Hälfte des Vertrags. Auch Header und zwischengespeicherter Zustand tragen Bedeutung. Ein 304 Not Modified ist ein Cache-Erfolg, kein Fehler, und ein 3xx, dem ein Browser automatisch folgt, kann für den Client-Code wie ein 200 aussehen.

Häufige Fehler

200 mit einer Fehlermeldung im Body zurückgeben, was jeden Client bricht, der den Statuscode prüft. 302 für eine dauerhafte Verschiebung verwenden und dadurch angesammelte Suchsignale verlieren. 401 als „nicht erlaubt“ deuten und dort einsetzen, wo 403 hingehört, oder umgekehrt. Ein 4xx blind wiederholen: Ein 400, 401 oder 422 wird nicht erfolgreich, bis sich die Anfrage ändert. Und 500 für alles Unerwartete verwenden, obwohl ein spezifischeres 502, 503 oder 504 auf die eigentliche Ursache zeigen würde.

Verwandte Tools

• URL-Encoder
• JSON-Formatierer
• Base64
• User-Agent-Parser
• MIME-Typ-Suche