1xx-informatiecodes

Wat een tussentijds antwoord is

Elke andere statusfamilie beëindigt de uitwisseling. Een 200, een 404 of een 502 is het laatste woord van de server over dat verzoek. Een 1xx is anders: de server stuurt de statusregel en eventuele headers, houdt dan de verbinding open en stuurt later een tweede antwoord. RFC 9110 vereist dat clients een of meer 1xx-antwoorden kunnen lezen voordat het eindantwoord komt, en staat elke client die een bepaalde 1xx-code niet begrijpt toe hem te negeren.

Het tussentijdse antwoord wordt weggegooid zodra het eindantwoord aankomt, dus de meeste tools tonen het nooit. Het netwerkpaneel van uw browser, het toegangslog van uw webserver en een monitoringcheck rapporteren allemaal de eindstatus. Het tussentijdse antwoord deed zijn werk op transportniveau en verdween.

De 1xx-codes waar u tegenaan kunt lopen

• 100 Continue. De client stuurde verzoekheaders met Expect: 100-continue en pauzeerde voordat hij een grote body stuurde. Een 100 betekent "headers zien er goed uit, stuur de body". Zou de server het verzoek toch afwijzen, dan kan hij in plaats daarvan met een eindfout antwoorden en verspilt de client nooit bandbreedte aan het uploaden van de payload. Dit is de ene 1xx-code die nuttig werk doet op gewone sites, meestal achter grote bestandsuploads en API-clients zoals curl.
• 101 Switching Protocols. De client vroeg om van protocol te wisselen met een Upgrade-header en de server ging akkoord. Dit is de normale, geslaagde uitkomst van een WebSocket-handshake, dus een 101 in een log is over het algemeen een goed teken, geen incident.
• 102 Processing. Gedefinieerd door de WebDAV-specificatie voor langlopende verzoeken, zodat de client weet dat de server niet is vastgelopen. Het wordt zelden buiten WebDAV geïmplementeerd en u komt het waarschijnlijk niet tegen op een gewone website.
• 103 Early Hints. De server stuurt vroeg Link-headers, voordat hij klaar is met het genereren van de pagina, zodat de browser stylesheets, fonts of scripts kan beginnen voor te laden terwijl de HTML nog geproduceerd wordt. Het is een prestatiefunctie, geen foutsignaal, en u zet het normaal gesproken bewust aan bij de CDN of de origin.

Waarom een 1xx niets is om te repareren

Een 1xx op zich draagt geen fout. Er bestaat niet zoiets als een pagina die "100 teruggeeft" of "101 teruggeeft" zoals een pagina 404 kan teruggeven. Heeft u een probleem en zit er ergens een 1xx in de uitwisseling, dan is de interessante informatie altijd de eindstatuscode die erop volgde, of het feit dat er helemaal geen eindantwoord aankwam.

De echte faalmodi rond 1xx verschijnen als een vastloper of een eindfout in plaats van als de 1xx zelf:

• Een oude proxy of load balancer die tussentijdse antwoorden niet doorstuurt, zodat een client die op 100 Continue wacht, vastloopt totdat zijn eigen time-out afgaat.
• Een WebSocket-upgrade die nooit een 101 bereikt omdat een proxy voor de applicatie de headers Upgrade en Connection strippt. De verbinding valt dan terug of faalt regelrecht.
• Early hints uitgegeven met links naar resources die niet meer bestaan, wat verzoeken verspilt zonder de pagina te breken.

Hoe u een 1xx-antwoord zelf ziet

1. Gebruik een uitgebreide client. Gewone curl -I toont alleen de eindresponsheaders, dus vraag in plaats daarvan om de hele uitwisseling:

   curl -v -H "Expect: 100-continue" --data-binary @big.bin https://example.com/upload

   Een meewerkende server antwoordt met HTTP/1.1 100 Continue voordat de body uitgaat, en dan de uiteindelijke 2xx of 4xx.
2. Controleer voor een WebSocket-pad of de handshake HTTP/1.1 101 Switching Protocols bereikt. Gebeurt dat niet, kijk dan eerst naar de proxylaag: upgradeheaders zijn hop-by-hop, en verschillende gangbare reverse-proxy-configuraties laten ze standaard vallen.
3. Vraag voor early hints de pagina op en kijk naar een blok 103 voorafgaand aan het eindantwoord. Niet elke tussenpartij geeft het door, dus een afwezige 103 betekent niet altijd dat de origin er geen stuurt.
4. Loopt een grote upload vast zonder enig antwoord, probeer dan opnieuw zonder de header Expect. Slaagt de nieuwe poging, dan slikt iets tussen u en de origin tussentijdse antwoorden in.

Monitoren van een uitwisseling die u niet kunt zien

Omdat 1xx-codes nooit een log of dashboard bereiken, is wat u monitort het eindantwoord en hoe lang het duurde om aan te komen. Een uploadpad dat vastloopt op een tussentijds antwoord ziet er van buitenaf precies uit als een traag of time-outend endpoint, en een externe check merkt dat meteen. HostTracker draait checks vanaf 300+ meetpunten in 158 steden, dus een verzoek dat vastloopt achter één specifiek netwerkpad is te onderscheiden van een echte storing. Voer een URL door de HTTP-checktool om de eindstatus en responstijd te zien. De handleidingen 2xx-succescodes en 3xx-omleidingscodes behandelen de antwoorden die een uitwisseling wel beëindigen.