406 Not Acceptable: wat het betekent en hoe u het oplost

Wat 406 Not Acceptable betekent

HTTP ondersteunt contentonderhandeling via een familie van Accept-headers: Accept voor het mediatype van het antwoord, Accept-Language voor de taal, en Accept-Encoding voor compressie. Een client kan een van deze versturen om te zeggen "geef me alleen een antwoord dat ik kan gebruiken." Volgens RFC 9110 antwoordt de server, als hij geen representatie kan produceren die de client aangaf te zullen accepteren, en hij ervoor kiest dat te signaleren in plaats van toch iets te sturen, met 406. In de praktijk negeren de meeste servers een smalle Accept-header stilzwijgend en sturen ze in plaats daarvan hun standaardantwoord, wat is waarom een echte 406 minder vaak voorkomt dan de header zelf.

Hoe de fout verschijnt

Een browser triggert zelden een 406 bij normale paginaladingen, omdat browsers permissieve Accept-headers versturen die met bijna alles overeenkomen wat een server aanbiedt. Hij verschijnt veel vaker bij API-clients, scripts, en commandoregeltools die een strikte Accept-header instellen:

curl -i -H "Accept: application/xml" https://api.example.com/v1/status
HTTP/1.1 406 Not Acceptable
Content-Type: application/json

In dat voorbeeld vroeg de client alleen om XML en kan de API alleen JSON produceren, dus weigert de server in plaats van een formaat te sturen dat de client expliciet zei niet te willen.

Wat een 406 Not Acceptable veroorzaakt

• Contentonderhandeling die echt mislukt. Een header Accept, Accept-Language, of Accept-Encoding die alleen formaten noemt die de server niet kan produceren, meestal een client die XML opvraagt bij een alleen-JSON-API, of een specifieke taalvariant die de server niet heeft.
• Een web application firewall bij shared hosting. Dit is een heel gebruikelijke praktijkoorzaak die niets met contentonderhandeling te maken heeft: ModSecurity en vergelijkbare WAF-regels in shared-hostingomgevingen blokkeren verzoeken waarvan de Accept-header ongewoon, ontbrekend, of geautomatiseerd oogt, en antwoorden met 406 als blokkeerantwoord ongeacht wat er werd onderhandeld.
• Een API die alleen JSON serveert, geraakt door een client die Accept: text/html stuurt. Sommige API's zijn hier strikt in en weigeren in plaats van te degraderen, wat naar boven komt als 406 voor elke client, inclusief een browsertab die rechtstreeks op het endpoint werd geopend.
• Een verkeerd geconfigureerde reverse proxy of CDN-regel die op basis van de Accept-header inspecteert en weigert om redenen van caching of botfiltering, los van wat de origin-server kan produceren.
• Overdreven strikte afhandeling van Accept-Encoding. Een server geconfigureerd om elk verzoek te weigeren dat geen compressiemethode noemt die hij verkiest, in plaats van terug te vallen op een ongecomprimeerd antwoord.

Hoe u vaststelt wiens fout het is

Raakt alleen een specifiek script of een specifieke integratie 406, controleer dan wat de Accept-headers ervan zeggen, aangezien een versmalde of verkeerd geconfigureerde header aan de clientkant vaak de directe oorzaak is. Werkt hetzelfde verzoek met een gewone, permissieve Accept-header maar faalt het met een specifieke, dan kan de server dat formaat echt niet serveren. Raakt normaal browserverkeer ook getroffen, of begon de fout vlak na een hosting- of WAF-wijziging zonder codewijziging aan uw kant, dan zijn beveiligingsregels van shared hosting de waarschijnlijkere boosdoener, en een HTTP-controle vanaf meerdere locaties met precies de headers die uw integratie stuurt is de snelste manier om te bevestigen of de blokkade consistent is of specifiek voor één netwerk.

Hoe u een 406 Not Acceptable oplost

Bent u de bezoeker

1. Verwijder of versoepel de Accept-header in welk script of tool het verzoek ook stuurt, als u er controle over heeft, en laat het het standaardformaat accepteren dat de server aanbiedt.
2. Controleer de documentatie van de API voor welke contenttypen en talen die ondersteunt voordat u aanneemt dat de server kapot is.
3. Probeer het verzoek rechtstreeks vanuit een browser, aangezien browsers brede Accept-headers versturen en deze fout zelden treffen, wat helpt bevestigen dat de blokkade specifiek is voor de headers van uw client.

Beheert u de site

1. Controleer eerst uw ModSecurity- of WAF-regels als de 406 onverwacht en wijdverspreid is, aangezien shared-hostingomgevingen vaak blokkeren op basis van patronen in de Accept-header in plaats van een echte onderhandelingsstoring. Bekijk de eigen logs van de WAF voor het gematchte regel-id voordat u applicatiecode aanraakt.
2. Bevestig welke formaten uw API daadwerkelijk serveert, en ondersteun ofwel meer van wat echte clients vragen ofwel documenteer de vereiste duidelijk zodat een 406 informatief is in plaats van verrassend.
3. Val terug op een standaardrepresentatie in plaats van ronduit te weigeren, waar dat aanvaardbaar is voor uw API, aangezien de meeste echte clients "hier is JSON ook al vroeg u breed" beter afhandelen dan een ronduit afwijzing.
4. Controleer regels van reverse proxy en CDN op iets dat de Accept-header inspecteert voor caching of botbeheer, aangezien een regel bedoeld voor één doel als bijeffect 406 kan opleveren voor niet-verwant verkeer.

Hoe u voorkomt dat een 406 een integratie platlegt

Een 406 geïntroduceerd door een beveiligingsupdate van een hostingprovider of een nieuwe WAF-regel ziet er van binnen uw eigen netwerk niet uit als een storing, aangezien uw eigen verzoeken andere headers kunnen gebruiken dan die van een getroffen integratie. Een geplande HTTP-controle die dezelfde Accept-header stuurt die uw echte clients gebruiken, met een assertie op de verwachte statuscode, vangt een onderhandelingsstoring op het moment dat die begint. Controleren vanaf meerdere locaties helpt ook een hostingbrede WAF-regel te scheiden van een die alleen bij bepaalde edge-knooppunten geldt.

Gerelateerde fouten

Zie 403 Forbidden voor het nauw verwante geval van een WAF- of botregel die een verzoek ronduit blokkeert in plaats van via contentonderhandeling, het 4xx-overzicht voor de bredere familie, en 413 Payload Too Large elders in deze reeks.

Veelgestelde vragen

Is 406 hetzelfde als een CORS-fout?

Nee. CORS-storingen gebeuren omdat de browser weigert een cross-origin-antwoord aan het aanroepende script bloot te stellen; 406 is de server zelf die weigert een responsbody te produceren omdat hij niet aan het gevraagde formaat, de taal, of de codering kan voldoen.

Waarom zie ik 406 alleen vanuit curl of Postman, nooit vanuit de browser?

Browsers versturen standaard brede, permissieve Accept-headers. Tools zoals curl versturen niets of een smalle header tenzij u er expliciet een instelt, wat veel eerder een echte onderhandelingsstoring triggert of een WAF-regel raakt die is afgesteld om ongewone headers te markeren.

Kan een 406 van ModSecurity komen zelfs als mijn Accept-header volkomen normaal is?

Ja. Veel ModSecurity-regelsets van shared hosting markeren verzoeken als geautomatiseerd op basis van een combinatie van signalen, waaronder de exacte structuur en volgorde van Accept-headers, en antwoorden met 406 als generiek blokkeerantwoord in plaats van omdat contentonderhandeling daadwerkelijk mislukte.

Moet mijn API 406 teruggeven of gewoon standaard JSON gebruiken?

Standaard een verstandig formaat gebruiken is vriendelijker voor echte clients en is wat de meeste productie-API's doen. 406 teruggeven is verdedigbaar wanneer het stilzwijgend serveren van het verkeerde formaat actief misleidend zou zijn voor de aanroeper.

Wat is het verschil tussen 406 en 415?

406 gaat over wat de client in het antwoord kan accepteren. 415 Unsupported Media Type gaat over wat de server kan accepteren in de requestbody die de client stuurde. Ze dekken tegenovergestelde richtingen van hetzelfde onderhandelingsidee.