HTTP 406 und http 406 verstehen: Ein umfassender Leitfaden zur Not Acceptable Statuscode

Der Statuscode HTTP 406, oft auch als Not Acceptable bezeichnet, gehört zu den weniger verstandenen Mechanismen des Webprotokolls. Viele Entwickler stoßen irgendwann darauf, besonders wenn sie mit Content Negotiation, API-Schnittstellen oder mehrsprachigen Webangeboten arbeiten. In diesem Artikel werfen wir einen detaillierten Blick auf den http 406, erklären, wann er auftritt, wie Content Negotiation funktioniert und wie man gängige Ursachen systematisch eingrenzt und löst. Dabei verwenden wir sowohl die Bezeichnung HTTP 406 als auch die Variante http 406, um Missverständnisse zu vermeiden und die Suchmaschinenoptimierung zu unterstützen.

Was bedeutet HTTP 406 wirklich?

Der Statuscode 406 aus dem HTTP-Protokoll signalisiert, dass der vom Client gewünschte Repräsentationsinhalt zwar vorhanden wäre, der Server ihn jedoch nicht auf eine Art liefern kann, die dem angegebenen Request-Header entspricht. Im Klartext: Der Client bittet um eine bestimmte Form der Antwort (etwa JSON, XML, eine bestimmte Sprache oder einen bestimmten Zeichensatz), und der Server kann diese Form nicht liefern. Stattdessen orakelt der Server, dass er eine andere, akzeptable Darstellung liefern könnte, oder er kündigt den Grund an, warum keine passende Darstellung existiert.

Die korrekte Bezeichnung dieser Fehlermeldung lautet offiziell HTTP 406 Not Acceptable. In der Praxis begegnet man häufig der Verkürzung http 406 oder der gemischten Schreibweise HTTP/1.1 406 Not Acceptable. Unabhängig von der Schreibweise signalisiert der Code dem Client, dass eine Entscheidung über das acceptable Content-Negotiation-Profil getroffen werden muss, bevor die Anfrage abgeschlossen werden kann.

Content Negotiation ist der Prozess, bei dem Client und Server gemeinsam festlegen, welche Version einer Ressource zurückgegeben wird. Der Client sendet dazu verschiedene Header, die dem Server Hinweise geben, welche Repräsentationen akzeptiert werden. Die wichtigsten Header sind:

Accept Header: Welches Mediatypenprofil wird akzeptiert?

Der Accept-Header listet Mediatypen wie text/html, application/json, application/xml etc. auf. Der Server prüft, welche Repräsentationen er anbieten kann, und wählt die beste Übereinstimmung aus. Gelingt diese Übereinstimmung nicht, kann der http 406 als Reaktion erscheinen, sofern der Server keine kompatible Darstellung liefern kann.

Accept-Language: Welche Sprache wird bevorzugt?

Mit Accept-Language teilt der Client mit, in welcher Sprache die Ressource idealerweise vorliegen soll. Wenn der Server keine Version in der gewünschten Sprache anbieten kann, ergibt sich häufig ein 406, vor allem bei lokalisierten APIs oder mehrsprachigen Webseiten.

Accept-Encoding: Welche Codierung ist akzeptabel?

Der Accept-Encoding-Header gibt an, welche Komprimierungsmethoden der Client akzeptiert (beispielsweise gzip, br). Sollte der Server die Ressource nicht in einer akzeptierten Codierung liefern können, kann ebenfalls ein 406 auftreten, obwohl hier oft auch andere Mechanismen greifen würden.

Vary Header und Verhaltensregeln

Der Vary-Header informiert Caching-Systeme darüber, welche Header das Caching beeinflussen. Bei Content Negotiation ist er besonders wichtig, damit verschiedene Varianten einer Ressource korrekt gecached werden. Missverständnisse hier führen gelegentlich zu falschen 406- oder auch falschen 304-Antworten.

Ein 406 Not Acceptable tritt nicht willkürlich auf. Typische Ursache ist eine Diskrepanz zwischen dem, was der Client anfordert (über Accept, Accept-Language, Accept-Encoding) und dem, was der Server tatsächlich liefern kann. Weitere häufige Gründe sind:

• Der Server unterstützt keine der vom Client akzeptierten Mediatypen.
• Der Server kann die angegebene Sprache oder Lokalisierung nicht bereitstellen.
• Die API-Schnittstelle verlangt Authentifizierung oder spezielle Parameter, die im Request fehlen, wodurch der Server die gewünschte Repräsentation nicht liefern kann.
• Ein Content-Management-System oder API-Gateway konnte keine passende Variante finden, weil Meta-Daten oder Content-Typen inkonsistent konfiguriert sind.
• Zwischen Proxy oder Caching-Schicht liegen inkonsistente Regeln, die dazu führen, dass eine Variante als nicht akzeptabel angesehen wird.

Es ist wichtig zu beachten, dass ein 406 nicht automatisch ein Fehler der Ressourcenverfügbarkeit bedeutet. Vielmehr signalisiert er eine Stellgröße im Content Negotiation-Prozess – der Server bittet den Client, eine kompatible Alternative zu akzeptieren oder die Anfrage anders zu formulieren.

Der HTTP-Statuscode 406 gehört in den Bereich der clientseitigen Fehler (400er). Er grenzt sich ab von:

• 404 Not Found: Die Ressource existiert nicht unter der angegebenen Adresse. Hier fehlt die Ressource selbst, unabhängig von akzeptierten Formaten.
• 400 Bad Request: Die Anfrage ist syntaxfehlerhaft oder ungültig formuliert. Im Gegensatz dazu existiert die Ressource, aber das Server-Format passt nicht zum Client-Wunsch (406).
• 415 Unsupported Media Type: Der Client fordert einen Mediatyp, den der Server nicht unterstützt. In manchen Implementierungen kann 415 stattdessen erscheinen, aber 406 kann auftreten, wenn der Server alternativen Content anbietet, diesen aber nicht akzeptiert wird.

In der Praxis können 406 und 415 leicht verwechselt werden. Der feine Unterschied: 406 bezieht sich auf die Fähigkeit des Servers, eine akzeptierte Darstellung zu liefern, während 415 ausdrückt, dass der Server die vom Client gewünschte Mediatype überhaupt nicht unterstützt.

Um das Konzept greifbar zu machen, betrachten wir zwei typische Szenarien, in denen der http 406 auftreten kann.

Beispiel A: REST-API, JSON vs. XML

Stellen Sie sich eine REST-API vor, die sowohl JSON als auch XML unterstützt. Der Client sendet einen Request mit Accept: application/xml, aber die API-Implementierung kann derzeit nur JSON liefern. In diesem Fall könnte die API mit HTTP 406 antworten, sofern sie keine JSON-Variante bereitstellt, die dem Accept-Header entspricht. Alternativ kann der Server auch eine automatische Umwandlung anbieten und eine 200 bzw. 406 je nach Verfügbarkeit senden.

Beispiel B: Mehrsprachige Inhalte

Bei einer mehrsprachigen Website fordert der Client Accept-Language: de, en-US; der Server hat allerdings nur Inhalte in Englisch. Falls der Server keine passende deutsche Version liefern kann, kann ein 406 auftreten, insbesondere wenn der Server ausdrücklich nur bestimmte Sprachen unterstützt und eine Weiterleitung vermieden wird.

Beispiel C: Komprimierung und Codierungsformate

Angenommen, ein Browser akzeptiert nur gzip-komprimierte Antworten, der Server hingegen kann nur unkomprimierte Daten liefern. In einer strengen Konfiguration könnte hier ein 406 die Folge sein, während der Server stattdessen eine althergebrachte unkomprimierte Version anbieten könnte, sofern vorgesehen.

Eine systematische Vorgehensweise zur Behebung des http 406 umfasst mehrere Schritte, die sowohl Frontend- als auch Backend-Teams betreffen. Ziel ist eine konsistente Content Negotiation, die den Clientwünschen realistisch entspricht oder klare Anweisungen liefert, wie der Client erneut ansetzen soll.

1. Protokollanalyse: Prüfen Sie die Request-Header (Accept, Accept-Language, Accept-Encoding) und vergleichen Sie diese mit den tatsächlich möglichen Repräsentationen der Ressource. Dokumentieren Sie, welche Varianten vorhanden sind und welche fehlen.
2. Server-Konfiguration prüfen: Vergewissern Sie sich, dass das Content-Negotiation-Verhalten sinnvoll konfiguriert ist. Sind standardmäßig mehrere Formate möglich? Gibt es Fallback-Optionen?
3. API-Dokumentation anpassen: Stellen Sie sicher, dass Entwickler klare Hinweise erhalten, wie sie Requests formulieren müssen, um eine gültige Repräsentation zu erhalten. Falls nötig, implementieren Sie automatische Redirections oder informative Fehlermeldungen statt eines reinen 406.
4. Fallback-Strategien einbauen: Bieten Sie alternative Formate an, die oft genutzt werden (z. B. JSON als Standard, XML als Option) und kommunizieren Sie diese klar über den Header.
5. Tests und Monitoring: Automatisierte Tests sollten alle Kernvarianten abdecken (Accept-Header-Kombinationen, Sprache, Codierung). Monitoring hilft, Muster in 406-Fehlern zu erkennen und frühzeitig zu reagieren.

Um langfristig robuste Systeme zu bauen, sind einige Best Practices besonders hilfreich, wenn es um http 406 geht:

• Klare API-Verträge: Definieren Sie explizit, welche Varianten einer Ressource vorhanden sind und in welchen Fällen eine Not Acceptable-Antwort sinnvoll ist.
• Flexible Content Negotiation: Wenn möglich, bevorzugen Sie eine strukturierte Standardvariante (z. B. application/json) und bieten Sie klare Fallbacks an, statt ausschließlich 406 zu verwenden.
• Informative Fehlermeldungen: Ergänzen Sie 406-Antworten um eine klare Nachricht, die erläutert, welche Varianten akzeptiert werden und wie der Client die Anfrage anpassen kann.
• Semantisch korrekte Header: Nutzen Sie Consistency-Header wie Vary, damit Caching-Systeme das richtige Variant speichern und ausliefern können.
• Security- und Compliance-Prüfungen: Vermeiden Sie, dass Content Negotiation zu offen implementiertem Verhalten führt, das Angreifer ausnutzen könnten. Prüfen Sie insbesondere Allowed-Parameter und Shaping der Repräsentationen.

Wenn ein http 406 auftritt, helfen konkrete Debugging-Schritte dabei, den Fehler schnell zu lokalisieren und zu beheben:

1. Loganalyse: Verfolgen Sie Request-Header, Server-Entscheidungen und die verfügbaren Repräsentationen der Ressource. Suchen Sie Muster in fehlerhaften Requests.
2. Lokale Reproduzierbarkeit: Versuchen Sie, das Problem in einer lokalen Entwicklungsumgebung zu reproduzieren, indem Sie verschiedene Accept-Header testen.
3. Simulierte Client-Szenarien: Verwenden Sie Tools wie cURL oder Postman, um gezielt Accept-Header-Kombinationen zu testen, und prüfen Sie, welche Varianten tatsächlich geliefert werden.
4. Ressourcen-Repository prüfen: Stellen Sie sicher, dass alle erwarteten Content-Typen in der Anwendung tatsächlich vorhanden und registriert sind (Mediatypen, Serialisierer).
5. Cache-Verhalten kontrollieren: Falsche Caching-Einstellungen können dazu führen, dass veraltete Varianten ausgeliefert werden, obwohl neue vorhanden sind.

HTTP 406 kann indirekt Auswirkungen auf Sicherheit und Performance haben. Eine unausgegorene Content Negotiation kann Angreifern Hinweise darauf geben, welche Formate unterstützt oder nicht unterstützt werden. Ebenso können unnötige 406-Antworten den Client frustrieren und die Performance beeinträchtigen, insbesondere wenn wiederholte Requests erforderlich sind, um eine akzeptable Variante zu finden.

Deshalb empfehlen sich klare Konventionen, saubere Implementierungen und eine sinnvolle Ablaufsteuerung. In vielen Systemen ist es sinnvoll, den Standardfall so zu gestalten, dass eine allgemein akzeptierte Repräsentation (z. B. JSON) immer verfügbar ist, während optional andere Formate als Feature angeboten werden.

Es gibt einige verbreitete Meinungen, die oft zu Irrtümern führen. Hier eine kurze Klarstellung:

• 406 bedeutet Wegsperren der Ressource: Nein, es bedeutet nicht, dass die Ressource nicht existiert. Es bedeutet vielmehr, dass die gewünschte Repräsentation nicht ausgewählt werden konnte, obwohl die Ressource vorhanden ist.
• 406 ist dasselbe wie 415: Nicht ganz. 415 bedeutet, dass der Mediatyp generell nicht unterstützt wird. 406 bezieht sich auf die Verfügbarkeit der passenden Repräsentation innerhalb der akzeptierten Formate.
• 404 oder 500 sind nicht korrekt: In vielen Fällen ist 406 die passende Antwort, wenn Content Negotiation das Problem ist. 404 oder 500 würden andere Ursachen signalisieren.

Hier finden Sie kurze Antworten auf häufige Fragen rund um den http 406:

Was bedeutet HTTP 406 Not Acceptable?

Es bedeutet, dass der Client eine Abfrage gestellt hat, deren gewünschte Repräsentation der Server nicht liefern kann oder will, weil sie nicht akzeptiert wird oder nicht verfügbar ist.

Wie kann ich http 406 vermeiden?

Stellen Sie sicher, dass der Server eine verfügbare Standardvariante liefert und bieten Sie klare Fallback-Optionen an. Dokumentieren Sie, welche Formate unterstützt werden.

Wann sollte ich 406 verwenden statt 415?

Wenn das Problem nicht ist, dass das Format grundsätzlich unsupported ist, sondern dass die gewünschte Repräsentation nicht akzeptiert wird. Wenn das Format gar nicht unterstützt wird, ist 415 geeigneter.

Der http 406 Not Acceptable ist mehr als eine bloße Fehlermeldung. Er ist ein integraler Bestandteil der Kommunikation zwischen Client und Server, der klarmacht, wie Inhalte präsentiert werden sollen. Durch eine durchdachte Implementierung der Content Negotiation – inklusive sinnvoller Standardformate, klarer Fallbacks und hilfreicher Fehlermeldungen – erhöhen Sie die Zuverlässigkeit Ihrer Webanwendungen erheblich. Gleichzeitig verbessern Sie die Entwickler- und Benutzererfahrung, weil klar kommuniziert wird, warum eine bestimmte Darstellung nicht möglich ist und was als Nächstes getan werden kann.

• Definieren Sie eine klare Liste unterstützter Mediatypen (Accept) und Sprachen (Accept-Language).
• Implementieren Sie sinnvolle Standardvarianten (z. B. application/json) und klare Fallbacks.
• Nutzen Sie den Vary-Header konsistent, damit Caching korrekt funktioniert.
• Stellen Sie informative Fehlermeldungen bereit, die konkrete Anweisungen geben, wie der Client anpassen kann.
• Automatisieren Sie Tests, die verschiedene Accept-Header-Szenarien abdecken.
• Dokumentieren Sie das Content Negotiation-Verhalten in der API-Spezifikation.

In einer Zeit, in der Microservices, GraphQL-Schnittstellen, RESTful APIs und API-Gateways alltäglich sind, gewinnt die korrekte Umsetzung von Content Negotiation zusätzlich an Bedeutung. Auch wenn viele Systeme auf JSON setzen, bestehen oft Bedürfnisse nach alternativen Formaten oder Lokalisierungen. Der http 406 bietet hier einen klaren Mechanismus, um dem Client mitzuteilen, dass eine gewünschte Variante nicht verfügbar ist, ohne die ganze Anfrage abzubrechen. Eine bewusste Gestaltung der Antworten erhöht die Interoperabilität und verringert Missverständnisse in verteilten Architekturen.

Der Statuscode http 406 erinnert daran, dass das Protokoll nicht nur aus festen Regeln besteht, sondern dass eine Kommunikation zwischen Client und Server immer auf gegenseitigem Verständnis basiert. Wenn dieser Dialog misslingt, reagiert der Server mit 406 Not Acceptable. Indem Sie diesen Dialog durch klare Verträge, robuste Implementierungen und hilfreiche Fehlermeldungen unterstützen, schaffen Sie robuste, benutzerfreundliche Systeme, die auch in komplexen Umgebungen zuverlässig funktionieren.