200 OK: was es bedeutet und was es verbirgt

Was ein 200 garantiert

Ein 200 ist der Standard-Erfolgsstatus. Er sagt Ihnen eine eng umrissene, spezifische Menge an Dingen: DNS hat aufgelöst, eine TCP-Verbindung wurde hergestellt, TLS hat verhandelt, falls die URL HTTPS war, der Server hat die Anfragezeile und die Header akzeptiert, und er hat eine Antwort erzeugt, die er als erfolgreich betrachtet. Bei einem GET ist der Body die angeforderte Ressource; bei einem POST ist es das Ergebnis der Aktion.

Was ein 200 Ihnen nicht sagt, ist, ob die Seite den Produktkatalog enthält, ob das Checkout-Formular gerendert wurde, ob das JavaScript, das die Seite füllt, seine Daten erhalten hat, oder ob die Antwort, die Sie erhalten haben, dieselbe ist, die Ihre Besucher in einem anderen Land bekommen. All das steckt im Body, und der Statuscode schaut sich den Body nie an.

Der 200er, der eigentlich ein Fehlschlag ist

Statuscode-Monitoring allein reicht nicht, denn eine defekte Website antwortet in all diesen Fällen mit 200:

• Eine Wartungsseite. Absichtlich mit 200 ausgeliefert, von einem Deployment-Skript oder einer CDN-Regel. Die Uptime sieht für das gesamte Ausfallfenster einwandfrei aus.
• Eine abgefangene Anwendungsausnahme. Das Framework fängt den Fehler ab und rendert eine freundliche "Etwas ist schiefgelaufen"-Seite über die normale Template-Pipeline, die den Standardstatus 200 setzt.
• Ein soft 404. Eine "Seite nicht gefunden"-Meldung wird mit 200 statt 404 zurückgegeben. Besucher sind verwirrt, und Suchmaschinen behalten die URL womöglich indexiert oder stufen das ganze Muster als minderwertig ein.
• Eine leere clientseitig gerenderte Hülle. Das HTML-Dokument lädt einwandfrei, aber der API-Aufruf, der es befüllt, ist fehlgeschlagen. Der Status ist 200 und die Seite ist leer.
• Eine veraltete oder falschsprachige gecachte Kopie. Ein Edge-Knoten, dessen Abruf vom Ursprung fehlschlug, liefert weiterhin das, was er bereits hat, mit 200.
• Eine geparkte oder entführte Domain. Nach einer DNS-Änderung antwortet sie mit 200 und dem Inhalt von jemand anderem.

Ein langsamer 200er ist trotzdem ein Problem

Die Antwortzeit zählt oft mehr als der Code. Eine Seite, die zwölf Sekunden braucht, um 200 zurückzugeben, ist für die meisten Besucher funktional down, denn sie werden gegangen sein, bevor sie fertig ist. Der Statuscode hat überhaupt keine Zeitdimension, Sie müssen die Antwortzeit also separat messen und mit einem Schwellenwert versehen. Auch die Größe lohnt sich aus demselben Grund zu beobachten: Ein 200, der 300 Byte zurückgibt, wo normalerweise 80 KB stehen, ist ein starkes Signal dafür, dass die Seite ohne ihren Inhalt gerendert wurde.

So verifizieren Sie, dass ein 200 ein echter Erfolg ist

1. Lesen Sie Statuszeile und Zeitmessung zusammen:

   curl -sI -o /dev/null -w "%{http_code} in %{time_total}s\n" https://example.com/

2. Rufen Sie den Body ab und prüfen Sie auf einen String, der nur erscheint, wenn die Seite tatsächlich funktioniert, etwa eine Überschrift, ein Preis oder eine Fußzeilen-Markierung, statt auf etwas, das auch das Fehler-Template enthält.
3. Prüfen Sie sowohl auf Abwesenheit als auch auf Anwesenheit. Die Suche nach Formulierungen wie "wird gewartet", "vorübergehend nicht verfügbar" oder dem Ausnahmetext Ihres Frameworks erkennt den Fall der freundlichen Fehlerseite.
4. Vergleichen Sie die Antwortgröße mit einer bekannten guten Basislinie. Ein plötzlicher Einbruch der Body-Länge bedeutet meist, dass die Hülle gerendert wurde und der Inhalt nicht.
5. Prüfen Sie eine tiefer liegende Seite, nicht nur die Startseite. Startseiten sind am stärksten gecacht und antworten am ehesten weiterhin mit 200, während die dahinterliegende Anwendung defekt ist.
6. Wiederholen Sie die Prüfung aus mehr als einem Netzwerk. Ein 200 aus Ihrem Büro und ein Fehler von einem anderen Kontinent deutet auf DNS, CDN oder geografisches Routing hin, nicht auf die Anwendung selbst.

Was eine grüne Uptime-Prüfung übersehen kann

Ein Monitor, der nur den Statuscode liest, meldet eine grüne Website durch einen gesamten Vorfall hindurch, der mit einer nie entfernten Wartungsseite begann. Die Statusprüfung mit einer Schlüsselwort-Bedingung und einem Antwortzeit-Schwellenwert zu kombinieren ist es, was aus "der Server hat geantwortet" ein "die Seite hat funktioniert" macht. HostTracker bietet 13 Monitortypen und alarmiert per E-Mail, SMS, Sprachanruf, Slack, Telegram und mehr, ein Inhaltsfehler löst also denselben Alarm aus wie ein Ausfall. Führen Sie eine URL durch das HTTP-Prüfungstool, um Status, Header und Zeitmessung zu sehen, oder lesen Sie die 2xx-Familie und 500 Internal Server Error für die Antworten, die eine freundliche Fehlerseite verbirgt.