2xx-Erfolgsstatuscodes

Was die 2xx-Familie abdeckt

Erfolg ist keine einzelne Bedingung. Ein Browser, der eine Seite abruft, ein Formular, das einen neuen Datensatz postet, ein Hintergrundjob, der Arbeit für später annimmt, und ein Videoplayer, der nach den Bytes 5.000.000 bis 6.000.000 fragt, sind alle erfolgreich, brauchen aber unterschiedliche Antworten. Genau das kodieren die 2xx-Codes. RFC 9110 definiert 200 bis 206; eine Handvoll andere stammen aus Erweiterungen wie WebDAV.

Beim alltäglichen Web-Traffic sind die weit überwiegende Mehrheit der erfolgreichen Antworten schlichte 200er. Der Rest ist vor allem für API-Clients, Upload-Pfade und Medienauslieferung wichtig.

Die 2xx-Codes und wann jeder erscheint

• 200 OK. Der Standarderfolg. Bei einem GET ist der Body die angeforderte Ressource; bei einem POST ist es das Ergebnis der Aktion. Das gibt eine gesunde Seite zurück.
• 201 Created. Die Anfrage hat eine neue Ressource erstellt. Eine wohlerzogene API gibt 201 mit einem Location-Header zurück, der auf das gerade Erstellte zeigt. Das sehen Sie in API-Protokollen, selten in einem Browser.
• 202 Accepted. Die Anfrage wurde zur Verarbeitung angenommen, ist aber nicht fertig. Genutzt für asynchrone Arbeit wie einen Massenimport oder einen Bericht, der im Hintergrund erzeugt wird. Ein 202 ist ein Versprechen, kein Ergebnis, der Client muss also normalerweise eine Status-URL abfragen.
• 203 Non-Authoritative Information. Erfolg, aber ein Proxy oder ein transformierender Vermittler hat die Antwort unterwegs verändert. Auf modernen Websites unüblich.
• 204 No Content. Erfolg mit absichtlich leerem Body. Typisch für ein DELETE, ein PUT, das gespeichert hat, ohne etwas zurückspiegeln zu müssen, oder einen Autosave-Endpunkt. Der Browser bleibt auf der aktuellen Seite.
• 205 Reset Content. Erfolg, und der Client soll das Formular oder die Dokumentansicht zurücksetzen, die die Anfrage gesendet hat. In der Praxis selten genutzt.
• 206 Partial Content. Der Server gibt nur den Byte-Bereich zurück, nach dem der Client mit einem Range-Header gefragt hat. So funktionieren Video-Seeking, fortsetzbare Downloads und große Dateiübertragungen, 206 ist also normal und erwartet auf Medien-Endpunkten.
• 207 Multi-Status und 208 Already Reported stammen aus WebDAV, wo eine Anfrage auf viele Ressourcen wirken kann und pro Ressource ein Ergebnis melden muss. 226 IM Used stammt aus der Delta-Encoding-Erweiterung und wird sehr selten eingesetzt.

Warum ein 200 nicht beweist, dass die Seite gesund ist

Ein Statuscode beschreibt das Ergebnis der HTTP-Transaktion, nicht die Richtigkeit dessen, was zurückkam. Eine gebrandete "wir sind wegen Wartung offline"-Seite wird mit einem 200 ausgeliefert. Genauso eine Anwendungsfehlerseite, wenn das Framework die Ausnahme fängt und eine freundliche Entschuldigung über das normale Template mit seinem Vorgabe-Status rendert. Eine clientseitig gerenderte Seite, deren API-Aufruf fehlschlug, gibt 200 für die leere Hülle rund um den fehlenden Inhalt zurück, und ein Soft-404 gibt 200 für eine "Seite nicht gefunden"-Meldung zurück, was auch Suchmaschinen verwirrt.

In jedem dieser Fälle meldet eine Statuscode-Prüfung Erfolg, während Ihre Besucher eine kaputte Website sehen. Die Lösung ist eine Content-Prüfung: bestätigen Sie, dass eine bekannte Zeichenfolge im Antwortkörper vorhanden ist, oder dass eine bekannte Fehlerzeichenfolge fehlt, zusätzlich zur Prüfung des Codes.

So prüfen Sie, was eine URL wirklich zurückgibt

1. Fragen Sie nur nach Headern und lesen Sie die Statuszeile:

   curl -sI https://example.com/ | head -n 1

2. Ist es ein 200, holen Sie auch den Body und bestätigen Sie, dass er enthält, was er soll. Grep nach einer Zeichenfolge, die nur auf einer funktionierenden Seite erscheint, etwa einer Überschrift oder einem Fußzeilen-Marker.
3. Bei einem API-Endpunkt prüfen Sie, ob der Code zur Semantik passt: Ein Create sollte 201 mit einem Location sein, ein Delete sollte 204 sein, und ein lang laufender Job sollte 202 mit einer Status-URL sein.
4. Bestätigen Sie bei Medien, dass der Server Accept-Ranges: bytes ankündigt und eine Range-Anfrage mit 206 beantwortet. Antwortet er einer Range-Anfrage mit 200, wird das Seeking langsam sein, weil die ganze Datei erneut gesendet wird.
5. Wiederholen Sie die Prüfung von einem anderen Netzwerk aus. Eine Antwort, die für Sie 200 ist und woanders ein Fehler, deutet auf DNS, CDN oder geografisches Routing statt auf die Anwendung.

Den Body prüfen, nicht nur den Code

Eine Statuscode-Prüfung meldet eine grüne Website, die eine Fehlerseite ausliefert, kombinieren Sie sie also mit einer Content-Assertion auf derselben Anfrage. HostTracker überwacht Websites seit 2004 und bietet 13 Monitor-Typen, eine URL kann also gleichzeitig auf ihren Statuscode, ein Schlüsselwort in der Antwort und die Antwortzeit überwacht werden. Führen Sie eine URL durch das HTTP-Prüfungstool, um den Code und die Header zu sehen, die sie gerade jetzt zurückgibt, und lesen Sie dann was ein 200 OK wirklich bedeutet und die 5xx-Serverfehlercodes für die Fehler, die ein 200 verbergen kann.