HTTP-Statuscodes — vollständige Liste mit Bedeutung und Beispielen

Zwischenantwort: Der Server hat die Request-Header erhalten, und der Client soll den Body senden.

Wird von Servern automatisch gesendet, wenn ein Client vor dem Upload eines großen Bodys „Expect: 100-continue“ mitschickt, damit er keine Bandbreite für eine Anfrage verschwendet, die abgelehnt würde.

Sende ihn nicht aus Anwendungscode als finalen Status; er ist nie die Antwort auf eine Anfrage, nur ein Schritt vor der eigentlichen.

Nicht zutreffend

RFC 9110 §15.2.1

PUT /upload HTTP/1.1
Content-Length: 104857600
Expect: 100-continue

HTTP/1.1 100 Continue

Der Server stimmt zu, die Verbindung auf das im Upgrade-Header genannte Protokoll umzustellen.

Die Handshake-Antwort für WebSocket-Verbindungen (Upgrade: websocket) und früher für Upgrades von HTTP/1.1 auf h2c.

HTTP/2 und HTTP/3 verwenden ihn nicht; WebSockets über HTTP/2 nutzen stattdessen die erweiterte CONNECT-Methode (RFC 8441).

Nicht zutreffend

RFC 9110 §15.2.2

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Zwischenantwort, die dem Client mitteilt, dass der Server noch an einer langen WebDAV-Anfrage arbeitet, damit kein Timeout eintritt.

WebDAV. In RFC 4918 aus WebDAV entfernt, aber weiterhin im IANA-Register.

Nur in älteren WebDAV-Servern bei langsamen rekursiven Vorgängen wie einem tiefen COPY oder MOVE.

Neue APIs sollten für lang laufende Aufgaben stattdessen 202 Accepted mit einer Status-URL zurückgeben.

Nicht zutreffend

RFC 2518 §10.1

HTTP/1.1 102 Processing

Zwischenantwort mit Link-Headern, damit der Browser mit Preload oder Preconnect beginnen kann, während der Server die finale Antwort noch vorbereitet.

Wenn das Erzeugen des HTML Zeit braucht (serverseitiges Rendering, Datenbankabfragen) und du weißt, welche CSS-Dateien, Schriften oder Origins die Seite braucht. Chromium-Browser und Firefox reagieren auf Preload- und Preconnect-Hinweise in 103-Antworten, Safari auf Preconnect.

Setze keine Header hinein, die nur für die finale Antwort gelten dürfen, etwa Set-Cookie; Browser ignorieren die meisten Header in 103.

Nicht zutreffend

RFC 8297

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: <https://cdn.example.com>; rel=preconnect

HTTP/1.1 200 OK
Content-Type: text/html

Zwischenantwort, die dem Client mitteilt, dass der begonnene Upload später fortgesetzt werden kann, und wo.

Vorläufige IANA-Registrierung für den IETF-Entwurf zu fortsetzbaren Uploads; noch kein finaler RFC.

Experimentell: Server, die den Entwurf zu fortsetzbaren Uploads umsetzen, senden ihn mit einem Location-Header für die Upload-Ressource.

Nicht für den allgemeinen Einsatz, bis der Entwurf als RFC veröffentlicht ist; die meisten Clients und Proxys kennen ihn nicht.

Nicht zutreffend

draft-ietf-httpbis-resumable-upload

HTTP/1.1 104 Upload Resumption Supported
Upload-Draft-Interop-Version: 6
Location: https://example.com/upload/b530ce8ff

Die Anfrage war erfolgreich. Was der Body enthält, hängt von der Methode ab: bei GET die Ressource, bei POST das Ergebnis der Aktion.

Die normale Erfolgsantwort für GET sowie für POST, PUT, PATCH oder DELETE, wenn du einen Body mit dem Ergebnis zurückgibst.

Gib nicht 200 mit einer Fehlermeldung im Body zurück („Soft Errors“). Clients, Monitoring, Caches und Suchmaschinen lesen den Statuscode, nicht dein JSON.

Standardmäßig cachebar (heuristisch cachebar)

RFC 9110 §15.3.1

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 42, "name": "Ada"}

Die Anfrage war erfolgreich und hat eine oder mehrere neue Ressourcen erstellt.

Nach einem POST (oder einem PUT auf eine neue URL), der etwas anlegt. Füge einen Location-Header hinzu, der auf die neue Ressource zeigt; der Body beschreibt sie meist.

Verwende ihn nicht, wenn nichts Neues erstellt wurde, etwa bei der Aktualisierung eines bestehenden Datensatzes (nimm 200 oder 204).

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.3.2

HTTP/1.1 201 Created
Location: /users/42
Content-Type: application/json

{"id": 42}

Die Anfrage wurde zur Verarbeitung angenommen, die Verarbeitung ist aber noch nicht abgeschlossen und kann noch fehlschlagen.

Eingereihte oder asynchrone Aufgaben: Videokodierung, Berichterstellung, Massenimporte. Gib einen Link zurück, unter dem der Client den Jobstatus prüfen kann.

Verwende ihn nicht als „Erfolg“ für synchrone Aufgaben; er verspricht ausdrücklich nichts über das Ergebnis.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.3.3

HTTP/1.1 202 Accepted
Location: /jobs/7f3a
Content-Type: application/json

{"status": "queued"}

Erfolg, aber ein transformierender Proxy hat die 200-Antwort des Ursprungsservers verändert.

Nur von Zwischenstationen, die Inhalte verändern, etwa ein Proxy, der Bilder komprimiert oder HTML umschreibt, um dem Client mitzuteilen, dass es nicht exakt die Antwort des Ursprungsservers ist.

Ursprungsserver und APIs sollten ihn nicht senden.

Standardmäßig cachebar (heuristisch cachebar)

RFC 9110 §15.3.4

HTTP/1.1 203 Non-Authoritative Information
Content-Type: image/webp

Erfolg, und es gibt absichtlich keinen Body.

Erfolgreiches DELETE, PUT oder PATCH, wenn du die aktualisierte Ressource nicht zurückgibst, automatisches Speichern eines Formulars oder eine CORS-Preflight-Antwort.

Füge nie einen Body hinzu; Clients lesen ihn nicht, und bei HTTP/1.1 beschädigt ein überzähliger Body die nächste Antwort auf der Verbindung. Nimm 200, wenn du etwas zurückzugeben hast.

Standardmäßig cachebar (heuristisch cachebar)

RFC 9110 §15.3.5

HTTP/1.1 204 No Content

Erfolg; der Client soll die Dokumentansicht zurücksetzen, zum Beispiel das abgeschickte Formular leeren.

Eingabeoberflächen, bei denen der Benutzer ein Formular absendet und sofort den nächsten Datensatz eingibt.

Browser setzen das Zurücksetzen nicht um, in der Praxis verhält er sich also wie 204. Darf keinen Body enthalten.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.3.6

HTTP/1.1 205 Reset Content

Der Server gibt nur den oder die Byte-Bereiche zurück, die der Client mit einem Range-Header angefordert hat.

Spulen in Video und Audio, fortsetzbare Downloads und Download-Manager, die eine Datei in parallelen Teilen laden. Füge Content-Range hinzu.

Sende ihn nur, wenn die Anfrage einen Range-Header hatte, den du berücksichtigst. Wenn du Range ignorierst, sende 200 mit dem vollständigen Body.

Standardmäßig cachebar (heuristisch cachebar)

RFC 9110 §15.3.7

GET /video.mp4 HTTP/1.1
Range: bytes=0-1023

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-1023/146515
Content-Length: 1024

Der Body (XML) enthält für jede von mehreren Ressourcen einen eigenen Status.

WebDAV

WebDAV-Vorgänge wie PROPFIND, die viele Ressourcen betreffen. Manche JSON-APIs übernehmen ihn für Batch-Endpunkte.

Bei Batch-APIs bevorzugen viele Teams 200 mit Ergebnissen pro Element, da generische Clients 207 als einfachen Erfolg behandeln.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 4918 §11.1

HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"

Wird innerhalb einer 207-Antwort verwendet, um anzugeben, dass eine Ressource bereits weiter oben aufgeführt wurde und daher nicht wiederholt wird (verhindert Schleifen mit Bindings).

WebDAV

WebDAV-Server, die Bindings unterstützen (RFC 5842).

Außerhalb von WebDAV als eigenständige Antwort nicht sinnvoll.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 5842 §7.1

<D:status>HTTP/1.1 208 Already Reported</D:status>

Der Server hat ein GET mit einem Delta (Instance Manipulation) beantwortet, das auf die aktuelle Ressource angewendet wurde, statt die vollständige Ressource zu senden.

Delta-Kodierung für HTTP (A-IM- / IM-Header). Selten im Einsatz.

Von Browsern nicht unterstützt; verwende ihn nicht in gewöhnlichen APIs.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 3229 §10.4.1

HTTP/1.1 226 IM Used
IM: vcdiff
ETag: "v2"

Die Ressource hat mehrere Darstellungen, und der Client (oder Benutzer) soll eine auswählen.

Selten: agentengesteuerte Content Negotiation, etwa ein Dokument in mehreren Sprachen oder Formaten mit Links zu jeder Variante.

Browser wählen nicht automatisch. Für die Auswahl von Sprache oder Format funktioniert serverseitige Negotiation oder eine normale Seite mit Links besser.

Standardmäßig cachebar (heuristisch cachebar)

RFC 9110 §15.4.1

HTTP/1.1 300 Multiple Choices
Link: </doc.en.html>; rel=alternate; hreflang=en
Link: </doc.fr.html>; rel=alternate; hreflang=fr

Die Ressource hat eine neue dauerhafte URL, angegeben im Location-Header.

Domainumzüge, HTTP zu HTTPS, geänderte Slugs, Zusammenführen doppelter URLs. Suchmaschinen übertragen Ranking-Signale auf die neue URL.

Browser können beim Folgen eines 301 POST in GET ändern. Wenn die Methode erhalten bleiben muss (ein umgezogener API-Endpunkt), nimm 308. Browser cachen 301-Antworten aggressiv, also teste vor dem Deployment.

Standardmäßig cachebar (heuristisch cachebar)

RFC 9110 §15.4.2

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-page

Die Ressource befindet sich vorübergehend unter einer anderen URL; nutze künftig weiter die ursprüngliche URL.

Temporäre Umleitungen: Login-Weiterleitungen, A/B-Tests, Wartungsseiten, Weiterleitungen nach Region oder Sprache.

Browser ändern beim Folgen eines 302 POST in GET (historisches Verhalten, das der RFC erlaubt). Nimm 303 für „sieh dir das Ergebnis an“ nach einem POST und 307, wenn die Methode erhalten bleiben muss.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.4.3

HTTP/1.1 302 Found
Location: /login?next=%2Faccount

Leitet den Client auf eine andere URL um, die er mit GET abrufen muss.

Das Post/Redirect/Get-Muster: Sende nach einem Formular-POST 303 auf die Ergebnisseite, damit ein Neuladen der Seite das Formular nicht erneut absendet.

Nicht für umgezogene Inhalte; er sagt nichts darüber aus, ob die ursprüngliche URL umgezogen ist.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.4.4

HTTP/1.1 303 See Other
Location: /orders/1234

Antwort auf ein bedingtes GET oder HEAD (If-None-Match oder If-Modified-Since): Die gecachte Kopie des Clients ist weiterhin gültig.

Cache-Revalidierung: wird selbst nicht gespeichert, frischt aber die gecachte Antwort auf, die der Client bereits hat.

Automatisch von Servern und CDNs, wenn ETag oder Last-Modified-Datum übereinstimmen; so entfällt die Übertragung eines unveränderten Bodys.

Sende nie einen Body. Sende ihn nicht auf eine Anfrage, die nicht bedingt war; der Client hat dann nichts, was er wiederverwenden kann.

Nicht zutreffend

RFC 9110 §15.4.5

GET /app.js HTTP/1.1
If-None-Match: "33a64df5"

HTTP/1.1 304 Not Modified
ETag: "33a64df5"
Cache-Control: max-age=3600

Veraltet. Forderte den Client früher auf, die Anfrage über einen in Location genannten Proxy zu wiederholen.

Nichts. Er wurde aus Sicherheitsgründen für veraltet erklärt, und Browser ignorieren ihn.

Sende ihn nicht.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.4.6

HTTP/1.1 305 Use Proxy

Reserviert. Wurde in einem Entwurf für „Switch Proxy“ verwendet und ist nicht mehr in Gebrauch.

Nichts.

Sende ihn nicht.

Nicht zutreffend

RFC 9110 §15.4.7

Temporäre Umleitung, bei der der Client die Anfrage mit derselben Methode und demselben Body wiederholen muss.

Vorübergehendes Umleiten von POST-, PUT- oder DELETE-Anfragen (ein API-Endpunkt ist wegen Wartung umgezogen). Browser zeigen außerdem einen internen 307, wenn HSTS HTTPS erzwingt.

Für einen dauerhaften Umzug nimm 308. Für „hol das Ergebnis per GET“ nimm 303.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.4.8

HTTP/1.1 307 Temporary Redirect
Location: https://api2.example.com/v1/orders

Dauerhafte Umleitung, bei der der Client die Anfrage mit derselben Methode und demselben Body wiederholen muss.

Ein dauerhaft umgezogener API-Endpunkt, der POST oder PUT empfängt. Suchmaschinen behandeln ihn wie 301. Next.js und Vercel verwenden standardmäßig 308 für dauerhafte Umleitungen.

Sehr alte Clients (Internet Explorer unter Windows 7 und älter) verstehen ihn nicht; für einfache Seitenumzüge ist 301 genauso gut.

Standardmäßig cachebar (heuristisch cachebar)

RFC 9110 §15.4.9

HTTP/1.1 308 Permanent Redirect
Location: https://example.com/api/v2/upload

Der Server verarbeitet die Anfrage wegen eines Client-Fehlers nicht: fehlerhafte Syntax, ungültiges Framing oder ungültige Parameter.

Nicht parsbares JSON, ein fehlender Pflichtparameter, ein Wert vom falschen Typ. Erkläre das Problem im Body (RFC 9457 problem+json ist ein gutes Format).

Für wohlgeformte Eingaben, die an Geschäftsregeln scheitern, verwenden viele APIs 422. Für Authentifizierungsprobleme nimm 401 oder 403.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.5.1

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

{"title": "Invalid JSON", "detail": "Unexpected token } at position 41"}

Der Anfrage fehlen gültige Anmeldedaten. Trotz des Namens bedeutet er „nicht authentifiziert“.

Kein Token, ein abgelaufenes Token oder ein falsches Passwort. Die Antwort muss einen WWW-Authenticate-Header enthalten, der beschreibt, wie man sich authentifiziert.

Wenn der Benutzer angemeldet ist, aber keine Berechtigung hat, nimm 403. Sende 401 nicht ohne WWW-Authenticate.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.5.2

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api", error="invalid_token"

Für künftige Verwendung reserviert. Es gibt keine standardisierte Bedeutung.

Manche APIs verwenden ihn für „Kontingent aufgebraucht, upgrade deinen Tarif“ oder eine fehlgeschlagene Zahlung (Stripe gibt 402 bei abgelehnten Kartenzahlungen zurück).

Verlass dich nicht darauf, dass Clients ihn verstehen; beschreibe das Problem im Body.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.5.3

HTTP/1.1 402 Payment Required
Content-Type: application/json

{"error": "card_declined"}

Der Server hat die Anfrage verstanden und weiß, wer du bist (oder es ist ihm egal), verweigert aber die Ausführung.

Dem angemeldeten Benutzer fehlt die Berechtigung, eine IP ist gesperrt, Verzeichnisauflistung ist deaktiviert oder eine WAF-Regel hat gegriffen. Erneutes Anmelden hilft nicht.

Wenn Anmeldedaten fehlen oder ungültig sind, nimm 401. Wenn schon die Information, dass die Ressource existiert, ein Leck wäre, gib stattdessen 404 zurück.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.5.4

HTTP/1.1 403 Forbidden
Content-Type: application/json

{"error": "You do not have access to this project"}

Der Server hat für die URL keine aktuelle Darstellung oder will nicht verraten, ob es eine gibt.

Unbekannte URLs, gelöschte Datensätze, wenn du Löschungen nicht nachverfolgst, oder das Verbergen von Ressourcen vor unberechtigten Benutzern.

Wenn die Ressource existiert hat und endgültig weg ist, sagt 410 das ausdrücklich. Gib keine 200-Seite zurück, auf der „nicht gefunden“ steht (ein Soft 404).

Standardmäßig cachebar (heuristisch cachebar)

RFC 9110 §15.5.5

HTTP/1.1 404 Not Found
Content-Type: text/html

Die URL existiert, unterstützt aber diese HTTP-Methode nicht.

Ein DELETE auf eine schreibgeschützte Ressource oder ein POST auf eine Seite, die nur GET kennt. Die Antwort muss einen Allow-Header mit den unterstützten Methoden enthalten.

Verwende ihn nicht für Berechtigungsprobleme (403) oder für Methoden, die der Server überhaupt nicht implementiert (501).

Standardmäßig cachebar (heuristisch cachebar)

RFC 9110 §15.5.6

HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD

Der Server kann keine Antwort erzeugen, die zu den Headern Accept, Accept-Language oder Accept-Encoding der Anfrage passt.

Eine API, die nur JSON spricht, erhält „Accept: application/xml“ ohne Fallback.

Die meisten Server ignorieren nicht passende Accept-Header und senden stattdessen ihr Standardformat, was meist freundlicher ist.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.5.7

HTTP/1.1 406 Not Acceptable
Content-Type: application/json

{"supported": ["application/json"]}

Wie 401, aber der Client muss sich beim dazwischenliegenden Proxy authentifizieren.

Wird von Forward-Proxys (Unternehmens-Proxys) mit einem Proxy-Authenticate-Header gesendet.

Ursprungsserver sollten ihn nie senden.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.5.8

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="corp-proxy"

Der Server hat in der Zeit, die er zu warten bereit war, keine vollständige Anfrage erhalten und schließt die Verbindung.

Wird von Servern bei inaktiven Keep-alive-Verbindungen oder langsamen Uploads gesendet. Clients können die Anfrage über eine neue Verbindung wiederholen.

Nicht für langsame Backend-Verarbeitung; das ist ein 504 an einem Gateway oder einfach eine langsame Antwort. Sende „Connection: close“ mit.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.5.9

HTTP/1.1 408 Request Timeout
Connection: close

Die Anfrage steht im Konflikt mit dem aktuellen Zustand der Ressource.

Anlegen eines Benutzers, dessen E-Mail-Adresse schon existiert, Bearbeiten eines Datensatzes, den jemand anderes geändert hat (Versionskonflikt), Löschen eines nicht leeren Ordners.

Für fehlgeschlagene If-Match- / If-Unmodified-Since-Bedingungen nimm 412. Für Validierungsfehler nimm 400 oder 422.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.5.10

HTTP/1.1 409 Conflict
Content-Type: application/json

{"error": "Email already registered"}

Die Ressource gab es hier früher, sie ist dauerhaft weg und hat keine Weiterleitungsadresse.

Eingestellte Produkte, abgelaufene Aktionen, gelöschte Konten, eingestellte API-Versionen. Google behandelt 404 und 410 fast gleich, ein 410 wird aber eventuell etwas früher aus dem Index entfernt.

Wenn der Inhalt umgezogen ist, leite stattdessen mit 301 um. Wenn du nicht sicher bist, ob es endgültig ist, nimm 404.

Standardmäßig cachebar (heuristisch cachebar)

RFC 9110 §15.5.11

HTTP/1.1 410 Gone

Der Server verlangt bei dieser Anfrage einen Content-Length-Header.

Server, die Chunked-Uploads ablehnen und die Body-Größe vorab kennen müssen.

Wird von Anwendungen selten gebraucht; meist sendet ihn der Webserver selbst.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.5.12

HTTP/1.1 411 Length Required

Eine Bedingung in den Request-Headern (If-Match, If-Unmodified-Since, If-None-Match bei einem Schreibvorgang) war falsch.

Optimistische Nebenläufigkeit: Der Client hat If-Match mit einem alten ETag gesendet, jemand anderes hat die Ressource also zuerst geändert.

Verwende ihn nicht für Verstöße gegen Geschäftsregeln, die nichts mit bedingten Headern zu tun haben (409 oder 422).

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.5.13

PUT /docs/7 HTTP/1.1
If-Match: "v3"

HTTP/1.1 412 Precondition Failed
ETag: "v4"

Der Request-Body ist größer, als der Server verarbeiten will. Hieß vor RFC 9110 „Payload Too Large“.

Uploads über dem Limit (nginx client_max_body_size, eine API-Obergrenze von 10 MB). Wenn das Limit vorübergehend ist, füge Retry-After hinzu.

Für eine zu lange URL nimm 414, für zu große Header 431.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.5.14

HTTP/1.1 413 Content Too Large
Connection: close

Das Anfrageziel (URL) ist länger, als der Server interpretieren will.

Riesige Query-Strings, oft ein GET-Formular, das ein POST sein sollte, oder eine Umleitungsschleife, die ständig Parameter anhängt.

Verlege große Eingaben in einen Request-Body (POST), statt das Limit immer weiter zu erhöhen.

Standardmäßig cachebar (heuristisch cachebar)

RFC 9110 §15.5.15

HTTP/1.1 414 URI Too Long

Der Server lehnt die Anfrage ab, weil das Format des Bodys (Content-Type oder Content-Encoding) nicht unterstützt wird.

Ein Endpunkt, der JSON akzeptiert, erhält Formulardaten oder XML, oder der Content-Type-Header fehlt. Füge Accept-Post oder Accept-Patch hinzu, um zu zeigen, was unterstützt wird.

Nicht für einen Body im richtigen Format mit ungültigem Inhalt (400 oder 422).

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.5.16

HTTP/1.1 415 Unsupported Media Type
Accept-Post: application/json

Keiner der Byte-Bereiche im Range-Header überschneidet sich mit der Ressource, etwa wenn Bytes hinter dem Dateiende angefordert werden.

Fortgesetzte Downloads, bei denen die Datei kleiner geworden ist oder der Client über ihr Ende hinaus anfragt. Füge Content-Range: bytes */<length> hinzu.

Server dürfen einen ungültigen Range auch einfach ignorieren und 200 mit dem vollständigen Body zurückgeben.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.5.17

HTTP/1.1 416 Range Not Satisfiable
Content-Range: bytes */47022

Der Server kann die Anforderung im Expect-Header der Anfrage nicht erfüllen.

Ein Client hat „Expect: 100-continue“ an einen Server oder Proxy gesendet, der das nicht unterstützt, oder eine unbekannte Erwartung angegeben.

Clients, die ihn erhalten, sollten es ohne Expect-Header erneut versuchen.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.5.18

HTTP/1.1 417 Expectation Failed

Von RFC 9110 reserviert, weil 418 als Scherzcode „I’m a teapot“ weit verbreitet war; er hat in HTTP keine definierte Bedeutung.

Reserviert. Berühmt als „I’m a teapot“ aus dem Aprilscherz-RFC 2324 (HTCPCP) von 1998.

Nur als Easter Egg. Manche Dienste nutzen ihn, um Anfragen, die sie ablehnen wollen, mit Humor zu beantworten.

Verwende ihn nicht für echte Fehler; ihm kann keine Bedeutung zugewiesen werden, und Clients wissen nicht, was zu tun ist.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.5.19

HTTP/1.1 418 I'm a teapot

Laravel gibt ihn zurück, wenn das CSRF-Token fehlt oder abgelaufen ist, meist nachdem eine Sitzung auf einer Seite mit Formular abgelaufen ist.

Wird von Laravels CSRF-Middleware gesendet. Abhilfe: Seite neu laden, @csrf in Formulare einfügen oder bei AJAX-Anfragen den Header X-CSRF-TOKEN mitsenden.

Kein Standardcode; sende ihn nicht aus APIs, die nicht auf Laravel basieren.

Nicht zutreffend

Laravel (nicht im IANA-Register)

HTTP/1.1 419 unknown status

Die Ratenlimit-Antwort der alten Twitter-API, ersetzt durch den Standardcode 429.

Nichts Neues. Du triffst ihn eventuell noch in alten Client-Bibliotheken. Spring definierte früher 420 „Method Failure“, inzwischen veraltet.

Nimm 429 für Rate Limiting.

Nicht zutreffend

Twitter API v1 (nicht im IANA-Register)

HTTP/1.1 420 Enhance Your Calm

Die Anfrage hat einen Server erreicht, der für diesen Host und dieses Schema keine Antwort erzeugen kann.

HTTP/2-Connection-Coalescing ist schiefgegangen: Der Browser hat eine Verbindung für einen anderen Hostnamen wiederverwendet, der vom selben Zertifikat abgedeckt ist, den der Server aber nicht bedient. Der Client sollte es über eine neue Verbindung erneut versuchen.

Nicht für gewöhnliche unbekannte Hostnamen auf einem einzelnen Server; das ist meist ein 404 oder der Standard-Virtual-Host.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.5.20

HTTP/2 421

Die Anfrage ist wohlgeformt und in einem unterstützten Format, aber ihr Inhalt besteht die Validierung nicht. Heißt in RFC 4918 „Unprocessable Entity“.

Validierungsfehler in Formularen und APIs: eine E-Mail-Adresse, die keine ist, ein Enddatum vor dem Startdatum. Rails, Laravel und FastAPI verwenden ihn standardmäßig.

Für fehlerhafte Syntax (nicht parsbares JSON) nimm 400.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.5.21

HTTP/1.1 422 Unprocessable Content
Content-Type: application/json

{"errors": {"email": ["is invalid"]}}

Die Ressource ist gesperrt, daher kann die Anfrage sie nicht ändern.

WebDAV

WebDAV-LOCK-Semantik. Manche APIs nutzen ihn für Datensätze, die gerade von jemand anderem bearbeitet werden, oder für Konten, die nach fehlgeschlagenen Logins gesperrt sind.

Außerhalb von WebDAV verstehen generische Clients 409 besser.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 4918 §11.3

HTTP/1.1 423 Locked

Die Aktion ist fehlgeschlagen, weil eine andere Aktion, von der sie abhing, fehlgeschlagen ist.

WebDAV

In einem WebDAV-PROPPATCH oder einer Batch-Anfrage für Elemente, die nicht versucht wurden, weil ein früheres Element fehlgeschlagen ist.

Nicht für Ausfälle vorgelagerter Dienste; das sind 502 oder 503.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 4918 §11.4

HTTP/1.1 424 Failed Dependency

Der Server verarbeitet eine Anfrage nicht, die in TLS-1.3-Early-Data (0-RTT) gesendet wurde, weil sie wiederholt eingespielt werden könnte.

CDNs und Server, die 0-RTT akzeptieren, aber nicht idempotente Anfragen (POST) in Early Data ablehnen. Der Client versucht es nach Abschluss des Handshakes erneut.

Kein allgemeiner „später versuchen“-Code; nimm dafür 503 mit Retry-After.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 8470 §5.2

HTTP/1.1 425 Too Early

Der Server lehnt die Anfrage mit dem aktuellen Protokoll ab, würde sie aber nach einem im Upgrade-Header genannten Upgrade annehmen.

TLS oder ein neueres Protokoll wird verlangt, oder ein WebSocket-Endpunkt erhält eine einfache HTTP-Anfrage. Muss einen Upgrade-Header enthalten.

Für HTTP zu HTTPS auf Websites ist eine 301- oder 308-Umleitung plus HSTS der übliche Weg.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.5.22

HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.3, HTTP/1.1
Connection: Upgrade

Der Server verlangt, dass die Anfrage bedingt ist (If-Match usw.), um verlorene Aktualisierungen zu verhindern.

APIs, die darauf bestehen, dass Clients vor einem PUT, PATCH oder DELETE If-Match mit dem zuletzt gesehenen ETag senden.

Nimm 412, wenn eine Vorbedingung gesendet wurde und fehlgeschlagen ist; 428 ist für den Fall, dass keine gesendet wurde.

Darf von Caches nicht gespeichert werden

RFC 6585 §3

HTTP/1.1 428 Precondition Required
Content-Type: application/json

{"error": "Send If-Match with the current ETag"}

Der Client hat in einem bestimmten Zeitraum zu viele Anfragen gesendet (Rate Limiting).

API-Ratenlimits, Login-Drosselung, Schutz vor Scraping. Füge Retry-After hinzu, damit sich gut programmierte Clients an die Wartezeit halten können; RateLimit-Header helfen ebenfalls.

Für einen Server, der für alle überlastet ist, nimm 503. Googlebot behandelt 429 wie 503 und verlangsamt das Crawling.

Darf von Caches nicht gespeichert werden

RFC 6585 §4

HTTP/1.1 429 Too Many Requests
Retry-After: 60
Content-Type: application/json

{"error": "Rate limit exceeded: 100 requests per minute"}

Die Header sind einzeln oder zusammen zu groß für den Server.

Meist übergroße Cookies, die sich auf einer Domain angesammelt haben, oder riesige Authorization-Tokens. Cookies löschen behebt es für Benutzer oft.

Für eine lange URL nimm 414, für einen großen Body 413.

Darf von Caches nicht gespeichert werden

RFC 6585 §5

HTTP/1.1 431 Request Header Fields Too Large

Die Sitzung des Clients ist abgelaufen, und er muss sich erneut anmelden (Outlook Web Access und andere IIS-Anwendungen).

In Exchange/OWA-Umgebungen zu sehen.

Nimm in deinen eigenen Anwendungen 401 für abgelaufene Sitzungen.

Nicht zutreffend

Microsoft IIS (nicht im IANA-Register)

HTTP/1.1 440 Login Time-out

nginx-interner Code: „return 444;“ schließt die Verbindung, ohne überhaupt eine Antwort zu senden.

Verwerfen von Anfragen durch Scanner, von Anfragen mit unbekanntem Host-Header in einem Default-Server-Block oder von missbräuchlichen Clients. Er erscheint in den nginx-Logs; der Client sieht eine leere Antwort.

Der Client erhält nie einen 444, im Client-Code muss er also nicht behandelt werden.

Nicht zutreffend

nginx (nicht im IANA-Register)

server {
  listen 80 default_server;
  return 444;
}

Microsoft-Erweiterung: Die Anfrage soll wiederholt werden, nachdem der Client eine bestimmte Aktion ausgeführt hat.

In einigen Microsoft-Diensten zu sehen (Exchange ActiveSync; Azure Cosmos DB verwendet 449 für wiederholbare Schreibkonflikte).

Nicht standardisiert; nimm in deinen eigenen APIs 409 oder 503 mit Retry-After.

Nicht zutreffend

Microsoft IIS (nicht im IANA-Register)

HTTP/1.1 449 Retry With

Der Jugendschutz von Windows hat den Zugriff auf die Seite blockiert.

Wird auf Windows-Systemen mit aktiviertem Jugendschutz erzeugt.

Nicht von Servern senden.

Nicht zutreffend

Microsoft (nicht im IANA-Register)

HTTP/1.1 450 Blocked by Windows Parental Controls

Der Zugriff wird aufgrund einer rechtlichen Anforderung verweigert: Gerichtsbeschluss, staatliche Zensur oder Geoblocking aus rechtlichen Gründen.

In einem Rechtsraum gesperrte Inhalte (Sanktionen, DSGVO-bedingte Geoblocks, Löschanordnungen). Ein Link-Header mit rel="blocked-by" kann nennen, wer die Sperre verhängt hat.

Nicht für gewöhnliche verweigerte Berechtigungen (403) oder für Inhalte, die du einfach entfernt hast (410).

Standardmäßig cachebar (heuristisch cachebar)

RFC 7725 §3

HTTP/1.1 451 Unavailable For Legal Reasons
Link: <https://authority.example/>; rel="blocked-by"

Wird von einem AWS ALB protokolliert, wenn der Client die Verbindung vor Ablauf des Idle-Timeouts geschlossen hat.

In ALB-Zugriffslogs zu sehen; meist ein Client mit kürzerem Timeout als die Verarbeitungszeit des Ziels.

Wird nicht an Clients gesendet.

Nicht zutreffend

AWS Elastic Load Balancing (nicht im IANA-Register)

elb_status_code=460

Der ALB hat einen X-Forwarded-For-Header mit mehr als 30 IP-Adressen erhalten.

Meist eine Proxy-Schleife, die ständig Adressen anhängt.

Nicht für den Einsatz in Anwendungen.

Nicht zutreffend

AWS Elastic Load Balancing (nicht im IANA-Register)

HTTP/1.1 463

nginx-interner Code für Header, die large_client_header_buffers überschreiten; der Client erhält einen 400.

Erscheint in nginx-Logs und in der error_page-Konfiguration.

Der Standardcode ist 431.

Nicht zutreffend

nginx (nicht im IANA-Register)

error_page 494 /header-too-large.html;

nginx-intern: Der Client hat ein ungültiges Client-Zertifikat vorgelegt (Mutual TLS). Wird an den Client als 400 gesendet.

Eigene Fehlerseiten für mTLS-Fehler.

Kein Statuscode, der tatsächlich übertragen wird.

Nicht zutreffend

nginx (nicht im IANA-Register)

error_page 495 /bad-client-cert.html;

nginx-intern: Ein Client-Zertifikat war erforderlich, wurde aber nicht vorgelegt. Wird an den Client als 400 gesendet.

Eigene Fehlerseiten, wenn ssl_verify_client aktiviert ist.

Kein Statuscode, der tatsächlich übertragen wird.

Nicht zutreffend

nginx (nicht im IANA-Register)

error_page 496 /client-cert-required.html;

nginx-intern: Eine einfache HTTP-Anfrage ist auf einem Port eingegangen, der TLS erwartet. Wird an den Client als 400 gesendet.

Ein gängiger Trick ist „error_page 497 =301 https://$host$request_uri;“, um solche Anfragen auf HTTPS umzuleiten.

Kein Statuscode, der tatsächlich übertragen wird.

Nicht zutreffend

nginx (nicht im IANA-Register)

error_page 497 =301 https://$host:$server_port$request_uri;

ArcGIS gibt ihn bei einem abgelaufenen oder anderweitig ungültigen Token zurück.

Nur relevant beim Aufruf von ArcGIS-Diensten.

Nimm in deinen eigenen APIs 401 für ungültige Tokens.

Nicht zutreffend

Esri ArcGIS (nicht im IANA-Register)

HTTP/1.1 498 Invalid Token

nginx protokolliert 499, wenn der Client die Verbindung geschlossen hat, bevor nginx eine Antwort gesendet hat.

In Zugriffslogs zu sehen: Benutzer, die die Seite verlassen, mobile Clients mit Timeout oder ein Load Balancer vor nginx mit kürzerem Timeout. Viele 499 auf einem Endpunkt bedeuten meist, dass er zu langsam ist.

Der Client erhält ihn nie. Esri verwendet 499 außerdem für „Token Required“.

Nicht zutreffend

nginx (nicht im IANA-Register)

203.0.113.9 - - [16/Oct/2026:10:12:01 +0000] "GET /report HTTP/1.1" 499 0

Der Server ist auf einen unerwarteten Zustand gestoßen, der ihn daran gehindert hat, die Anfrage zu erfüllen.

Unbehandelte Exceptions und Bugs. Er ist der generische Fallback, wenn kein spezifischerer 5xx-Code zutrifft.

Verwende ihn nicht für Fehler des Clients (4xx). Gib in der Produktion keine Stacktraces im Body preis; protokolliere sie stattdessen.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.6.1

HTTP/1.1 500 Internal Server Error
Content-Type: application/problem+json

{"title": "Internal Server Error", "traceId": "4bf92f35"}

Der Server unterstützt die benötigte Funktionalität nicht, typischerweise eine HTTP-Methode, die er überhaupt nicht kennt.

Eine Anfrage mit einer unbekannten Methode (z. B. eine WebDAV-Methode auf einem einfachen Webserver) oder eine Funktion, die der Server bewusst noch nicht umgesetzt hat.

Wenn die Methode bekannt, auf dieser URL aber nicht erlaubt ist, nimm 405.

Standardmäßig cachebar (heuristisch cachebar)

RFC 9110 §15.6.2

HTTP/1.1 501 Not Implemented

Ein Gateway oder Proxy hat vom vorgelagerten Server eine ungültige Antwort erhalten.

Wird von Reverse-Proxys und Load Balancern (nginx, Cloudflare, AWS ALB) gesendet, wenn der App-Server abgestürzt ist, die Verbindung geschlossen oder Unsinn zurückgegeben hat.

Anwendungscode muss ihn selten senden, außer API-Gateways, die einen anderen Dienst aufrufen, der fehlgeschlagen ist.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.6.3

HTTP/1.1 502 Bad Gateway
Server: nginx

Der Server kann die Anfrage gerade nicht bearbeiten: überlastet oder wegen Wartung nicht verfügbar. Voraussichtlich vorübergehend.

Geplante Wartung, Lastabwurf, Ausfall einer Abhängigkeit. Füge Retry-After hinzu. Suchmaschinen behalten die Seite bei kurzen 503-Phasen im Index, anders als bei einer Wartungsseite mit 200 oder einem 404.

Lass eine Website nicht tagelang auf 503; Google entfernt URLs, die ihn dauerhaft zurückgeben, irgendwann aus dem Index.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.6.4

HTTP/1.1 503 Service Unavailable
Retry-After: 3600

Ein Gateway oder Proxy hat vom vorgelagerten Server nicht rechtzeitig eine Antwort erhalten.

Wird von Proxys und Load Balancern gesendet, wenn die Anwendung länger braucht als das Proxy-Timeout (nginx proxy_read_timeout ist standardmäßig 60 Sekunden).

Bei langen Aufgaben erhöhe nicht einfach die Timeouts; gib 202 zurück und verarbeite asynchron.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.6.5

HTTP/1.1 504 Gateway Timeout
Server: awselb/2.0

Der Server unterstützt die in der Anfrage verwendete HTTP-Hauptversion nicht.

Ein Server erhält eine Protokollversion, die er nicht sprechen kann.

Selten zu sehen; Clients handeln HTTP/2 und HTTP/3 über ALPN und Alt-Svc aus, nicht durch Ausprobieren.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 9110 §15.6.6

HTTP/1.1 505 HTTP Version Not Supported

Fehler in der Serverkonfiguration: Die gewählte Variante ist selbst für Negotiation eingerichtet, wodurch eine Schleife entsteht.

Transparente Content Negotiation (experimentell)

Nur Server, die die transparente Content Negotiation nach RFC 2295 umsetzen.

Nicht für Anwendungsfehler.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 2295 §8.1

HTTP/1.1 506 Variant Also Negotiates

Der Server kann nicht speichern, was zur Erfüllung der Anfrage nötig ist.

WebDAV

WebDAV- oder Dateispeicher-APIs, wenn die Festplatte oder das Kontingent des Benutzers voll ist.

Für einen einzelnen Upload, der ein Größenlimit überschreitet, ist 413 klarer.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 4918 §11.5

HTTP/1.1 507 Insufficient Storage

Der Server hat einen Vorgang abgebrochen, weil er eine Endlosschleife gefunden hat (WebDAV-Bindings mit Depth: infinity).

WebDAV

WebDAV-Server. Shared Hosts auf Basis von CloudLinux senden 508 außerdem als „Resource Limit Is Reached“, wenn ein Konto seine Limits erreicht – das ist nicht standardkonform.

Nicht für Umleitungsschleifen; die sind ein clientseitiger Fehler, den der Browser selbst meldet.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 5842 §7.2

HTTP/1.1 508 Loop Detected

Das Hosting-Konto hat sein Bandbreitenkontingent überschritten.

Control Panels von Shared-Hosting-Anbietern.

Nimm in deinen eigenen Systemen 503 oder 429.

Nicht zutreffend

Apache / cPanel (nicht im IANA-Register)

HTTP/1.1 509 Bandwidth Limit Exceeded

Die Anfrage hat die Richtlinie für den Zugriff auf die Ressource gemäß HTTP Extension Framework nicht erfüllt.

Im IANA-Register als obsolet markiert: RFC 2774 wurde auf Historic gesetzt.

Nichts Aktuelles; das Extension Framework wurde nie breit umgesetzt.

Sende ihn nicht.

Nur mit explizitem Cache-Control oder Expires cachebar

RFC 2774 §7

HTTP/1.1 510 Not Extended

Der Client muss sich authentifizieren, um Netzwerkzugang zu erhalten: ein Captive Portal.

WLAN-Portale in Hotels, Flughäfen und Cafés, die den Datenverkehr abfangen, bis sich der Benutzer anmeldet oder die Bedingungen akzeptiert.

Ursprungsserver dürfen ihn nie senden; er ist nur für abfangende Netzwerk-Proxys gedacht.

Darf von Caches nicht gespeichert werden

RFC 6585 §6

HTTP/1.1 511 Network Authentication Required
Content-Type: text/html

<meta http-equiv="refresh" content="0; url=https://login.example.net/">

Der Ursprungsserver hat Cloudflare eine leere, unbekannte oder unerwartete Antwort geliefert.

Prüfe die Logs des Ursprungsservers: Abstürze, Verbindungsabbrüche, Header über dem Cloudflare-Limit oder eine leere Antwort.

Nur Cloudflare sendet ihn.

Nicht zutreffend

Cloudflare (nicht im IANA-Register)

HTTP/2 520
server: cloudflare

Cloudflare konnte keine Verbindung zum Ursprungsserver herstellen: Die Verbindung wurde abgelehnt.

Der Webserver am Ursprung ist gestoppt, oder eine Firewall blockiert die IP-Bereiche von Cloudflare.

Nur Cloudflare sendet ihn.

Nicht zutreffend

Cloudflare (nicht im IANA-Register)

HTTP/2 521
server: cloudflare

Bei Cloudflare ist beim Aufbau einer TCP-Verbindung zum Ursprungsserver ein Timeout aufgetreten.

Ursprungsserver überlastet, Pakete von einer Firewall verworfen oder eine falsche Ursprungs-IP im DNS.

Nur Cloudflare sendet ihn.

Nicht zutreffend

Cloudflare (nicht im IANA-Register)

HTTP/2 522
server: cloudflare

Cloudflare erreicht den Ursprungsserver überhaupt nicht, typischerweise ein Routing-Problem oder ein falscher DNS-Eintrag.

Prüfe, ob die DNS-Einträge A/AAAA auf die richtige, erreichbare IP zeigen.

Nur Cloudflare sendet ihn.

Nicht zutreffend

Cloudflare (nicht im IANA-Register)

HTTP/2 523
server: cloudflare

Cloudflare hat sich mit dem Ursprungsserver verbunden, aber dieser hat innerhalb des Timeouts (standardmäßig 100 Sekunden) keine HTTP-Antwort gesendet.

Lang laufende Anfragen: Verlagere die Arbeit in einen Hintergrundjob und frage den Status ab, oder streame den Fortschritt.

Nur Cloudflare sendet ihn.

Nicht zutreffend

Cloudflare (nicht im IANA-Register)

HTTP/2 524
server: cloudflare

Der TLS-Handshake zwischen Cloudflare und dem Ursprungsserver ist fehlgeschlagen.

Der Ursprungsserver lauscht nicht auf 443, hat kein Zertifikat, keine gemeinsamen Cipher-Suites oder SNI ist nicht konfiguriert, während der SSL-Modus Full oder Full (strict) ist.

Nur Cloudflare sendet ihn.

Nicht zutreffend

Cloudflare (nicht im IANA-Register)

HTTP/2 525
server: cloudflare

Im Modus Full (strict) konnte Cloudflare das Zertifikat des Ursprungsservers nicht validieren: abgelaufen, selbstsigniert oder falscher Hostname.

Installiere auf dem Ursprungsserver ein gültiges Zertifikat oder ein Cloudflare-Origin-CA-Zertifikat.

Nur Cloudflare sendet ihn.

Nicht zutreffend

Cloudflare (nicht im IANA-Register)

HTTP/2 526
server: cloudflare

Verbindungsproblem zwischen Cloudflare und einem Railgun-Listener am Ursprungsserver. Cloudflare hat Railgun eingestellt.

Nur noch historisch.

Nur Cloudflare hat ihn gesendet.

Nicht zutreffend

Cloudflare (nicht im IANA-Register)

HTTP/1.1 527 Railgun Error

Wird mit einer Cloudflare-Fehlerseite 1xxx zurückgegeben (etwa 1016 Origin DNS error); der auf der Seite angezeigte 1xxx-Code ist die eigentliche Ursache.

Schlag die 1xxx-Fehlernummer nach, die auf der Seite angezeigt wird.

Nur CDNs und Hoster senden ihn.

Nicht zutreffend

Cloudflare (nicht im IANA-Register)

HTTP/2 530
server: cloudflare

Die integrierte Authentifizierung des ALB (OIDC oder Cognito) ist beim Identitätsanbieter fehlgeschlagen.

Prüfe die IdP-Konfiguration der Listener-Regel des ALB.

Nicht für den Einsatz in Anwendungen.

Nicht zutreffend

AWS Elastic Load Balancing (nicht im IANA-Register)

HTTP/1.1 561

Wird von einigen Proxys verwendet, um ein Lese-Timeout hinter dem Proxy zu signalisieren.

Selten; er kann bei bestimmten Proxy-Produkten auftauchen.

Nimm 504.

Nicht zutreffend

Informal convention (nicht im IANA-Register)

HTTP/1.1 598

Wird von einigen Proxys und Client-Bibliotheken (etwa dem HTTP-Client von Tornado) für ein Verbindungs-Timeout verwendet.

Selten.

Nimm 504 für Proxys.

Nicht zutreffend

Informal convention (nicht im IANA-Register)

HTTP/1.1 599