HTTP-Statuscodes

Der Server hat die Header erhalten, der Client darf jetzt den Body schicken. Das ist die Antwort auf Expect: 100-continue – so kann ein Client vor einem großen Upload prüfen, ob der Server ihn überhaupt annimmt.

Der Server wechselt auf das Protokoll, das der Client im Upgrade-Header angefragt hat. Der häufigste Fall ist der Handshake beim Aufbau einer WebSocket-Verbindung.

Ein WebDAV-Code (RFC 2518): Der Server ist noch mit einer langen Anfrage beschäftigt, der Client soll nicht in einen Timeout laufen. In RFC 4918 wurde er wieder gestrichen und spielt heute kaum noch eine Rolle.

Kommt vor der eigentlichen Antwort und enthält Link-Header. Der Browser kann so schon Stylesheets vorladen oder Verbindungen zu anderen Hosts aufbauen, während der Server die Seite noch rendert (RFC 8297). Aktuelle Browser und CDNs wie Cloudflare unterstützen das.

Alles hat geklappt. Bei einem GET steckt die angefragte Ressource im Body – diesen Code sollte jede normale, indexierbare Seite liefern.

Die Anfrage hat eine neue Ressource angelegt, typischerweise nach einem POST oder PUT an eine API. Der Location-Header zeigt meist auf die neue Ressource.

Die Anfrage wurde angenommen, ist aber noch nicht fertig verarbeitet – und kann auch noch scheitern. Üblich bei asynchronen Jobs wie einem Export, der in einer Warteschlange landet.

Die Anfrage war erfolgreich, aber ein zwischengeschalteter Proxy hat den Inhalt der ursprünglichen 200-Antwort verändert.

Erfolgreich, aber bewusst ohne Body. Typisch für API-Aufrufe wie DELETE oder für Formulare, die speichern, ohne die Seite zu verlassen.

Erfolgreich, und der Client soll die Ansicht zurücksetzen, also etwa das gerade abgeschickte Formular leeren. Ein Body wird nicht mitgeschickt.

Der Server liefert nur einen Teil der Ressource, weil der Client einen Range-Header geschickt hat. Damit lassen sich Downloads fortsetzen und Videos oder Audiodateien an beliebiger Stelle abspielen.

Ein WebDAV-Code (RFC 4918): Der Body ist ein XML-Dokument mit eigenen Statuscodes für mehrere Ressourcen oder Operationen.

Wird innerhalb einer WebDAV-207-Antwort genutzt (RFC 5842), damit dieselbe gebundene Ressource nicht mehrfach aufgelistet wird.

Der Server liefert das Ergebnis einer Instanz-Manipulation, etwa nur die Änderungen statt des ganzen Dokuments (RFC 3229). In freier Wildbahn so gut wie nie zu sehen.

Es gibt mehrere Varianten der Ressource (etwa verschiedene Sprachen oder Formate), und Client oder Nutzer sollen eine auswählen. Browser gehen damit uneinheitlich um, deshalb wird er kaum eingesetzt.

Die Ressource ist dauerhaft unter die URL im Location-Header umgezogen. Clients dürfen dabei aus einem POST ein GET machen. Der Klassiker für Domainumzüge, die Umstellung auf HTTPS und geänderte URLs – mehr dazu unter 301 vs. 302.

Die Ressource liegt vorübergehend unter einer anderen URL, die ursprüngliche URL bleibt gültig. Wie bei 301 machen Browser aus einem POST in der Regel ein GET.

Der Client soll eine andere URL per GET abrufen. Klassisch nach einem Formular-POST, um auf eine Bestätigungsseite weiterzuleiten (Post/Redirect/Get). So wird das Formular beim Neuladen nicht doppelt abgeschickt.

Die Antwort auf eine bedingte Anfrage mit If-None-Match oder If-Modified-Since: Die Ressource hat sich nicht geändert, der Client kann seine Kopie aus dem Cache nehmen. Die Antwort hat keinen Body.

Veraltet. Sollte den Client anweisen, über einen Proxy zuzugreifen. Weil das ein Sicherheitsrisiko war, ignorieren Browser den Code.

Hieß in einem frühen Entwurf "Switch Proxy". Der Code ist reserviert und wird nicht mehr verwendet.

Eine temporäre Weiterleitung wie 302 – nur muss der Client die Anfrage mit derselben Methode und demselben Body wiederholen. Einen internen 307 zeigen Browser auch an, wenn HSTS den Wechsel von HTTP auf HTTPS erzwingt. Details in 307 vs. 308.

Eine dauerhafte Weiterleitung wie 301, aber Methode und Body dürfen sich nicht ändern – ein POST bleibt ein POST. Ideal für APIs und Formular-Endpunkte (ursprünglich in RFC 7538 definiert).

Der Server kann die Anfrage wegen eines Fehlers auf Client-Seite nicht verarbeiten, zum Beispiel wegen fehlerhafter Syntax, eines ungültigen Headers oder eines zu großen Cookies.

Für die Anfrage ist eine Anmeldung nötig, und es wurden keine oder falsche Zugangsdaten mitgeschickt. Der Server muss im WWW-Authenticate-Header angeben, wie die Anmeldung funktioniert.

Für die Zukunft reserviert. Manche APIs und Dienste nutzen ihn bei aufgebrauchtem Kontingent oder unbezahltem Konto, eine einheitliche Bedeutung gibt es aber nicht.

Der Server hat die Anfrage verstanden, verweigert aber den Zugriff. Anders als bei 401 hilft eine Anmeldung meist nicht – Ursache sind fehlende Rechte, eine IP-Sperre oder eine Firewall-Regel.

Unter dieser URL findet der Server nichts. Ob das nur vorübergehend oder für immer so ist, sagt der Code nicht. Der häufigste Fehler im Web, meist verursacht durch kaputte Links oder fehlende Weiterleitungen nach einem Relaunch.

Die Ressource gibt es, aber sie unterstützt die Methode nicht – etwa ein POST auf eine statische Seite. Die Antwort muss einen Allow-Header mit den erlaubten Methoden enthalten.

Der Server hat keine Variante, die zu den Accept-Headern des Clients passt (Inhaltstyp, Sprache, Kodierung). Manche Sicherheitsmodule missbrauchen ihn außerdem, um Anfragen zu blocken.

Wie 401, nur muss sich der Client bei einem Proxy anmelden. Der Proxy schickt dazu einen Proxy-Authenticate-Header.

Die vollständige Anfrage kam nicht rechtzeitig beim Server an, deshalb schließt er die Verbindung. Der Client darf es erneut versuchen.

Die Anfrage passt nicht zum aktuellen Zustand der Ressource – zum Beispiel eine Änderung auf Basis einer veralteten Version oder der Versuch, etwas anzulegen, das schon existiert.

Die Ressource wurde absichtlich entfernt, kommt nicht wieder, und es gibt keine neue Adresse. Für bewusst gelöschte Inhalte eindeutiger als 404.

Der Server lehnt die Anfrage ab, weil der Content-Length-Header fehlt.

Eine Bedingung aus den Request-Headern wie If-Match oder If-Unmodified-Since ist nicht erfüllt. So verhinderst du, dass Änderungen von jemand anderem überschrieben werden.

Der Request-Body ist größer, als der Server verarbeiten will – typischerweise ein Upload über einem Limit wie client_max_body_size bei nginx. Hieß früher "Payload Too Large".

Die URL ist länger, als der Server akzeptiert. Taucht gern bei fehlerhaften Redirect-Regeln auf, die bei jedem Schritt Parameter anhängen, bis die URL zu lang wird.

Der Server kann mit dem Format des Request-Bodys nichts anfangen, etwa XML an eine API, die nur JSON versteht. Prüf den Content-Type-Header.

Der Byte-Bereich im Range-Header liegt außerhalb der Ressource, zum Beispiel hinter dem Dateiende.

Der Server kann die Anforderung im Expect-Header nicht erfüllen, meist Expect: 100-continue.

Bekannt als "I'm a teapot" aus dem Aprilscherz-RFC 2324 (Hyper Text Coffee Pot Control Protocol). RFC 9110 reserviert den Code, weil ihn so viele Server als Gag implementiert haben – anderweitig vergeben wird er deshalb nicht.

Die Anfrage ist bei einem Server gelandet, der für diesen Host keine Antwort liefern kann. Passiert bei HTTP/2, wenn eine Verbindung wiederverwendet wird und ein TLS-Zertifikat mehrere Domains abdeckt, die auf verschiedenen Servern laufen.

Die Anfrage ist syntaktisch korrekt, inhaltlich aber ungültig – etwa ein JSON-Body, der die Validierung nicht besteht. In REST-APIs sehr verbreitet; hieß früher "Unprocessable Entity" und stammt aus WebDAV.

Ein WebDAV-Code (RFC 4918): Die Ressource ist gesperrt, zum Beispiel weil gerade jemand anderes sie bearbeitet.

Ein WebDAV-Code (RFC 4918): Die Anfrage ist gescheitert, weil eine vorherige Anfrage, von der sie abhängt, fehlgeschlagen ist.

Der Server verarbeitet eine Anfrage nicht, die als TLS-1.3-Early-Data (0-RTT) kam, weil sie wiederholt eingespielt werden könnte (RFC 8470). Der Client soll es nach dem Handshake erneut versuchen.

Der Server lehnt die Anfrage mit dem aktuellen Protokoll ab und nennt im Upgrade-Header das nötige, etwa eine neuere TLS- oder HTTP-Version.

Der Server verlangt eine bedingte Anfrage, zum Beispiel mit If-Match, damit keine Änderungen verloren gehen (RFC 6585).

Der Client hat in kurzer Zeit zu viele Anfragen geschickt (Rate Limiting, RFC 6585). Ein Retry-After-Header kann angeben, wie lange er warten soll.

Ein einzelner Header oder alle Header zusammen sind zu groß (RFC 6585). Häufige Ursache sind zu viele oder zu große Cookies – die Cookies der Domain zu löschen, hilft meistens.

Die Ressource darf aus rechtlichen Gründen nicht ausgeliefert werden, etwa wegen eines Gerichtsbeschlusses oder gesetzlich vorgeschriebenen Geoblockings (RFC 7725). Die Zahl ist eine Anspielung auf Ray Bradburys "Fahrenheit 451".

Der Allzweck-Fehler: Auf dem Server ist etwas schiefgelaufen, und kein spezifischerer Code passt. Typische Ursachen sind PHP-Fatal-Errors, ungültige Direktiven in der .htaccess oder eine ausgefallene Datenbankverbindung. Mehr verrät dir das Error-Log des Servers.

Der Server unterstützt die für die Anfrage nötige Funktion nicht, typischerweise eine unbekannte Request-Methode.

Ein Gateway oder Reverse Proxy (etwa nginx oder ein CDN) hat vom dahinterliegenden Server eine ungültige Antwort bekommen – zum Beispiel, weil ein PHP-FPM- oder Node.js-Prozess abgestürzt ist.

Der Server kann die Anfrage gerade nicht bearbeiten, weil er überlastet ist oder gewartet wird. Ein Retry-After-Header kann angeben, wann es wieder klappt. Der richtige Code für geplante Wartungsfenster.

Ein Gateway oder Proxy hat vom dahinterliegenden Server nicht rechtzeitig eine Antwort bekommen, etwa weil ein Skript länger läuft als der Proxy-Timeout.

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

Ein Konfigurationsfehler bei der transparenten Content Negotiation (RFC 2295): Die gewählte Variante verhandelt selbst wieder, dadurch entsteht eine Schleife.

Ein WebDAV-Code (RFC 4918): Der Server kann die nötigen Daten nicht speichern, zum Beispiel weil die Festplatte oder das Kontingent voll ist.

Ein WebDAV-Code (RFC 5842): Der Server hat beim Verarbeiten eine Endlosschleife entdeckt. Manche Hoster nutzen ihn auch, wenn ein Account seine Ressourcenlimits überschreitet.

Der Server braucht für die Anfrage weitere Erweiterungen (RFC 2774). Das zugrundeliegende Erweiterungs-Framework gilt als historisch, der Code wird praktisch nicht genutzt.

Der Client muss sich anmelden, um überhaupt ins Netz zu kommen (RFC 6585). Kommt von Captive Portals im Hotel- oder Flughafen-WLAN, nicht von der Website, die du aufrufen willst.