4xx-statuscodes uitgelegd: wat clientfouten echt betekenen

Wat de klasse 4xx zegt

RFC 9110 definieert de klasse 4xx als "Client Error": de server meent dat de client een fout maakte. Dat dekt een verzoek om iets dat niet bestaat, een verzoek zonder de benodigde credentials, een verzoek dat de server op beleidsgronden weigert, en een verzoek dat misvormd of te groot is.

Drie eigenschappen van de klasse zijn belangrijk terwijl u er één debugt:

• Een 4xx is een definitief antwoord voor dat verzoek zoals verstuurd. Het identieke verzoek herhalen levert normaal gesproken dezelfde code op.
• De responsbody is bedoeld als een voor mensen leesbare uitleg. Daarom bestaan aangepaste foutpagina's, en daarom is een lege 404-pagina een gemiste kans.
• Sommige 4xx-antwoorden zijn standaard cachebaar. RFC 9111 vermeldt 404, 405, 410 en 414 als codes die een cache heuristisch mag opslaan, dus een verkeerde 404 kan de bug overleven die hem veroorzaakte.

De 4xx-codes die u tegenkomt

• 400 Bad Request: het verzoek is misvormd en de server kan het niet parsen. Vaak een verkeerde querystring, een te grote cookieheader of een kapotte proxy voor de app.
• 401 Unauthorized: authenticatie is vereist en ontbreekt of is ongeldig. De server moet een header WWW-Authenticate sturen die de client vertelt hoe te authenticeren.
• 403 Forbidden: de server begreep het verzoek en weigert het. Credentials helpen niet, want de weigering is een beleidsbeslissing, geen authenticatiefout.
• 404 Not Found: er bestaat geen actuele representatie op die URL, of de server geeft niet toe dat er één bestaat. Uitgebreid behandeld in de 404-handleiding.
• 405 Method Not Allowed: de URL bestaat, maar niet voor die methode. De server moet de methoden die hij wel accepteert in een header Allow opsommen.
• 408 Request Timeout: de client deed er te lang over om het verzoek te versturen. Anders dan een 504, waarbij de vertraging achter de server zit.
• 410 Gone: de resource bestond en werd bewust verwijderd, en dat wordt geacht permanent te zijn.
• 413 Content Too Large en 414 URI Too Long: het verzoek overschreed een ingestelde limiet, meestal een uploadlimiet of een limiet op headergrootte.
• 429 Too Many Requests: er werd een ratelimiet geraakt. Deze bijt vooral in monitoringopstellingen.

Wanneer een 4xx eigenlijk een serverconfiguratiefout is

Het label "clientfout" gaat over protocolrollen, niet over schuld. De meeste 4xx-codes die op een gezonde productiesite verschijnen, worden veroorzaakt door iets aan uw kant. Een herschrijf- of routeringsregel die niet meer matcht, maakt geldige URL's tot 404's over een hele map, en het teken is een 404 op veel URL's tegelijk in plaats van op één. Een build die stopt met het genereren van een gehasht asset doet hetzelfde op bestandsniveau: elke pagina vraagt een bestand op dat 404 teruggeeft, zodat de pagina rendert maar er kapot uitziet.

Beveiligingslagen verklaren het grootste deel van de rest. Een WAF-regel, een botfilter of een geoblokkade kan 403 teruggeven aan echt verkeer, en die zijn makkelijk te missen omdat ze meestal wel doorlaten voor het IP-adres van het kantoor. Een authenticatiewijziging die een pagina 401 laat antwoorden terwijl ze openbaar zou moeten zijn, is een 4xx volledig veroorzaakt door de server. Net als een 400 of 413 van een reverse proxy wiens header- of bodylimiet kleiner is dan die van de applicatie, voor een verzoek dat de app zou hebben geaccepteerd.

Hoe u een 4xx op uw eigen site diagnosticeert

1. Lees eerst de exacte code en headers. Beoordeel niet op de foutpagina, die generiek kan zijn:

   curl -sS -o /dev/null -D - https://example.com/broken-page

   Dit toont de statusregel plus Allow, WWW-Authenticate, Retry-After en elke server- of CDN-identificatieheader.
2. Bepaal of het één URL is of een patroon. Eén URL wijst op een link of een verwijderde pagina. Een heel padprefix wijst op routering, rechten of een deploy.
3. Controleer wie antwoordde. Vergelijk het antwoord van de CDN-edge met het antwoord van de origin. Een 403 die alleen op de edge bestaat, is een WAF- of botregel, niet uw applicatie.
4. Probeer een andere clientidentiteit. Een andere user agent, een niet-geauthenticeerde sessie of een ander netwerk kan de code van 403 naar 200 laten omslaan, wat de blokkade meteen lokaliseert.
5. Lees de serverlogregel voor dat verzoek. Webserver- en applicatielogs registreren welke regel of handler de code produceerde. Dit is de stap die het onderzoek meestal afsluit.
6. Los op, wis dan caches. Omdat verschillende 4xx-codes cachebaar zijn, kan een gecorrigeerde pagina de oude fout van een CDN- of browsercache blijven serveren totdat het item wordt geïnvalideerd.

De 4xx-pagina's vinden die u nooit bezoekt

Een 4xx haalt geen server neer, en daarom blijft het onopgemerkt. De site laadt, de homepage is in orde, en één sectie geeft voor iedereen behalve u 404 of 403 terug. Een geplande HTTP-controle vergelijkt de code die hij ontvangt met de code die u verwacht, dus een pagina die 403 begint te antwoorden in plaats van 200 activeert een waarschuwing in plaats van te wachten op een supportticket. Waar de controle vandaan draait, is ook belangrijk. HostTracker controleert vanaf 300+ controlepunten in 158 steden, dus een geoblokkade of een regionale WAF-regel verschijnt als een echt verschil tussen locaties in plaats van een raadsel. Is de falende code in plaats daarvan 500, 502 of 503, dan ligt de oorzaak aan de kant van de server en is de 5xx-familiehandleiding de plek om te beginnen.