Schneller Nachschlag mit Erklärung
{{ c.name }}
HTTP-Statuscodes sind dreistellige Zahlen, die der Server in jeder Antwort an den Client zurückgibt. Sie wurden erstmals 1991 mit HTTP/0.9 eingeführt, in RFC 2616 (1999) standardisiert und schließlich in RFC 7231 (2014) sowie der heute gültigen RFC 9110 (2022) konsolidiert. Der Statuscode ist Teil der sogenannten Status-Line einer HTTP-Response (z.B. HTTP/1.1 200 OK) und teilt dem Client mit, ob die Anfrage erfolgreich war, umgeleitet wurde oder fehlgeschlagen ist. Ohne diese Codes wüsste der Browser nicht, ob er eine HTML-Seite rendern, einer Weiterleitung folgen oder eine Fehlerseite anzeigen soll.
Die erste Ziffer des Statuscodes bestimmt die Klasse, die zweite und dritte Ziffer das konkrete Ergebnis:
Diese Codes begegnen Entwicklern täglich — im Browser-DevTools-Netzwerk-Tab, in API-Responses und in Server-Logs:
If-None-Match/If-Modified-Since; Body ist leer, Browser lädt aus eigenem Cache.WWW-Authenticate sollte folgen.Retry-After nennt die Wartezeit.Beide Codes leiten den Browser auf eine andere URL um, der Unterschied liegt in der Permanenz und damit im SEO-Verhalten. Ein 301 signalisiert „diese URL existiert nicht mehr — nimm dauerhaft die neue Adresse“. Google überträgt den PageRank vollständig auf die Ziel-URL, Browser cachen die Umleitung aggressiv (oft monatelang). Ein 302 bedeutet „nur diese eine Anfrage soll umgeleitet werden, die alte URL bleibt der Master“. Suchmaschinen behalten die Originaladresse im Index und folgen jedem Request neu. Faustregel: Bei Domain-Umzügen, URL-Restrukturierungen oder permanenten Slug-Änderungen IMMER 301. Bei A/B-Tests, Wartungsweiterleitungen oder Login-Flow „nach erfolgreichem POST zur Übersicht“ ist 302 (oder besser 303 / 307) korrekt. Ein häufiger Fehler: bei Site-Migrationen 302 statt 301 zu setzen — Google verliert dann die Linkkraft.
HTTP-Caching ist eine der wichtigsten Performance-Optimierungen im Web — und HTTP-Statuscodes spielen dabei eine zentrale Rolle. Der wichtigste Cache-Code ist 304 Not Modified: Der Browser sendet einen If-None-Match-Header mit dem zuletzt gespeicherten ETag, der Server prüft, ob sich die Ressource geändert hat, und antwortet mit 304 und leerem Body wenn nicht — der Browser nutzt seine lokale Kopie. Das spart Bandbreite massiv. 200 OK mit Cache-Control: max-age=31536000, immutable wird ein Jahr lang gar nicht erst neu angefragt. 301 wird von Browsern oft monatelang gecacht — Vorsicht beim Wechsel von 301 auf 302! 503 mit Retry-After teilt CDNs mit, wann ein Retry sinnvoll ist. Header-Kombinationen wie Cache-Control, ETag, Last-Modified und Vary bestimmen das tatsächliche Cache-Verhalten.
REST-APIs nutzen Statuscodes systematisch: 200 für gelesene Ressourcen, 201 nach erfolgreichem POST mit Location-Header, 204 für DELETE ohne Body, 400 für Validierungsfehler, 401 für fehlendes Auth-Token, 404 für nicht existierende Ressourcen, 422 wenn Daten zwar valide JSON sind, aber Geschäftslogik verletzen. Browser-Debugging: im DevTools-Netzwerk-Tab zeigt die Statuscode-Spalte sofort, wo Probleme liegen — rote 4xx/5xx-Einträge sind die ersten Anlaufstellen. Server-Konfiguration (Nginx, Apache, Caddy) verwendet Statuscodes für Rewrite-Rules, Error-Pages und Health-Checks. SEO-Migrationen stehen und fallen mit korrekten 301-Redirects: alte URLs auf neue mappen, sitemap.xml aktualisieren, Search Console Change-of-Address. Monitoring-Tools wie Uptime-Robot prüfen periodisch auf 2xx und alarmieren bei 5xx.
Bei einer dauerhaften Umstellung — neue URL-Struktur, Domain-Wechsel, gelöschter Beitrag mit neuem Pendant — nimm 301 Moved Permanently. Bei kurzlebigen Umleitungen (Wartung, A/B-Test, vorübergehende Aktion) nutze 302 Found oder, wenn die HTTP-Methode strikt erhalten bleiben soll, 307 Temporary Redirect. Für SEO ist die Wahl entscheidend: 301 überträgt PageRank, 302 nicht.
200 OK mit leerem Body ist technisch erlaubt — der Client erwartet aber meist Inhalt. 204 No Content ist die saubere Wahl, wenn der Server bewusst keinen Body zurückgibt (z.B. nach erfolgreichem PUT oder DELETE). Der wichtige Unterschied: 204 darf laut RFC 9110 keinen Body haben, während 200 immer einen Body haben sollte. APIs sollten konsequent 204 für No-Content-Antworten verwenden — das spart Bandbreite und macht die Semantik klar.
Die Faustregel ist einfach: 401 Unauthorized heißt „du bist nicht eingeloggt — bitte authentifizieren". 403 Forbidden heißt „du bist eingeloggt, hast aber keine Berechtigung für diese Aktion". Beispiel: Ein nicht angemeldeter User ruft /admin auf → 401. Ein eingeloggter normaler User ruft /admin auf → 403. Bei 401 sollte der Server einen WWW-Authenticate-Header zurückgeben, der dem Client zeigt, welches Auth-Schema erwartet wird (z.B. Bearer, Basic).
Ja — Anbieter und Frameworks haben eigene Codes etabliert. Bekannt: 418 I'm a teapot aus RFC 2324 (Aprilscherz, aber real implementiert). Cloudflare nutzt 520 (Web Server Returned an Unknown Error), 521 (Web Server is Down), 522 (Connection Timed Out), 523 (Origin Is Unreachable), 524 (A Timeout Occurred), 525/526 (SSL-Probleme). Microsoft IIS hat 440 (Login Timeout), AWS hat 460/463/464. Nginx nutzt 444 (No Response — schließt die Verbindung ohne Antwort). Diese sind nicht im RFC, aber in der Praxis verbreitet und werden meist in den 4xx/5xx-Klassen eingeordnet.
Ein HTTP-Statuscode ist Teil der Status-Line, die der Server in jeder Response zurueckschickt: HTTP/1.1 200 OK. Die dreistellige Zahl ist maschinenlesbar, der Reason Phrase ("OK", "Not Found") ist nur fuer Menschen gedacht und seit RFC 7230 explizit veraltet — Clients duerfen ihn nicht parsen. In HTTP/2 und HTTP/3 entfaellt die Reason Phrase komplett, nur die Zahl im :status-Pseudo-Header bleibt uebrig. Das bedeutet: wenn du in einem Proxy oder Lua-Script auf den Reason Phrase angewiesen bist, brichst du die HTTP-Spezifikation.
Die erste Ziffer klassifiziert die Antwort und ist absichtlich grobkoernig: 1xx bedeutet "warten, ich denke noch nach" (Informational), 2xx "alles gut" (Success), 3xx "woanders schauen" (Redirection), 4xx "dein Fehler" (Client Error), 5xx "mein Fehler" (Server Error). Diese Klassifizierung erlaubt es Clients, unbekannte Codes vernuenftig zu behandeln: ein 299 wird wie 200 interpretiert, ein 599 wie 500. Genau das macht es moeglich, IANA-registrierte Erweiterungen wie 451 (Unavailable For Legal Reasons, RFC 7725) ohne Client-Update hinzuzufuegen. Die offizielle IANA-Registry listet alle bestaetigten Codes; eigene 6xx- oder x99-Codes verletzen die Spezifikation und brechen Reverse Proxies wie nginx, die strikt validieren.
Idempotenz und Cacheability haengen direkt am Statuscode. Per Default cachen Browser und Proxies nur Responses mit 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501 — ein 200 ohne explizite Cache-Control-Header darf vom Browser heuristisch fuer Stunden gespeichert werden. Bei 301 (Moved Permanently) cachet der Browser den Redirect oft permanent, was zu fiesem Verhalten fuehrt, wenn du den Redirect spaeter zurueckziehen willst — nutze 302 oder 307 wenn du dir nicht 100% sicher bist. RFC 7231 schreibt vor, welche Methoden bei welchen Codes idempotent bleiben: ein 405 auf POST signalisiert dem Client, dass die Methode generell verboten ist, ein 409 auf PUT, dass der konkrete Zustand kollidiert.
Jede der fuenf Klassen hat semantische Garantien, die du beim API-Design respektieren solltest.
100 Continue bei Expect: 100-continue, 101 beim WebSocket-Upgrade, 103 Early Hints erlaubt Preload-Header vor der finalen Response.200 Standard, 201 nach POST mit neuem Resource-URL im Location-Header, 204 ohne Body (z.B. DELETE), 206 nur fuer Range-Requests.301/308 permanent, 302/307 temporaer, 303 nach POST-Redirect-GET (PRG-Pattern), 304 nur als Antwort auf If-Modified-Since/If-None-Match.400 generischer Fehler, 401 = nicht authentifiziert (Login fehlt), 403 = authentifiziert aber nicht berechtigt, 422 validiert geparste aber inhaltlich fehlerhafte Daten.500 Catch-all, 502 Upstream antwortet kaputt, 503 Server kennt sein eigenes Limit (Wartung, Overload), 504 Upstream antwortet nicht in Zeit. Clients sollten 503 mit Retry-After-Header respektieren.So mappst du echte API-Situationen auf den richtigen Code — das machen u.a. GitHub, Stripe und AWS in Produktion vor.
/orders erfolgreich → 201 Created mit Location: /orders/42. Stripe nutzt das fuer jede Ressourcen-Erstellung./users/me ohne Bearer-Token → 401 Unauthorized mit WWW-Authenticate: Bearer. Mit gueltigem Token aber ohne admin-Rolle → 403 Forbidden./articles/5 mit veralteter If-Match-ETag → 412 Precondition Failed. Loest das verbreitete "Lost Update"-Problem ohne Locking.204 No Content (idempotent) oder 410 Gone, wenn die Loeschung Teil der Public API ist und nicht zurueckkommt.429 Too Many Requests mit Retry-After: 30 und X-RateLimit-Remaining: 0. GitHub und Twitter machen das so.Viele APIs verwechseln 401 und 403: 401 heisst "ich weiss nicht, wer du bist" (Login fehlt oder Token abgelaufen), 403 heisst "ich weiss wer du bist, aber dir ist es trotzdem nicht erlaubt". Wer beides als 403 schickt, blockiert legitime Token-Refresh-Logiken im Client. Ein weiterer Klassiker: ein 200 mit {"error": "..."} im JSON-Body. Das brechen Monitoring-Tools wie Datadog APM oder Sentry, weil sie nach HTTP-Status filtern — fehlerhaft verarbeitete Requests sehen wie Erfolg aus. Ebenfalls heikel: 307 und 308 bewahren die HTTP-Methode beim Redirect (POST bleibt POST), 301 und 302 erlaubten historisch das Umschreiben auf GET — viele Clients tun das bis heute, was unerwarteten Datenverlust verursacht. Wenn du auf einen Login-Endpunkt nach POST redirectest, nutze immer 303 See Other, das macht das PRG-Pattern explizit. Letzter Fallstrick: Cloudflare schickt eigene 52x-Codes (520-527), die nicht IANA-registriert sind und nur auf Cloudflare-spezifische Edge-Probleme hinweisen — niemals selbst in einer eigenen API verwenden.
401 Unauthorized bedeutet, der Server konnte den Benutzer nicht authentifizieren — entweder fehlt der Authorization-Header oder das Token ist ungueltig. 403 Forbidden bedeutet, der Benutzer ist bekannt, hat aber keine Berechtigung fuer die Aktion. Bei 401 sollte der Client einen Login oder Token-Refresh anstossen, bei 403 macht das keinen Sinn.400 Bad Request ist fuer Anfragen, die schon syntaktisch nicht passen — kaputtes JSON, fehlende Header, falscher Content-Type. 422 Unprocessable Entity (WebDAV, RFC 4918, aber faktisch fuer REST etabliert) ist fuer syntaktisch korrekte Bodies, deren Inhalte aber Validierungsregeln brechen — z.B. Email ohne @, negative Preise, fehlende Pflichtfelder. Rails und Laravel nutzen 422 als Default fuer Validation-Errors.401 Unauthorized mit einem konkreten WWW-Authenticate-Header: WWW-Authenticate: Bearer error="invalid_token", error_description="The access token expired" nach RFC 6750. Damit weiss der Client, dass ein Refresh sinnvoll ist, anstatt einen kompletten Re-Login auszuloesen.type, title, status, detail.418 stammt aus dem Aprilscherz-RFC 2324 (Hyper Text Coffee Pot Control Protocol) und ist offiziell reserviert: ein Server, der Kaffee kochen soll, aber eine Teekanne ist, soll 418 zurueckgeben. Real wird der Code von einigen APIs (z.B. Cloudflare-Mock fuer scrapende Bots) als Easter-Egg verwendet. Fuer Produktiv-APIs nicht verwenden.301 Moved Permanently uebertraegt PageRank zur neuen URL und ist Standard fuer permanente Domain- oder Pfad-Umstellungen. 302 Found behaelt den PageRank bei der alten URL und ist fuer temporaere Umleitungen gedacht (z.B. A/B-Tests oder geozielsensitive Weiterleitungen). Google behandelt 308 (permanent, method-preserving) und 307 (temporary, method-preserving) seit 2018 wie 301/302 fuer SEO-Zwecke.