HTTP Statuscode Referenz

Die HTTP-Statuscode-Referenz ist ein vollständiger, durchsuchbarer Index jedes in den HTTP-Spezifikationen definierten Statuscodes — von 100 Continue bis hin zu 511 Network Authentication Required. Jeder Eintrag zeigt den kanonischen Namen, den RFC, der ihn definiert, was der Code tatsächlich bedeutet, wann er zu senden ist, wann er nicht zu senden ist und die häufigen Fallstricke, die echten Codebasen Probleme bereiten. Ein Live-Filter und Kategorie-Chips ermöglichen es Ihnen, mit einem Klick von Klasse zu Klasse zu springen.

Im Gegensatz zu einem einfachen Spickzettel bietet dieses Tool für jeden Code eine eigene Mikro-Seite mit drei farbcodierten Panels (Verwendung / Vermeidung / Fallstricke) und kopierfertigen Handlern für Express.js, Django, FastAPI und Go net/http. Das animierte Leitungsdiagramm zeigt, wie die Anfrage vom Client zum Server wandert und der gewählte Status zurückfließt — nützlich für Einsteiger, die lernen möchten, was ein Statuscode auf der Leitung wirklich darstellt.

Warum eine Statuscode-Referenz wichtig ist

So nutzen Sie die HTTP-Statuscode-Referenz

1. Schnellsuche. Geben Sie einen Code (404) oder ein Namensfragment (teapot, gateway) in das Suchfeld oben ein und senden Sie es ab. Der passende Eintrag öffnet sich mit dem vollständigen Detail-Panel.
2. Nach Klasse durchsuchen. Klicken Sie auf einen der 5 Chips (1xx, 2xx, 3xx, 4xx, 5xx), um das Raster auf diese Klasse zu filtern. Klicken Sie auf Alle, um es zurückzusetzen.
3. Live-Filter. Das Filterfeld direkt über dem Raster grenzt die Karten während der Eingabe ein — nützlich, wenn Sie sich nur an die Hälfte eines Namens wie too many oder precondition erinnern.
4. Einen Code untersuchen. Klicken Sie auf eine beliebige Karte, um deren Detail-Panel zu öffnen. Sie sehen die Bedeutung, wann er zu verwenden ist, wann nicht, häufige Fallstricke und einen Snippet-Block für 4 Frameworks.
5. Ein Snippet kopieren. Nutzen Sie den Tab-Umschalter und die kleine Schaltfläche Kopieren, um einen kopierfertigen Handler zu erhalten.
6. Nachborn vergleichen. Das Detail-Panel endet mit Geschwister-Karten aus derselben Klasse (1xx / 2xx / 3xx / 4xx / 5xx) für einen schnellen direkten Vergleich.

Die fünf HTTP-Statusklassen auf einen Blick

Häufig verwechselte Paare

• 401 vs. 403. 401 bedeutet nicht authentifiziert — der Anfrage fehlen gültige Anmeldedaten. 403 bedeutet authentifiziert, aber nicht erlaubt — die Anmeldedaten sind in Ordnung, aber dem Benutzer fehlt die Berechtigung.
• 404 vs. 410. 404 bedeutet unbekannt: Vielleicht existiert es irgendwo, vielleicht ist es ein Tippfehler. 410 bedeutet absichtlich entfernt: Suchmaschinen sollten es aus dem Index löschen.
• 301 vs. 302 vs. 307 vs. 308. 301 / 308 sind permanent (308 behält Methode & Body strikt bei), 302 / 307 sind temporär (307 behält Methode & Body strikt bei). Verwenden Sie 307 / 308 für POST- / PUT- / PATCH-Weiterleitungen.
• 400 vs. 422. 400 bedeutet, dass der Anfragetext fehlerhaft ist (ungültiges JSON, fehlendes Feld). 422 bedeutet, dass der Body sauber analysiert wurde, aber die Werte die Geschäftsregeln verfehlen (ungültiges E-Mail-Format, Menge außerhalb des zulässigen Bereichs).
• 502 vs. 503 vs. 504. 502 bedeutet, dass der Upstream fehlerhafte Daten gesendet hat. 503 bedeutet, dass der Server überlastet ist oder gewartet wird. 504 bedeutet, dass der Upstream nicht rechtzeitig geantwortet hat.
• 409 vs. 412. 409 ist ein Konflikt mit dem aktuellen Zustand der Ressource. 412 bedeutet spezifisch, dass ein Precondition-Header (If-Match, If-Unmodified-Since) als falsch ausgewertet wurde.

Header, die mit bestimmten Statuscodes einhergehen

• 201 Created — sollte Location enthalten, das auf die neue Ressource verweist.
• 301 / 302 / 307 / 308 — müssen Location mit der Ziel-URL enthalten.
• 304 Not Modified — muss die Header widerspiegeln, die bei einer 200 erschienen wären (ETag, Cache-Control, Vary).
• 401 Unauthorized — muss WWW-Authenticate mit den akzeptierten Schemata (Basic, Bearer) enthalten.
• 405 Method Not Allowed — muss Allow mit den Methoden enthalten, die erlaubt sind.
• 413 / 429 / 503 — enthalten oft Retry-After (Sekunden oder HTTP-Datum), damit Clients korrekt pausieren.
• 416 Range Not Satisfiable — muss Content-Range: bytes */<length> enthalten.

Statuscodes, die Sie fast immer ignorieren können

Eine Handvoll Codes sind technisch gültig, aber in modernen APIs extrem selten: 305 Use Proxy (veraltet), 306 (reserviert, ungenutzt), 305, 506 Variant Also Negotiates, 510 Not Extended und 508 Loop Detected. Die meisten werden aus historischen Gründen im Register geführt. Wenn Ihre Bibliothek oder Middleware einen dieser Codes ausgibt, betrachten Sie dies als Fehlerbericht gegen die Bibliothek — nicht als Hinweis, ihn speziell zu behandeln.

FAQ

Enthält das Tool auch Codes aus anderen RFCs als 9110?

Ja. Es deckt RFC 9110 (HTTP-Semantik), RFC 6585 (zusätzliche 4xx / 5xx), RFC 4918 (WebDAV), RFC 5842 (WebDAV-Bindungen), RFC 7725 (451), RFC 8297 (103 Early Hints), RFC 8470 (425 Too Early) und das berühmte, spielerische RFC 2324 (418 Teapot) ab.

Sind diese Codes in HTTP/2 und HTTP/3 gültig?

Ja. Die Statuscode-Semantik ist in RFC 9110 definiert, dem versionsunabhängigen Dokument für HTTP-Semantik. HTTP/2 (RFC 9113) and HTTP/3 (RFC 9114) ändern nur das Framing und den Transport.

Kann ich direkt auf einen bestimmten Code verlinken?

Senden Sie das Formular mit einem einzelnen Code ab (zum Beispiel 404) und das Detail-Panel wird unter dem Formular geladen. Die URL zeigt Ihre Suche an und kann sicher geteilt werden — beim Öffnen wird dasselbe Ergebnis geladen.

Warum lässt mich mein Framework nicht 418 zurückgeben?

Ältere Versionen einiger HTTP-Bibliotheken weigern sich, Codes auszugeben, die nicht in ihrem internen Register enthalten sind. Die Lösung besteht darin, die Bibliothek zu aktualisieren oder, sofern möglich, die Statuszeile manuell zu schreiben.

Sollte eine API jemals 200 mit einem Fehler-Body zurückgeben?

Nein. Monitoring, Wiederholungsversuche (Retries) und Intermediäre gehen alle davon aus, dass 2xx Erfolg bedeutet. Wenn Sie eine Fehlerstruktur zurückgeben müssen, geben Sie ein passendes 4xx oder 5xx zurück und fügen Sie die strukturierten Details in den Body ein. Das Format „Problem Details for HTTP APIs“ (RFC 9457) ist eine gute Vorlage.

Gibt es ein verbindliches Register für HTTP-Statuscodes?

Ja. Die IANA verwaltet das Register unter iana.org/assignments/http-status-codes. Dieses Tool bleibt mit diesem Register sowie den am häufigsten zitierten RFCs synchron.