HTTP-Statuscodes

Vollständige Referenz aller HTTP-Statuscodes mit Beschreibungen und Beispielen.

61 von 61 angezeigt

1xx Informell

4 Statuscodes

100

Fortfahren

Der Server hat die Anfrage-Header empfangen und der Client sollte mit dem Senden des Anfrage-Bodys fortfahren. Dies wird verwendet, um große Uploads zu optimieren, indem der Client prüfen kann, ob der Server die Anfrage akzeptiert, bevor die vollständige Nutzlast gesendet wird.

Häufige Anwendungsfälle: Wird verwendet, wenn ein Client einen Expect: 100-continue-Header sendet, bevor er einen großen Anfrage-Body hochlädt, sodass der Server die Anfrage frühzeitig ablehnen kann, ohne Bandbreite zu verschwenden.

RFC 9110
101

Protokollwechsel

Der Server wechselt zu einem anderen Protokoll, wie vom Client über einen Upgrade-Header angefordert. Der Server stimmt zu und wird nach dieser Antwort über das neue Protokoll kommunizieren.

Häufige Anwendungsfälle: Am häufigsten beim Upgrade einer HTTP-Verbindung auf eine WebSocket-Verbindung zu sehen. Der Client sendet einen Upgrade: websocket-Header und der Server antwortet mit 101, um den Wechsel zu bestätigen.

RFC 9110
102

Verarbeitung

Der Server hat die Anfrage empfangen und verarbeitet sie, aber es ist noch keine Antwort verfügbar. Dies verhindert, dass der Client eine Zeitüberschreitung erleidet, während der Server an einem lang laufenden Vorgang arbeitet.

Häufige Anwendungsfälle: Wird bei WebDAV-Operationen verwendet, die lange dauern können. Teilt dem Client mit, dass der Server die Verbindung nicht getrennt hat und noch an der Anfrage arbeitet.

RFC 2518
103

Frühe Hinweise

Der Server sendet vorläufige Antwort-Header vor der endgültigen Antwort. Dies ermöglicht es dem Client, mit dem Vorladen von Ressourcen zu beginnen, während der Server noch die vollständige Antwort vorbereitet.

Häufige Anwendungsfälle: Wird verwendet, um Link-Header frühzeitig zu senden, damit der Browser CSS, JavaScript oder Schriftarten vorladen kann, bevor die endgültige HTML-Antwort eintrifft, was die Seitenladezeit verbessert.

RFC 8297

2xx Erfolg

10 Statuscodes

200

OK

Die Anfrage war erfolgreich. Die Bedeutung des Erfolgs hängt von der HTTP-Methode ab: GET gibt die angeforderte Ressource zurück, POST gibt das Ergebnis der Aktion zurück und so weiter.

Häufige Anwendungsfälle: Die Standard-Erfolgsantwort für die meisten API-Aufrufe. Wird verwendet, wenn eine GET-Anfrage Daten zurückgibt, eine PUT-Anfrage eine Ressource aktualisiert oder eine Operation erfolgreich mit einem Antwort-Body abgeschlossen wird.

RFC 9110
Anfrage
GET /api/users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Antwort
HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 42,
  "name": "Jane Doe",
  "email": "jane@example.com",
  "created_at": "2025-08-15T10:30:00Z"
}
201

Erstellt

Die Anfrage wurde erfüllt und eine neue Ressource wurde erstellt. Die Antwort enthält typischerweise einen Location-Header, der auf die neu erstellte Ressource verweist.

Häufige Anwendungsfälle: Wird nach einer erfolgreichen POST-Anfrage zurückgegeben, die eine neue Ressource erstellt, z. B. das Anlegen eines neuen Benutzerkontos, das Hinzufügen eines Blog-Beitrags oder das Hochladen einer Datei.

RFC 9110
Anfrage
POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "Jane Doe",
  "email": "jane@example.com"
}
Antwort
HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/users/42

{
  "id": 42,
  "name": "Jane Doe",
  "email": "jane@example.com",
  "created_at": "2025-08-15T10:30:00Z"
}
202

Akzeptiert

Die Anfrage wurde zur Verarbeitung angenommen, aber die Verarbeitung ist noch nicht abgeschlossen. Die Anfrage könnte letztendlich ausgeführt werden oder auch nicht, da sie bei der tatsächlichen Verarbeitung abgelehnt werden könnte.

Häufige Anwendungsfälle: Wird für asynchrone Operationen verwendet, bei denen der Server eine Aufgabe zur späteren Verarbeitung einreiht, z. B. das Senden einer E-Mail, das Erstellen eines Berichts oder das Auslösen eines Batch-Jobs.

RFC 9110
203

Nicht-autoritative Information

Die Anfrage war erfolgreich, aber die zurückgegebenen Metadaten in den Headern stammen möglicherweise von einer lokalen oder Drittanbieter-Kopie und nicht vom Ursprungsserver. Die enthaltene Nutzlast ist eine modifizierte Version der 200-Antwort des Ursprungsservers.

Häufige Anwendungsfälle: Wird in der Praxis selten verwendet. Kann auftreten, wenn ein transformierender Proxy die Antwort-Header des Ursprungsservers ändert, was darauf hinweist, dass die Metadaten möglicherweise nicht mit dem Original übereinstimmen.

RFC 9110
204

Kein Inhalt

Der Server hat die Anfrage erfolgreich erfüllt und es gibt keinen zusätzlichen Inhalt im Antwort-Body. Die Antwort kann aktualisierte Header enthalten.

Häufige Anwendungsfälle: Wird nach einer erfolgreichen DELETE-Anfrage zurückgegeben oder bei einem PUT/PATCH-Update, bei dem kein Antwort-Body benötigt wird. Auch für Fire-and-Forget-Operationen verwendet, bei denen eine Bestätigung allein ausreicht.

RFC 9110
Anfrage
DELETE /api/users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Antwort
HTTP/1.1 204 No Content
205

Inhalt zurücksetzen

Der Server hat die Anfrage erfüllt und möchte, dass der Benutzeragent die Dokumentansicht zurücksetzt, die das Senden der Anfrage verursacht hat. Es wird kein Antwort-Body mitgeliefert.

Häufige Anwendungsfälle: Wird verwendet, um dem Client mitzuteilen, dass er das Formular oder die Benutzeroberfläche zurücksetzen soll, die die Anfrage abgesendet hat. Zum Beispiel kann der Server nach dem erfolgreichen Absenden eines Formulars dem Browser signalisieren, die Formularfelder zu leeren.

RFC 9110
206

Teilweiser Inhalt

Der Server liefert nur einen Teil der Ressource aufgrund eines Range-Headers, der vom Client gesendet wurde. Dies wird für fortsetzbare Downloads und Media-Streaming verwendet.

Häufige Anwendungsfälle: Wird verwendet, wenn ein Client einen bestimmten Byte-Bereich einer großen Datei anfordert und ermöglicht Funktionen wie fortsetzbare Downloads, Video-Seeking und parallele Chunk-Downloads.

RFC 9110
207

Multi-Status

Eine WebDAV-Antwort, die Informationen über mehrere Ressourcen übermittelt, wenn mehrere Statuscodes angemessen sein könnten. Der Antwort-Body ist ein XML-Dokument mit individuellen Statuscodes für jede Unteranfrage.

Häufige Anwendungsfälle: Wird bei WebDAV-Batch-Operationen verwendet, bei denen jede Unteroperation ein unterschiedliches Ergebnis haben kann. Zum Beispiel beim Kopieren mehrerer Dateien, bei dem einige erfolgreich sind und andere fehlschlagen.

RFC 4918
208

Bereits gemeldet

Wird innerhalb eines DAV: propstat-Antwortelements verwendet, um zu vermeiden, dass die internen Mitglieder mehrerer Bindungen an dieselbe Sammlung wiederholt aufgezählt werden.

Häufige Anwendungsfälle: Ein WebDAV-Status, der verhindert, dass dieselbe Ressource mehrfach aufgelistet wird, wenn sie aufgrund von Bindungen an mehreren Stellen innerhalb einer Sammlung erscheint.

RFC 5842
226

IM verwendet

Der Server hat eine GET-Anfrage für die Ressource erfüllt, und die Antwort ist eine Darstellung des Ergebnisses einer oder mehrerer Instanz-Manipulationen, die auf die aktuelle Instanz angewendet wurden.

Häufige Anwendungsfälle: Wird mit Delta-Kodierung verwendet, um nur die Änderungen (Deltas) zwischen der aktuellen Version einer Ressource und einer zuvor zwischengespeicherten Version zu senden und so die Bandbreitennutzung zu reduzieren.

RFC 3229

3xx Weiterleitung

7 Statuscodes

300

Mehrere Auswahlmöglichkeiten

Die Zielressource hat mehr als eine Darstellung und der Benutzer oder Benutzeragent kann eine bevorzugte auswählen. Der Server kann eine Liste der verfügbaren Darstellungen bereitstellen.

Häufige Anwendungsfälle: Wird in der Praxis selten verwendet. Könnte eingesetzt werden, wenn eine Ressource in mehreren Formaten verfügbar ist (z. B. JSON, XML, HTML) und der Server möchte, dass der Client explizit auswählt.

RFC 9110
301

Dauerhaft verschoben

Der Zielressource wurde eine neue permanente URI zugewiesen und alle zukünftigen Verweise auf diese Ressource sollten die zurückgegebene Location-URI verwenden. Suchmaschinen aktualisieren ihren Index.

Häufige Anwendungsfälle: Wird verwendet, wenn eine Seite oder ein API-Endpunkt dauerhaft an eine neue URL verschoben wurde. Unverzichtbar für SEO beim Umstrukturieren einer Website, beim Wechsel des Domainnamens oder beim Auslaufen alter URL-Muster.

RFC 9110
Anfrage
GET /old-page HTTP/1.1
Host: www.example.com
Antwort
HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-page
Content-Type: text/html

<html><body>This page has moved to <a href="https://www.example.com/new-page">/new-page</a>.</body></html>
302

Gefunden

Die Zielressource befindet sich vorübergehend unter einer anderen URI. Da die Weiterleitung gelegentlich geändert werden kann, sollte der Client weiterhin die ursprüngliche URI für zukünftige Anfragen verwenden.

Häufige Anwendungsfälle: Wird für temporäre Weiterleitungen verwendet, z. B. Weiterleitung zu einer Anmeldeseite, Weiterleitung von Benutzern zu einer Wartungsseite oder A/B-Tests verschiedener Seitenversionen.

RFC 9110
Anfrage
GET /dashboard HTTP/1.1
Host: www.example.com
Antwort
HTTP/1.1 302 Found
Location: https://www.example.com/login?redirect=/dashboard
303

Siehe andere

Der Server leitet den Benutzeragenten mit einer GET-Anfrage zu einer anderen Ressource weiter, typischerweise nach einer POST-Operation. Dies stellt sicher, dass der Client die Formulardaten nicht erneut übermittelt.

Häufige Anwendungsfälle: Wird nach einer POST-Formularübermittlung verwendet, um auf eine Bestätigungsseite weiterzuleiten (das Post/Redirect/Get-Muster), wodurch doppelte Formularübermittlungen beim Aktualisieren der Seite verhindert werden.

RFC 9110
304

Nicht modifiziert

Die Ressource wurde seit der in den Anfrage-Headern If-Modified-Since oder If-None-Match angegebenen Version nicht modifiziert. Der Server muss den Ressourcen-Body nicht erneut senden.

Häufige Anwendungsfälle: Wird zurückgegeben, wenn ein Client eine bedingte Anfrage stellt und sich die Ressource nicht geändert hat, sodass der Client seine zwischengespeicherte Kopie verwenden kann. Dies spart Bandbreite und verbessert die Ladezeiten.

RFC 9110
Anfrage
GET /api/users/42 HTTP/1.1
Host: api.example.com
If-None-Match: "etag-abc123"
Antwort
HTTP/1.1 304 Not Modified
ETag: "etag-abc123"
Cache-Control: max-age=3600
307

Temporäre Weiterleitung

Die Zielressource befindet sich vorübergehend unter einer anderen URI und der Benutzeragent darf die Anfragemethode bei der Weiterleitung nicht ändern. Im Gegensatz zu 302 bleiben Methode und Body garantiert gleich.

Häufige Anwendungsfälle: Wird verwendet, wenn eine temporäre Weiterleitung benötigt wird, die die HTTP-Methode strikt beibehält. Zum Beispiel die Weiterleitung einer POST-Anfrage zu einem anderen Endpunkt, ohne sie in eine GET-Anfrage umzuwandeln.

RFC 9110
308

Permanente Weiterleitung

Der Zielressource wurde eine neue permanente URI zugewiesen. Wie 301, aber die Anfragemethode und der Body dürfen bei der Weiterleitung nicht geändert werden.

Häufige Anwendungsfälle: Wird für permanente Weiterleitungen verwendet, wenn die HTTP-Methode beibehalten werden muss. Zum Beispiel die permanente Weiterleitung eines POST-Endpunkts, wobei sichergestellt wird, dass Clients weiterhin POST-Anfragen senden.

RFC 9110

4xx Client-Fehler

29 Statuscodes

400

Ungültige Anfrage

Der Server kann oder will die Anfrage nicht verarbeiten, weil etwas als Client-Fehler wahrgenommen wird, wie z. B. fehlerhafte Anfrage-Syntax, ungültiges Anfrage-Framing oder irreführendes Anfrage-Routing.

Häufige Anwendungsfälle: Wird zurückgegeben, wenn der Anfrage-Body fehlerhaftes JSON enthält, Pflichtfelder fehlen, Query-Parameter ungültig sind oder die Anfrage anderweitig nicht dem erwarteten Format entspricht.

RFC 9110
Anfrage
POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "",
  "email": "not-an-email"
}
Antwort
HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error": "validation_error",
  "message": "Request validation failed",
  "details": [
    { "field": "name", "message": "Name is required" },
    { "field": "email", "message": "Must be a valid email address" }
  ]
}
401

Nicht autorisiert

Die Anfrage wurde nicht angewendet, weil gültige Authentifizierungsdaten für die Zielressource fehlen. Die Antwort muss einen WWW-Authenticate-Header enthalten, der das anwendbare Authentifizierungsschema angibt.

Häufige Anwendungsfälle: Wird zurückgegeben, wenn einer Anfrage Authentifizierungsdaten fehlen oder das bereitgestellte Token/die Anmeldeinformationen abgelaufen oder ungültig sind. Der Client muss sich authentifizieren, bevor er es erneut versucht.

RFC 9110
Anfrage
GET /api/users/me HTTP/1.1
Host: api.example.com
Antwort
HTTP/1.1 401 Unauthorized
Content-Type: application/json
WWW-Authenticate: Bearer

{
  "error": "unauthorized",
  "message": "Authentication required. Please provide a valid Bearer token."
}
402

Zahlung erforderlich

Für zukünftige Verwendung reserviert. Ursprünglich für digitale Zahlungssysteme vorgesehen, ist dieser Statuscode nicht weit verbreitet standardisiert, wird aber manchmal von APIs verwendet, um anzuzeigen, dass eine Zahlung erforderlich ist.

Häufige Anwendungsfälle: Obwohl offiziell reserviert, verwenden einige APIs diesen Code, um anzuzeigen, dass eine kostenpflichtige Funktion oder ein Abonnement erforderlich ist oder dass der Benutzer sein kostenloses Kontingent überschritten hat.

RFC 9110
403

Verboten

Der Server hat die Anfrage verstanden, weigert sich aber, sie zu autorisieren. Im Gegensatz zu 401 hilft eine Authentifizierung nicht weiter. Der Client verfügt nicht über die erforderlichen Berechtigungen für die Ressource.

Häufige Anwendungsfälle: Wird zurückgegeben, wenn der Benutzer authentifiziert ist, aber nicht über die erforderlichen Berechtigungen verfügt. Zum Beispiel ein normaler Benutzer, der auf einen Admin-Endpunkt zugreift, oder der Zugriff auf eine Ressource, die einem anderen Benutzer gehört.

RFC 9110
Anfrage
DELETE /api/users/99 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Antwort
HTTP/1.1 403 Forbidden
Content-Type: application/json

{
  "error": "forbidden",
  "message": "You do not have permission to delete this user. Admin role required."
}
404

Nicht gefunden

Der Ursprungsserver hat keine aktuelle Darstellung für die Zielressource gefunden oder ist nicht bereit, deren Existenz offenzulegen. Dies kann vorübergehend oder dauerhaft sein.

Häufige Anwendungsfälle: Der am häufigsten auftretende Fehler. Wird zurückgegeben, wenn die angeforderte Ressource nicht existiert, z. B. bei der Abfrage eines Benutzers mit einer ID, die nicht in der Datenbank vorhanden ist, oder beim Aufrufen einer URL ohne passende Route.

RFC 9110
Anfrage
GET /api/users/99999 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Antwort
HTTP/1.1 404 Not Found
Content-Type: application/json

{
  "error": "not_found",
  "message": "User with ID 99999 was not found"
}
405

Methode nicht erlaubt

Die in der Anfrage empfangene Methode ist dem Ursprungsserver bekannt, wird aber von der Zielressource nicht unterstützt. Die Antwort muss einen Allow-Header mit den gültigen Methoden enthalten.

Häufige Anwendungsfälle: Wird zurückgegeben, wenn die HTTP-Methode für den Endpunkt nicht unterstützt wird. Zum Beispiel das Senden einer DELETE-Anfrage an eine schreibgeschützte Ressource oder einer POST-Anfrage an einen Endpunkt, der nur GET unterstützt.

RFC 9110
Anfrage
DELETE /api/reports/monthly HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Antwort
HTTP/1.1 405 Method Not Allowed
Content-Type: application/json
Allow: GET, HEAD

{
  "error": "method_not_allowed",
  "message": "DELETE is not allowed on this resource. Allowed methods: GET, HEAD"
}
406

Nicht akzeptabel

Die Zielressource hat keine Darstellung, die gemäß den im Request empfangenen proaktiven Content-Negotiation-Headern für den Benutzeragenten akzeptabel wäre.

Häufige Anwendungsfälle: Wird zurückgegeben, wenn der Server keine Antwort erzeugen kann, die den vom Client gesendeten Accept-Headern entspricht. Zum Beispiel wenn ein Client XML anfordert, die API aber nur JSON unterstützt.

RFC 9110
407

Proxy-Authentifizierung erforderlich

Ähnlich wie 401, aber der Client muss sich beim Proxy authentifizieren. Der Proxy muss einen Proxy-Authenticate-Header mit der entsprechenden Herausforderung zurückgeben.

Häufige Anwendungsfälle: Wird von einem Proxy-Server zurückgegeben, wenn der Client keine gültigen Anmeldeinformationen für den Proxy selbst bereitgestellt hat. Häufig in Unternehmensnetzwerken, in denen der ausgehende Datenverkehr über einen authentifizierten Proxy läuft.

RFC 9110
408

Anfrage-Zeitüberschreitung

Der Server hat innerhalb der Wartezeit keine vollständige Anfragenachricht empfangen. Der Client kann die Anfrage zu einem späteren Zeitpunkt ohne Änderungen wiederholen.

Häufige Anwendungsfälle: Wird zurückgegeben, wenn der Client zu lange braucht, um die vollständige Anfrage zu senden. Kann bei langsamen Verbindungen, großen Uploads über unzuverlässige Netzwerke oder wenn ein Client eine Verbindung öffnet, aber keine Daten sendet, auftreten.

RFC 9110
409

Konflikt

Die Anfrage konnte aufgrund eines Konflikts mit dem aktuellen Zustand der Zielressource nicht abgeschlossen werden. Der Client sollte in der Lage sein, den Konflikt zu lösen und die Anfrage erneut einzureichen.

Häufige Anwendungsfälle: Wird verwendet, wenn eine Anfrage mit vorhandenen Daten in Konflikt steht, z. B. das Erstellen eines Benutzers mit einer bereits vorhandenen E-Mail-Adresse oder der Versuch, eine Ressource zu aktualisieren, die seit dem letzten Abruf von einer anderen Anfrage geändert wurde.

RFC 9110
Anfrage
POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "Jane Doe",
  "email": "jane@example.com"
}
Antwort
HTTP/1.1 409 Conflict
Content-Type: application/json

{
  "error": "conflict",
  "message": "A user with email jane@example.com already exists",
  "existing_id": 42
}
410

Entfernt

Die Zielressource ist auf dem Ursprungsserver nicht mehr verfügbar und dieser Zustand ist wahrscheinlich dauerhaft. Im Gegensatz zu 404 wird hier ausdrücklich angegeben, dass die Ressource einst existierte, aber absichtlich entfernt wurde.

Häufige Anwendungsfälle: Wird verwendet, wenn eine Ressource absichtlich und dauerhaft gelöscht wurde. Signalisiert Suchmaschinen, dass sie die URL aus ihrem Index entfernen sollten, im Gegensatz zu 404, das vorübergehend sein kann.

RFC 9110
411

Längenangabe erforderlich

Der Server lehnt die Anfrage ohne definierten Content-Length-Header ab. Der Client kann die Anfrage wiederholen, wenn ein gültiger Content-Length-Header hinzugefügt wird.

Häufige Anwendungsfälle: Wird zurückgegeben, wenn der Server den Content-Length-Header in der Anfrage verlangt, typischerweise bei Uploads oder POST-Anfragen, bei denen der Server die Nutzlastgröße im Voraus wissen muss.

RFC 9110
412

Vorbedingung fehlgeschlagen

Eine oder mehrere Bedingungen in den Anfrage-Header-Feldern ergaben bei der serverseitigen Prüfung false. Wird bei bedingten Anfragen wie If-Match oder If-Unmodified-Since verwendet.

Häufige Anwendungsfälle: Wird zurückgegeben, wenn ein bedingtes Update fehlschlägt, weil die Ressource seit dem letzten Abruf durch den Client geändert wurde. Wird zur Implementierung optimistischer Nebenläufigkeitskontrolle in APIs verwendet.

RFC 9110
413

Inhalt zu groß

Der Server weigert sich, die Anfrage zu verarbeiten, weil die Anfrage-Nutzlast größer ist, als der Server verarbeiten kann oder möchte. Der Server kann die Verbindung schließen oder einen Retry-After-Header zurückgeben.

Häufige Anwendungsfälle: Wird zurückgegeben, wenn ein Datei-Upload oder Anfrage-Body die konfigurierte Maximalgröße des Servers überschreitet, z. B. beim Hochladen einer 100-MB-Datei an einen Endpunkt mit einem 10-MB-Limit.

RFC 9110
414

URI zu lang

Der Server weigert sich, die Anfrage zu bearbeiten, weil das Anfrageziel länger ist, als der Server interpretieren möchte. Dies kann auftreten, wenn eine GET-Anfrage übermäßig lange Query-Parameter hat.

Häufige Anwendungsfälle: Wird zurückgegeben, wenn die URL die maximale Länge des Servers überschreitet. Dies passiert häufig, wenn zu viele Daten in Query-Parametern kodiert werden, anstatt sie in einem POST-Anfrage-Body zu senden.

RFC 9110
415

Nicht unterstützter Medientyp

Der Ursprungsserver weigert sich, die Anfrage zu bearbeiten, weil die Nutzlast in einem Format vorliegt, das von dieser Methode auf der Zielressource nicht unterstützt wird. Der Content-Type oder Content-Encoding ist nicht akzeptabel.

Häufige Anwendungsfälle: Wird zurückgegeben, wenn der Server den in der Anfrage gesendeten Content-Type nicht unterstützt. Zum Beispiel das Senden von form-urlencoded-Daten an einen Endpunkt, der nur application/json akzeptiert.

RFC 9110
416

Bereich nicht erfüllbar

Die Menge der Bereiche im Range-Header-Feld der Anfrage wurde abgelehnt, weil keiner der angeforderten Bereiche für die ausgewählte Darstellung erfüllbar ist.

Häufige Anwendungsfälle: Wird zurückgegeben, wenn ein Client einen Byte-Bereich anfordert, der außerhalb der Größe der Ressource liegt, z. B. die Anforderung der Bytes 1000-2000 einer 500-Byte-Datei.

RFC 9110
417

Erwartung fehlgeschlagen

Die im Expect-Header-Feld der Anfrage angegebene Erwartung konnte von mindestens einem der eingehenden Server nicht erfüllt werden.

Häufige Anwendungsfälle: Wird zurückgegeben, wenn der Server die im Expect-Header angegebenen Anforderungen nicht erfüllen kann. Am häufigsten im Zusammenhang mit dem Expect: 100-continue-Mechanismus, wenn der Server die Anfrage ablehnt, bevor der Body gesendet wird.

RFC 9110
418

Ich bin eine Teekanne

Jeder Versuch, Kaffee mit einer Teekanne zu brühen, sollte zu diesem Fehlercode führen. Dies wurde im Hyper Text Coffee Pot Control Protocol als Aprilscherz definiert, aber als kulturelles Kuriosum bewahrt.

Häufige Anwendungsfälle: Ein Easter-Egg-Statuscode aus einem Aprilscherz-RFC. Wird manchmal humorvoll in APIs als lustige Antwort verwendet oder als bewusste Ablehnung einer Anfrage, die der Server als absurd betrachtet.

RFC 2324
421

Fehlgeleitete Anfrage

Die Anfrage wurde an einen Server gerichtet, der keine Antwort erzeugen kann. Dies kann auftreten, wenn ein Server nicht für die Kombination aus Schema und Autorität im Anfrage-URI konfiguriert ist.

Häufige Anwendungsfälle: Kann in HTTP/2 auftreten, wenn eine Verbindung für einen anderen Hostnamen wiederverwendet wird, den der Server nicht verarbeiten kann. Der Client sollte die Anfrage über eine andere Verbindung erneut versuchen.

RFC 9110
422

Nicht verarbeitbarer Inhalt

Der Server versteht den Inhaltstyp und die Syntax der Anfrage ist korrekt, aber er konnte die enthaltenen Anweisungen nicht verarbeiten. Die Anfrage ist wohlgeformt, aber semantisch ungültig.

Häufige Anwendungsfälle: Wird verwendet, wenn der Anfrage-Body syntaktisch gültiges JSON ist, aber die Geschäftslogik-Validierung fehlschlägt. Zum Beispiel das Setzen eines negativen Preises, das Planen eines Meetings in der Vergangenheit oder die Angabe eines Enddatums vor einem Startdatum.

RFC 9110
Anfrage
POST /api/events HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "title": "Team Meeting",
  "start_date": "2025-12-01",
  "end_date": "2025-11-01"
}
Antwort
HTTP/1.1 422 Unprocessable Content
Content-Type: application/json

{
  "error": "unprocessable_entity",
  "message": "Semantic validation failed",
  "details": [
    { "field": "end_date", "message": "End date must be after start date" }
  ]
}
423

Gesperrt

Die Quell- oder Zielressource einer Methode ist gesperrt. Der Client sollte es später erneut versuchen oder eine Entsperrung anfordern.

Häufige Anwendungsfälle: Wird in WebDAV verwendet, wenn eine Ressource von einem anderen Benutzer oder Prozess gesperrt ist. Kann auch in APIs verwendet werden, um anzuzeigen, dass eine Ressource vorübergehend von einem anderen Benutzer zur Bearbeitung gesperrt ist.

RFC 4918
424

Fehlgeschlagene Abhängigkeit

Die Methode konnte nicht auf der Ressource ausgeführt werden, weil die angeforderte Aktion von einer anderen Aktion abhing, die fehlgeschlagen ist.

Häufige Anwendungsfälle: Wird in WebDAV verwendet, wenn eine Operation fehlschlägt, weil eine vorausgesetzte Operation, von der sie abhängt, ebenfalls fehlgeschlagen ist. Zum Beispiel schlägt das Kopieren eines Verzeichnisses fehl, weil das Kopieren einer der untergeordneten Dateien fehlgeschlagen ist.

RFC 4918
425

Zu früh

Der Server ist nicht bereit, eine Anfrage zu verarbeiten, die möglicherweise wiederholt wird, um potenzielle Replay-Angriffe bei der Verwendung von TLS 1.3 Early Data (0-RTT) zu vermeiden.

Häufige Anwendungsfälle: Wird verwendet, wenn eine Anfrage in TLS 1.3 Early Data (0-RTT) eintrifft und der Server nicht garantieren kann, dass sie nicht bereits verarbeitet wurde. Verhindert Replay-Angriffe auf nicht-idempotente Anfragen.

RFC 8470
426

Upgrade erforderlich

Der Server weigert sich, die Anfrage mit dem aktuellen Protokoll auszuführen, ist aber möglicherweise bereit, dies zu tun, nachdem der Client auf ein anderes Protokoll gewechselt hat. Der Server muss einen Upgrade-Header mit dem erforderlichen Protokoll angeben.

Häufige Anwendungsfälle: Wird verwendet, wenn der Server vom Client den Wechsel zu einer neueren Protokollversion verlangt, z. B. ein Upgrade von HTTP/1.1 auf HTTP/2 oder von einer unverschlüsselten Verbindung auf TLS.

RFC 9110
428

Vorbedingung erforderlich

Der Ursprungsserver verlangt, dass die Anfrage bedingt ist. Dies soll das Problem des verlorenen Updates verhindern, bei dem ein Client eine Ressource per GET abruft, sie ändert und per PUT zurücksendet, während ein anderer Client sie ebenfalls geändert hat.

Häufige Anwendungsfälle: Wird zurückgegeben, wenn der Server bedingte Header wie If-Match oder If-Unmodified-Since erfordert, um Probleme durch gleichzeitige Änderungen zu vermeiden. Zwingt Clients zur Implementierung optimistischer Sperren.

RFC 6585
429

Zu viele Anfragen

Der Benutzer hat in einem bestimmten Zeitraum zu viele Anfragen gesendet (Ratenbegrenzung). Die Antwort sollte einen Retry-After-Header enthalten, der angibt, wie lange vor einer neuen Anfrage gewartet werden soll.

Häufige Anwendungsfälle: Wird zurückgegeben, wenn der Client das API-Ratenlimit überschreitet. Die meisten APIs verwenden dies zum Schutz vor Missbrauch und zur Gewährleistung fairer Nutzung. Clients sollten zurückweichen und nach der im Retry-After-Header angegebenen Zeit erneut versuchen.

RFC 6585
Anfrage
GET /api/search?q=test HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Antwort
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1735689600

{
  "error": "rate_limit_exceeded",
  "message": "Rate limit exceeded. Maximum 100 requests per minute.",
  "retry_after": 60
}
431

Anfrage-Header-Felder zu groß

Der Server ist nicht bereit, die Anfrage zu verarbeiten, weil ihre Header-Felder zu groß sind. Die Anfrage kann nach Reduzierung der Größe der Anfrage-Header-Felder erneut eingereicht werden.

Häufige Anwendungsfälle: Wird zurückgegeben, wenn Anfrage-Header die Größenlimits des Servers überschreiten. Dies passiert häufig, wenn Cookies zu groß werden oder zu viele Daten in benutzerdefinierten Headern oder einem übergroßen Authorization-Token übergeben werden.

RFC 6585
451

Aus rechtlichen Gründen nicht verfügbar

Der Server verweigert den Zugriff auf die Ressource aufgrund einer rechtlichen Anforderung. Die Antwort sollte eine Erklärung der rechtlichen Einschränkung im Body und einen Link-Header zur Identifizierung der rechtlichen Instanz enthalten.

Häufige Anwendungsfälle: Wird verwendet, wenn eine Ressource aufgrund rechtlicher Anforderungen blockiert ist, z. B. staatliche Zensuranordnungen, DMCA-Takedown-Benachrichtigungen, Gerichtsbeschlüsse oder Sanktionsvorschriften. Die Codenummer verweist auf Fahrenheit 451.

RFC 7725

5xx Server-Fehler

11 Statuscodes

500

Interner Serverfehler

Der Server ist auf eine unerwartete Bedingung gestoßen, die ihn daran gehindert hat, die Anfrage zu erfüllen. Dies ist ein generischer Auffangfehler, wenn kein spezifischerer 5xx-Statuscode angemessen ist.

Häufige Anwendungsfälle: Der häufigste Serverfehler. Wird zurückgegeben, wenn der Server auf eine nicht behandelte Ausnahme, einen Fehler, einen Datenbankverbindungsfehler oder ein anderes unerwartetes Problem während der Anfrageverarbeitung stößt.

RFC 9110
Antwort
HTTP/1.1 500 Internal Server Error
Content-Type: application/json

{
  "error": "internal_server_error",
  "message": "An unexpected error occurred. Please try again later.",
  "request_id": "req_abc123xyz"
}
501

Nicht implementiert

Der Server unterstützt die zur Erfüllung der Anfrage erforderliche Funktionalität nicht. Dies ist die angemessene Antwort, wenn der Server die Anfragemethode nicht erkennt und nicht in der Lage ist, sie zu unterstützen.

Häufige Anwendungsfälle: Wird zurückgegeben, wenn der Server die angeforderte HTTP-Methode nicht erkennt oder noch nicht implementiert hat. Kann als Platzhalter für API-Endpunkte verwendet werden, die geplant, aber noch nicht erstellt sind.

RFC 9110
502

Fehlerhaftes Gateway

Der Server hat in seiner Funktion als Gateway oder Proxy eine ungültige Antwort von einem Upstream-Server erhalten, auf den er bei dem Versuch, die Anfrage zu erfüllen, zugegriffen hat.

Häufige Anwendungsfälle: Wird von Reverse-Proxys, Load-Balancern oder API-Gateways zurückgegeben, wenn der Upstream-Anwendungsserver eine fehlerhafte Antwort sendet, abstürzt oder nicht erreichbar ist. Häufig während Deployments.

RFC 9110
Antwort
HTTP/1.1 502 Bad Gateway
Content-Type: application/json

{
  "error": "bad_gateway",
  "message": "The upstream server returned an invalid response. Please try again shortly."
}
503

Dienst nicht verfügbar

Der Server ist derzeit nicht in der Lage, die Anfrage aufgrund vorübergehender Überlastung oder geplanter Wartung zu bearbeiten. Dies ist ein vorübergehender Zustand und der Server wird bald wieder verfügbar sein.

Häufige Anwendungsfälle: Wird während geplanter Wartungsfenster, bei Serverüberlastung oder wenn eine kritische Abhängigkeit ausgefallen ist, zurückgegeben. Der Retry-After-Header kann angeben, wann der Client es erneut versuchen sollte.

RFC 9110
Antwort
HTTP/1.1 503 Service Unavailable
Content-Type: application/json
Retry-After: 300

{
  "error": "service_unavailable",
  "message": "Service is temporarily unavailable for scheduled maintenance. Expected back at 2025-12-01T03:00:00Z.",
  "retry_after": 300
}
504

Gateway-Zeitüberschreitung

Der Server hat in seiner Funktion als Gateway oder Proxy keine rechtzeitige Antwort von einem Upstream-Server erhalten, auf den er zugreifen musste, um die Anfrage abzuschließen.

Häufige Anwendungsfälle: Wird von Reverse-Proxys oder Load-Balancern zurückgegeben, wenn der Upstream-Anwendungsserver zu lange für eine Antwort braucht. Weist oft auf eine langsame Datenbankabfrage, ein Timeout einer externen API oder ein überlastetes Backend hin.

RFC 9110
505

HTTP-Version nicht unterstützt

Der Server unterstützt die in der Anfragenachricht verwendete Hauptversion von HTTP nicht oder lehnt deren Unterstützung ab.

Häufige Anwendungsfälle: Wird zurückgegeben, wenn der Server die in der Anfrage verwendete HTTP-Protokollversion nicht unterstützt, z. B. ein Server, der nur HTTP/1.1 unterstützt und eine HTTP/2-Anfrage empfängt, die er nicht verarbeiten kann.

RFC 9110
506

Variante verhandelt ebenfalls

Der Server hat einen internen Konfigurationsfehler: Die gewählte Varianten-Ressource ist so konfiguriert, dass sie selbst an der transparenten Inhaltsaushandlung teilnimmt, was zu einer Zirkelverweisung führt.

Häufige Anwendungsfälle: Ein seltener Fehler, der auf eine Fehlkonfiguration bei der Inhaltsaushandlung auf der Serverseite hinweist, bei der die ausgehandelte Ressource selbst versucht zu verhandeln, wodurch eine Endlosschleife entsteht.

RFC 2295
507

Unzureichender Speicher

Die Methode konnte nicht auf der Ressource ausgeführt werden, weil der Server die Darstellung, die zum erfolgreichen Abschluss der Anfrage erforderlich ist, nicht speichern kann.

Häufige Anwendungsfälle: Ein WebDAV-Status, der zurückgegeben wird, wenn dem Server beim Versuch, Daten zu schreiben, der Speicherplatz oder das Speicherkontingent ausgeht. Kann auch für APIs gelten, bei denen ein Speicherlimit erreicht wurde.

RFC 4918
508

Schleife erkannt

Der Server hat eine Operation beendet, weil er beim Verarbeiten einer Anfrage mit Depth: infinity eine Endlosschleife erkannt hat. Dies ist eine spezifischere Version von 500.

Häufige Anwendungsfälle: Ein WebDAV-Status, der zurückgegeben wird, wenn der Server eine zirkuläre Abhängigkeit oder Endlosschleife in Ressourcenbindungen erkennt, z. B. eine Verzeichnisstruktur, die auf sich selbst verweist.

RFC 5842
510

Nicht erweitert

Die Richtlinie für den Zugriff auf die Ressource wurde in der Anfrage nicht erfüllt. Der Server sollte alle Informationen zurücksenden, die der Client benötigt, um eine erweiterte Anfrage zu stellen.

Häufige Anwendungsfälle: Ein selten verwendeter Statuscode, der anzeigt, dass weitere Erweiterungen der Anfrage erforderlich sind, damit der Server sie erfüllen kann. Definiert in der HTTP Extension Framework-Spezifikation.

RFC 2774
511

Netzwerkauthentifizierung erforderlich

Der Client muss sich authentifizieren, um Netzwerkzugang zu erhalten. Dies betrifft nicht die Authentifizierung auf HTTP-Ebene, sondern den Zugang auf Netzwerkebene, z. B. die Anmeldung an einem Captive-Portal.

Häufige Anwendungsfälle: Wird von Captive-Portalen (z. B. Hotel- oder Flughafen-WLAN-Anmeldeseiten) zurückgegeben, wenn der Benutzer sich noch nicht beim Netzwerk authentifiziert hat. Der Antwort-Body enthält typischerweise eine Anmeldeseite.

RFC 6585

Verwandte Leitfäden

36 Header

HTTP-Header

Gängige HTTP-Header erklärt mit Syntax, Beispielen und häufigen Werten.

Durchsuchen
9 Methoden

HTTP-Methoden

Vollständiger Leitfaden zu HTTP-Anfragemethoden mit Vergleichstabellen und Beispielen.

Durchsuchen
70 MIME-Typen

MIME-Typen

Vollständige Referenz gängiger MIME-Typen mit Dateierweiterungen, Kategorien und Anwendungsbeispielen.

Durchsuchen
10 Header

CORS erklärt

Vollständiger Leitfaden zu Cross-Origin Resource Sharing — wie es funktioniert, jeder Header erklärt und häufige Fehler mit Lösungen.

Durchsuchen

In RequestDock ausprobieren

Echte HTTP-Anfragen senden und Antworten inspizieren — direkt im Browser.

RequestDock öffnen