2xx succes-statuscodes

Wat de klasse 2xx dekt

Succes is niet één enkele situatie. Een browser die een pagina ophaalt, een formulier dat een nieuw record post, een achtergrondtaak die werk voor later accepteert, en een videospeler die om bytes 5.000.000 tot 6.000.000 vraagt, zijn allemaal geslaagd, maar ze hebben elk een ander antwoord nodig. Dat is wat de codes in de klasse 2xx coderen. RFC 9110 definieert 200 tot en met 206; een handvol andere komt uit extensies zoals WebDAV.

Bij alledaags webverkeer is de overgrote meerderheid van de geslaagde antwoorden gewoon een 200. De rest doet er vooral toe voor API-clients, uploadpaden en het leveren van media.

De codes in 2xx en wanneer elk verschijnt

• 200 OK. Het standaardsucces. Bij een GET is de body de opgevraagde resource; bij een POST is het het resultaat van de actie. Dit is wat een gezonde pagina teruggeeft.
• 201 Created. Het verzoek heeft een nieuwe resource aangemaakt. Een nette API geeft 201 terug met een Location-header die naar het zojuist aangemaakte object wijst. U ziet dit in API-logs, zelden in een browser.
• 202 Accepted. Het verzoek is geaccepteerd voor verwerking maar is nog niet klaar. Gebruikt voor asynchroon werk zoals een bulkimport of een rapport dat op de achtergrond wordt gegenereerd. Een 202 is een belofte, geen resultaat, dus de client moet doorgaans een status-URL pollen.
• 203 Non-Authoritative Information. Succes, maar een proxy of een tussenliggende partij die transformeert, heeft het antwoord onderweg aangepast. Ongebruikelijk op moderne sites.
• 204 No Content. Succes met opzettelijk geen body. Typisch voor een DELETE, een PUT die is opgeslagen zonder iets terug te hoeven sturen, of een autosave-endpoint. De browser blijft op de huidige pagina.
• 205 Reset Content. Succes, en de client moet het formulier of documentbeeld dat het verzoek verstuurde, resetten. Wordt in de praktijk zelden gebruikt.
• 206 Partial Content. De server geeft alleen het bytebereik terug dat de client vroeg met een Range-header. Zo werken videospoelen, hervatbare downloads en overdrachten van grote bestanden, dus 206 is normaal en verwacht op media-endpoints.
• 207 Multi-Status en 208 Already Reported komen uit WebDAV, waar één verzoek op veel resources kan inwerken en per resource een uitkomst moet melden. 226 IM Used komt uit de delta-encoding-extensie en wordt zeer zelden ingezet.

Waarom een 200 niet bewijst dat de pagina gezond is

Een statuscode beschrijft de uitkomst van de HTTP-transactie, niet de juistheid van wat er terugkwam. Een pagina met een merklogo en "we zijn offline voor onderhoud" wordt met een 200 geserveerd. Dat geldt ook voor een applicatiefoutpagina, wanneer het framework de uitzondering opvangt en een vriendelijke verontschuldiging weergeeft via de normale template met zijn standaardstatus. Een client-gerenderde pagina waarvan de API-aanroep mislukte, geeft 200 terug voor de lege huls rond de ontbrekende content, en een soft 404 geeft 200 terug voor een bericht "pagina niet gevonden", wat ook zoekmachines in verwarring brengt.

In elk van die gevallen meldt een statuscodecheck succes terwijl uw bezoekers een kapotte site zien. De oplossing is een contentcheck: bevestig dat een bekende string aanwezig is in de responsebody, of dat een bekende foutstring afwezig is, naast het controleren van de code.

Hoe u controleert wat een URL echt teruggeeft

1. Vraag alleen om headers en lees de statusregel:

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

2. Is het een 200, haal dan ook de body op en bevestig dat die bevat wat erin hoort. Grep naar een string die alleen op een werkende pagina voorkomt, zoals een kop of een footer-markering.
3. Verifieer voor een API-endpoint of de code overeenkomt met de semantiek: een aanmaak zou 201 moeten zijn met een Location, een verwijdering zou 204 moeten zijn, en een langlopende taak zou 202 moeten zijn met een status-URL.
4. Bevestig voor media dat de server Accept-Ranges: bytes adverteert en een ranged verzoek beantwoordt met 206. Antwoordt hij met 200 op een ranged verzoek, dan wordt spoelen traag omdat het hele bestand opnieuw wordt verstuurd.
5. Herhaal de controle vanaf een ander netwerk. Een antwoord dat bij u 200 is en elders een fout, wijst op DNS, CDN of geografische routering in plaats van op de applicatie.

De body controleren, niet alleen de code

Een statuscodecheck meldt een groene site die een foutpagina serveert, dus combineer die met een content-assertie op hetzelfde verzoek. HostTracker monitort al sinds 2004 websites en biedt 13 monitortypen, dus één URL kan tegelijk worden bewaakt op zijn statuscode, op een trefwoord in het antwoord en op responstijd. Voer een URL door de HTTP-controletool om de code en headers te zien die hij op dit moment teruggeeft, en lees vervolgens wat een 200 OK echt betekent en de serverfoutcodes 5xx voor de storingen die een 200 kan verbergen.