406 Not Acceptable: co to znamená a jak to opravit

Co znamená 406 Not Acceptable

HTTP podporuje vyjednávání obsahu přes rodinu hlaviček Accept: Accept pro typ média odpovědi, Accept-Language pro jazyk, a Accept-Encoding pro kompresi. Klient může poslat kteroukoli z nich se zprávou "dej mi jen odpověď, kterou dokážu použít." Podle RFC 9110, pokud server nedokáže vyprodukovat reprezentaci, kterou klient uvedl, že přijme, a rozhodne se to signalizovat místo toho, aby něco přesto poslal, odpoví 406. V praxi většina serverů úzkou hlavičku Accept potichu ignoruje a místo toho pošle svou výchozí odpověď, což je důvod, proč je skutečná 406 méně častá než samotná hlavička.

Jak se chyba projevuje

Prohlížeč jen zřídka spustí 406 při běžném načítání stránky, protože prohlížeče posílají shovívavé hlavičky Accept, které odpovídají skoro čemukoli, co server nabízí. Mnohem častěji se objevuje u klientů API, skriptů, a nástrojů příkazové řádky, které nastavují přísnou hlavičku Accept:

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

V tomhle příkladu klient požádal jen o XML a API dokáže vyprodukovat jen JSON, takže server odmítne místo toho, aby poslal formát, o kterém klient výslovně řekl, že ho nechce.

Co způsobuje 406 Not Acceptable

• Vyjednávání obsahu skutečně selhává. Hlavička Accept, Accept-Language, nebo Accept-Encoding pojmenovávající jen formáty, které server nedokáže vyprodukovat, nejčastěji klient žádající XML od API pouze pro JSON, nebo konkrétní jazykovou variantu, kterou server nemá.
• Web application firewall na sdíleném hostingu. Tohle je velmi běžná skutečná příčina, která nemá s vyjednáváním obsahu vůbec nic společného: ModSecurity a podobná pravidla WAF na prostředích sdíleného hostingu blokují požadavky, jejichž hlavička Accept vypadá neobvykle, chybí, nebo je automatizovaná, a odpoví 406 jako blokovací odpověď bez ohledu na to, co se vlastně vyjednávalo.
• API, které obsluhuje jen JSON, oslovené klientem posílajícím Accept: text/html. Některá API jsou v tomhle přísná a odmítnou místo toho, aby degradovala, což se projeví jako 406 pro každého klienta, včetně karty prohlížeče otevřené přímo na endpointu.
• Špatně nastavená reverzní proxy nebo pravidlo CDN, které kontroluje a odmítá na základě hlavičky Accept z důvodů cachování nebo filtrování botů, nesouvisejících s tím, co dokáže vyprodukovat origin server.
• Přehnaně přísné zpracování Accept-Encoding. Server nastavený tak, aby odmítl každý požadavek, který neuvede metodu komprese, jakou preferuje, místo aby spadl zpátky na nekomprimovanou odpověď.

Jak zjistit, čí je to chyba

Pokud na 406 naráží jen konkrétní skript nebo integrace, zkontrolujte, co říkají jeho hlavičky Accept, protože zúžená nebo špatně nastavená hlavička na straně klienta je často přímou příčinou. Pokud stejný požadavek funguje s obyčejnou, shovívavou hlavičkou Accept, ale selže s konkrétní, server skutečně nedokáže daný formát obsloužit. Pokud je postižený i běžný provoz prohlížečů, nebo chyba začala hned po změně hostingu nebo WAF bez jakékoli změny kódu na vaší straně, pravděpodobnější viníkem jsou bezpečnostní pravidla sdíleného hostingu, a spuštění HTTP kontroly z několika míst s přesně těmi hlavičkami, které posílá vaše integrace, je nejrychlejší způsob, jak potvrdit, jestli je blokace konzistentní, nebo specifická pro jednu síť.

Jak opravit 406 Not Acceptable

Pokud jste návštěvník

1. Odstraňte nebo uvolněte hlavičku Accept v jakémkoli skriptu nebo nástroji, který požadavek posílá, pokud ho ovládáte, a nechte ho přijmout výchozí formát, který server nabízí.
2. Zkontrolujte dokumentaci API, jaké typy obsahu a jazyky podporuje, než usoudíte, že je server rozbitý.
3. Zkuste požadavek přímo z prohlížeče, protože prohlížeče posílají široké hlavičky Accept a na tuhle chybu narážejí jen zřídka, což pomůže potvrdit, že je blokace specifická pro hlavičky vašeho klienta.

Pokud web provozujete

1. Nejdřív zkontrolujte svá pravidla ModSecurity nebo WAF, pokud je 406 neočekávaná a rozšířená, protože prostředí sdíleného hostingu často blokují na základě vzorů hlaviček Accept, ne kvůli skutečnému selhání vyjednávání. Než se dotknete kódu aplikace, podívejte se do vlastních logů WAF na ID pravidla, které zafungovalo.
2. Ověřte, jaké formáty vaše API skutečně obsluhuje, a buď podporujte víc z toho, o co skuteční klienti žádají, nebo tenhle požadavek jasně zdokumentujte, aby byla 406 informativní, ne překvapivá.
3. Spadněte zpátky na výchozí reprezentaci místo přímého odmítnutí, tam, kde je to pro vaše API přijatelné, protože většina skutečných klientů zvládá "tady je JSON, i když jsi žádal široce" lépe než přímé odmítnutí.
4. Zkontrolujte pravidla reverzní proxy a CDN kvůli čemukoli, co kontroluje hlavičku Accept kvůli cachování nebo správě botů, protože pravidlo určené pro jeden účel může jako vedlejší efekt vyprodukovat 406 pro nesouvisející provoz.

Jak předejít tomu, aby 406 shodila integraci

406 zavedená bezpečnostní aktualizací poskytovatele hostingu nebo novým pravidlem WAF nebude vypadat jako výpadek zevnitř vaší vlastní sítě, protože vaše vlastní požadavky mohou používat jiné hlavičky než postižená integrace. Naplánovaná HTTP kontrola, která posílá stejnou hlavičku Accept jako vaši skuteční klienti, s ověřením očekávaného stavového kódu, zachytí selhání vyjednávání ve chvíli, kdy začne. Kontrola z více míst taky pomůže oddělit pravidlo WAF platné pro celý hosting od takového, které se uplatňuje jen na určitých edge uzlech.

Související chyby

Viz 403 Forbidden pro úzce související případ, kdy pravidlo WAF nebo botů požadavek rovnou blokuje místo přes vyjednávání obsahu, přehled 4xx pro širší rodinu, a 413 Payload Too Large jinde v této dávce.

Často kladené otázky

Je 406 totéž jako chyba CORS?

Ne. Selhání CORS nastává, protože prohlížeč odmítá vystavit cross-origin odpověď volajícímu skriptu; 406 je situace, kdy server sám odmítá vyprodukovat tělo odpovědi vůbec, protože nedokáže splnit požadovaný formát, jazyk, nebo kódování.

Proč vidím 406 jen z curl nebo Postman, nikdy z prohlížeče?

Prohlížeče ve výchozím stavu posílají široké, shovívavé hlavičky Accept. Nástroje jako curl nepošlou nic, nebo úzkou hlavičku, pokud ji explicitně nenastavíte, což mnohem pravděpodobněji spustí skutečné selhání vyjednávání nebo aktivuje pravidlo WAF nastavené tak, aby označovalo neobvyklé hlavičky.

Může 406 pocházet z ModSecurity, i když je moje hlavička Accept naprosto normální?

Ano. Mnoho sad pravidel ModSecurity na sdíleném hostingu označuje požadavky za automatizované na základě kombinace signálů, včetně přesné struktury a pořadí hlaviček Accept, a odpoví 406 jako obecnou blokovací odpověď, ne proto, že vyjednávání obsahu skutečně selhalo.

Má moje API vracet 406, nebo se prostě má vrátit zpátky na JSON?

Návrat na rozumný výchozí formát je vůči skutečným klientům přátelštější a dělá to většina produkčních API. Vrácení 406 je obhajitelné, když by tiché posloužení špatným formátem bylo pro volajícího aktivně zavádějící.

Jaký je rozdíl mezi 406 a 415?

406 se týká toho, co klient dokáže přijmout v odpovědi. 415 Unsupported Media Type se týká toho, co server dokáže přijmout v těle požadavku, které poslal klient. Pokrývají opačné směry stejné myšlenky vyjednávání.