200 OK: wat het betekent en wat het verbergt

Wat een 200 garandeert

Een 200 is de standaard successtatus. Ze vertelt u een smalle, specifieke set dingen: DNS herleidde, er kwam een TCP-verbinding tot stand, TLS onderhandelde als de URL HTTPS was, de server accepteerde de verzoekregel en headers, en produceerde een antwoord dat hij als geslaagd beschouwt. Voor een GET is de body de opgevraagde resource; voor een POST is het het resultaat van de actie.

Wat een 200 u niet vertelt, is of de pagina de productcatalogus bevat, of het afrekenformulier rendered, of de JavaScript die de pagina vult zijn data ontving, of het antwoord dat u kreeg hetzelfde is als wat uw bezoekers in een ander land krijgen. Dat alles leeft in de body, en de statuscode kijkt nooit naar de body.

De 200 die eigenlijk een mislukking is

Statuscodemonitoring op zich is niet genoeg, want een kapotte site antwoordt in al deze gevallen met 200:

• Een onderhoudspagina. Bewust bediend met 200 door een deploymentscript of een CDN-regel. Uptime ziet er perfect uit voor het hele storingsvenster.
• Een opgevangen applicatie-uitzondering. Het framework vangt de fout af en rendert een vriendelijke "er ging iets mis"-pagina via de normale template-pipeline, die de standaardstatus van 200 zet.
• Een zachte 404. Een "pagina niet gevonden"-bericht teruggegeven met 200 in plaats van 404. Bezoekers raken in verwarring en zoekmachines kunnen de URL geïndexeerd houden of het hele patroon als laagwaardig behandelen.
• Een lege client-gerenderde shell. Het HTML-document laadt prima, maar de API-aanroep die het vult, mislukte. De status is 200 en de pagina is leeg.
• Een verouderde of verkeerde-taal gecachete kopie. Een edge-node wiens origin-fetch mislukte blijft bedienen wat hij al heeft, met 200.
• Een geparkeerd of gekaapt domein. Na een DNS-wijziging antwoordt het met 200 met de content van iemand anders.

Een trage 200 is nog steeds een probleem

Responstijd doet er vaak meer toe dan de code. Een pagina die twaalf seconden nodig heeft om 200 terug te geven, is voor de meeste bezoekers functioneel down, want zij zijn al weg voordat ze klaar is. De statuscode heeft helemaal geen tijddimensie, dus u moet responstijd apart meten en er een drempel op zetten. Grootte is om dezelfde reden de moeite van bekijken waard: een 200 die 300 bytes teruggeeft waar hij normaal 80 KB teruggeeft, is een sterk signaal dat de pagina rendered zonder zijn content.

Hoe u verifieert dat een 200 echt geslaagd is

1. Lees de statusregel en de timing samen:

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

2. Haal de body op en toets op een string die alleen verschijnt wanneer de pagina daadwerkelijk werkt, zoals een titel, een prijs of een footer-markering, in plaats van op iets dat de foutentemplate ook bevat.
3. Toets ook op afwezigheid, niet alleen aanwezigheid. Zoeken naar zinnen zoals "in onderhoud", "tijdelijk niet beschikbaar" of de uitzonderingsbewoording van uw framework, vangt het geval van de vriendelijke fout.
4. Vergelijk de responsgrootte met een bekend goede basislijn. Een plotselinge instorting van de bodylengte betekent meestal dat de shell rendered en de content niet.
5. Controleer een diepe pagina, niet alleen de homepage. Homepages worden het zwaarst gecachet en blijven het meest waarschijnlijk 200 antwoorden terwijl de applicatie erachter kapot is.
6. Herhaal vanaf meer dan één netwerk. Een 200 vanuit uw kantoor en een fout vanaf een ander continent wijst op DNS, CDN of geografische routering in plaats van de applicatie zelf.

Wat een groene uptimecheck kan missen

Een monitor die alleen de statuscode leest, meldt een groene site door een heel incident heen dat begon met een onderhoudspagina die niemand verwijderde. De statuscheck combineren met een trefwoordtoets en een responstijddrempel is wat "de server antwoordde" verandert in "de pagina werkte". HostTracker biedt 13 monitortypen en waarschuwt per e-mail, sms, spraakoproep, Slack, Telegram en meer, dus een contentmismatch geeft dezelfde waarschuwing als een storing. Voer een URL door de HTTP-checktool om de status, headers en timing te zien, of lees de 2xx-familie en 500 Internal Server Error voor de antwoorden die een vriendelijke foutpagina verbergt.