406 Not Acceptable: Bedeutung und Lösung

Was 406 Not Acceptable bedeutet

HTTP unterstützt Content-Aushandlung über eine Familie von Accept-Headern: Accept für den Medientyp der Antwort, Accept-Language für die Sprache, und Accept-Encoding für die Kompression. Ein Client kann jeden davon senden, um zu sagen "geben Sie mir nur eine Antwort, die ich nutzen kann". Nach RFC 9110 antwortet der Server mit 406, wenn er keine Darstellung erzeugen kann, die der Client als akzeptabel angegeben hat, und er sich entscheidet, das zu signalisieren, statt trotzdem etwas zu senden. In der Praxis ignorieren die meisten Server einen engen Accept-Header still und senden stattdessen ihre Standardantwort, weshalb ein echter 406 seltener vorkommt als der Header selbst.

Wie sich der Fehler zeigt

Ein Browser löst bei normalem Seitenladen selten einen 406 aus, da Browser großzügige Accept-Header senden, die zu fast allem passen, was ein Server anbietet. Er zeigt sich weit häufiger bei API-Clients, Skripten, und Kommandozeilen-Tools, die einen strengen Accept-Header setzen:

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

In diesem Beispiel hat der Client nur XML angefragt, und die API kann nur JSON erzeugen, der Server lehnt also ab, statt ein Format zu senden, das der Client ausdrücklich nicht wollte.

Was einen 406 Not Acceptable verursacht

• Content-Aushandlung scheitert tatsächlich. Ein Accept-, Accept-Language-, oder Accept-Encoding-Header, der nur Formate nennt, die der Server nicht erzeugen kann, meist ein Client, der XML von einer Nur-JSON-API anfragt, oder eine bestimmte Sprachvariante, die der Server nicht hat.
• Eine Web-Application-Firewall auf Shared Hosting. Das ist eine sehr häufige reale Ursache, die mit Content-Aushandlung nichts zu tun hat: ModSecurity und ähnliche WAF-Regeln in Shared-Hosting-Umgebungen blockieren Anfragen, deren Accept-Header ungewöhnlich, fehlend, oder automatisiert wirkt, und antworten unabhängig davon, was gerade ausgehandelt wurde, mit 406 als Blockierungsantwort.
• Eine API, die nur JSON bedient, angesteuert von einem Client, der Accept: text/html sendet. Manche APIs sind dabei streng und lehnen ab, statt herabzustufen, was für jeden Client als 406 erscheint, einschließlich eines Browser-Tabs, das direkt auf dem Endpunkt geöffnet wurde.
• Eine falsch konfigurierte Reverse-Proxy- oder CDN-Regel, die aus Caching- oder Bot-Filterungsgründen anhand des Accept-Headers untersucht und ablehnt, unabhängig davon, was der Ursprungsserver erzeugen kann.
• Übermäßig strenge Accept-Encoding-Behandlung. Ein Server, der konfiguriert ist, jede Anfrage abzulehnen, die keine von ihm bevorzugte Kompressionsmethode auflistet, statt auf eine unkomprimierte Antwort zurückzufallen.

So finden Sie heraus, wer schuld ist

Trifft der 406 nur ein bestimmtes Skript oder eine bestimmte Integration, prüfen Sie, was deren Accept-Header aussagen, da ein eingeengter oder falsch konfigurierter Header auf Client-Seite oft die direkte Ursache ist. Funktioniert dieselbe Anfrage mit einem einfachen, großzügigen Accept-Header, scheitert aber mit einem bestimmten, kann der Server dieses Format tatsächlich nicht bedienen. Ist auch normaler Browser-Traffic betroffen, oder fing der Fehler genau nach einer Hosting- oder WAF-Änderung ohne eigene Code-Änderung an, sind Shared-Hosting-Sicherheitsregeln die wahrscheinlichere Ursache, und eine HTTP-Prüfung von mehreren Standorten mit genau den Headern, die Ihre Integration sendet, ist der schnellste Weg zu bestätigen, ob die Blockierung durchgängig ist oder auf ein Netzwerk beschränkt bleibt.

So beheben Sie einen 406 Not Acceptable

Wenn Sie Besucher sind

1. Entfernen oder lockern Sie den Accept-Header in dem Skript oder Tool, das die Anfrage stellt, falls Sie es kontrollieren, und lassen Sie es das vom Server angebotene Standardformat akzeptieren.
2. Prüfen Sie die Dokumentation der API darauf, welche Content-Typen und Sprachen sie unterstützt, bevor Sie annehmen, der Server sei kaputt.
3. Probieren Sie die Anfrage direkt im Browser, da Browser breite Accept-Header senden und diesen Fehler selten treffen, was hilft zu bestätigen, dass die Blockierung spezifisch für die Header Ihres Clients ist.

Wenn Sie die Website betreiben

1. Prüfen Sie zuerst Ihre ModSecurity- oder WAF-Regeln, falls der 406 unerwartet und weit verbreitet ist, da Shared-Hosting-Umgebungen häufig anhand von Accept-Header-Mustern blockieren statt wegen echtem Aushandlungsfehlschlag. Sehen Sie sich die eigenen Logs der WAF auf die getroffene Regel-ID an, bevor Sie Anwendungscode anfassen.
2. Bestätigen Sie, welche Formate Ihre API tatsächlich bedient, und unterstützen Sie entweder mehr von dem, was echte Clients anfragen, oder dokumentieren Sie die Anforderung klar, damit ein 406 informativ statt überraschend ist.
3. Fallen Sie auf eine Standarddarstellung zurück, statt rundweg abzulehnen, wo das für Ihre API akzeptabel ist, da die meisten echten Clients "hier ist JSON, obwohl Sie breit gefragt haben" besser verkraften als eine glatte Ablehnung.
4. Prüfen Sie Reverse-Proxy- und CDN-Regeln auf alles, was den Accept-Header aus Caching- oder Bot-Management-Gründen untersucht, da eine für einen Zweck gedachte Regel als Nebeneffekt einen 406 für unabhängigen Traffic erzeugen kann.

So verhindern Sie, dass ein 406 eine Integration lahmlegt

Ein 406, eingeführt durch ein Sicherheitsupdate eines Hosting-Anbieters oder eine neue WAF-Regel, sieht aus dem eigenen Netzwerk nicht wie ein Ausfall aus, da Ihre eigenen Anfragen andere Header nutzen können als eine betroffene Integration. Eine geplante HTTP-Prüfung, die denselben Accept-Header sendet, den Ihre echten Clients nutzen, mit einer Zusicherung auf den erwarteten Statuscode, erkennt einen Aushandlungsfehlschlag in dem Moment, in dem er beginnt. Die Prüfung von mehreren Standorten hilft außerdem, eine hostingweite WAF-Regel von einer zu trennen, die nur an bestimmten Edge-Knoten greift.

Verwandte Fehler

Siehe 403 Forbidden für den eng verwandten Fall, dass eine WAF- oder Bot-Regel eine Anfrage rundweg blockiert, statt über Content-Aushandlung, die 4xx-Übersicht für die breitere Familie, und 413 Payload Too Large anderswo in dieser Gruppe.

Häufig gestellte Fragen

Ist 406 dasselbe wie ein CORS-Fehler?

Nein. CORS-Fehlschläge passieren, weil der Browser sich weigert, eine Cross-Origin-Antwort dem aufrufenden Skript zu zeigen; 406 ist der Server selbst, der sich weigert, überhaupt einen Antwort-Body zu erzeugen, weil er das angefragte Format, die Sprache, oder die Kodierung nicht erfüllen kann.

Warum sehe ich 406 nur von curl oder Postman, nie vom Browser?

Browser senden standardmäßig breite, großzügige Accept-Header. Tools wie curl senden nichts oder einen engen Header, sofern Sie keinen ausdrücklich setzen, was viel eher einen echten Aushandlungsfehlschlag auslöst oder eine auf ungewöhnliche Header abgestimmte WAF-Regel trifft.

Kann ein 406 von ModSecurity kommen, auch wenn mein Accept-Header völlig normal ist?

Ja. Viele ModSecurity-Regelwerke auf Shared Hosting markieren Anfragen anhand einer Kombination aus Signalen als automatisiert, einschließlich der genauen Struktur und Reihenfolge der Accept-Header, und antworten mit 406 als generische Blockierungsantwort, statt weil Content-Aushandlung tatsächlich scheiterte.

Sollte meine API 406 zurückgeben oder einfach standardmäßig auf JSON zurückfallen?

Auf ein sinnvolles Standardformat zurückzufallen ist freundlicher zu echten Clients und ist, was die meisten Produktions-APIs tun. Einen 406 zurückzugeben ist vertretbar, wenn das stille Bedienen des falschen Formats den Aufrufer aktiv in die Irre führen würde.

Was ist der Unterschied zwischen 406 und 415?

406 geht darum, was der Client in der Antwort akzeptieren kann. 415 Unsupported Media Type geht darum, was der Server im vom Client gesendeten Anfrage-Body akzeptieren kann. Sie decken entgegengesetzte Richtungen derselben Aushandlungsidee ab.