Warum ein Proxy-Anbieter über Statuscodes schreibt: Wir sind Geonode und der API-Verkehr wird über uns geleitet, daher werden wir gefragt, ob ein bestimmter Fehler „vom Proxy“ stammt. Bei 415 lautet die Antwort im Grunde immer „nein“. Ein 415-Fehler stammt vom Ursprungsserver und sagt etwas über die von Ihnen erstellte Anfrage aus. Ein Vermittler kann unter bestimmten Umständen einen solchen Fehler auslösen – beispielsweise ein Filter-Proxy, der Request-Inhalte überprüft, oder ein Gateway mit eigenen Inhaltsregeln –, doch das ist selten und wird in den Antwort-Headern deutlich angegeben. Wenn Sie über einen Proxy einen 415-Fehler erhalten, entfernen Sie den Proxy, und Sie werden mit ziemlicher Sicherheit denselben 415-Fehler direkt erhalten. Korrigieren Sie die Anfrage. Der einzige Statuscode, der tatsächlich auf einen Proxy hindeutet, ist 407, und das sagt schon der Name.
Nun zum eigentlichen Fehler.
Was die Spezifikation besagt
RFC 9110, Abschnitt 15.5.16, definiert dies genau:
Der Statuscode 415 (Unsupported Media Type) zeigt an, dass der Ursprungsserver die Bearbeitung der Anfrage verweigert, da der Inhalt in einem Format vorliegt, das von dieser Methode auf der Zielressource nicht unterstützt wird.
Drei Teile dieses Satzes sind korrekt.
„Der Inhalt“ – der Anfragetext, nicht die URL, nicht der Abfrage-String, nicht die Antwort. Wenn Ihre Anfrage keinen Anfragetext enthält, ist ein 415-Fehler ungewöhnlich und deutet darauf hin, dass etwas anderes vor sich geht.
„Von dieser Methode nicht unterstützt“ – die Unterstützung gilt pro Methode. Eine Ressource kann „application/json“ bei POST akzeptieren und bei PATCH ablehnen, was eine wirklich häufige Quelle für Verwirrung ist, wenn sich derselbe Endpunkt unter verschiedenen Verben unterschiedlich verhält.
„Bei der Zielressource“ – und pro Ressource. Dass ein Endpunkt einer API ein Format akzeptiert, sagt nichts über einen anderen aus.
Die Spezifikation nennt dann die Ursachen:
Das Formatproblem kann auf den in der Anfrage angegebenen Content-Type oder Content-Encoding zurückzuführen sein oder sich aus der direkten Überprüfung der Daten ergeben.
Dieser letzte Satz ist wichtig und wird häufig übersehen. Ein Server darf einen 415-Fehler zurückgeben, nachdem er die Bytes geprüft hat, nicht nur nach dem Lesen der Header. Die Angabe von „Content-Type: application/json“ und das Senden von Daten, die kein JSON sind, kann durchaus einen 415-Fehler statt eines 400-Fehlers zur Folge haben.
Der RFC legt auch fest, welche Informationen der Server bereitstellen sollte. Wenn das Problem in der Inhaltskodierung lag, heißt es, dass der Antwort-Header „Accept-Encoding“ verwendet werden „sollte, um anzugeben, welche (falls überhaupt) Inhaltskodierungen akzeptiert worden wären“. Wenn es sich um den Medientyp handelte, kann „Accept“ verwendet werden, „um anzugeben, welche Medientypen akzeptiert worden wären“. In der Praxis dokumentiert MDN, dass Server für die methodenspezifischen Fälle üblicherweise „Accept-Post“ und „Accept-Patch“ verwenden, was noch nützlicher ist.
Lesen Sie die Antwort-Header. Server geben Ihnen häufig die Antwort, und Clients ignorieren diese häufig.
Die sechs Ursachen
In grober Reihenfolge nach ihrer Häufigkeit.
1. Das „Content-Type“ fehlt komplett. Sie senden einen Body, ohne dessen Format anzugeben. Viele Frameworks können dies nicht erraten. Das Beispiel von MDN zeigt genau diesen Fall: ein POST-Request mit einem JSON-Body, einem „Content-Length“ und ohne „Content-Type“, auf den mit „415“ und „Accept-Post: application/json; charset=UTF-8“ geantwortet wird.
2. Der falsche „Content-Type“. Der Klassiker ist das Senden von JSON bei der Angabe von „application/x-www-form-urlencoded“, meist weil ein HTTP-Client standardmäßig die Form-Kodierung verwendet und Sie eine JSON-Zeichenkette unverändert übergeben haben. Der Body ist in Ordnung; die Bezeichnung ist falsch.
3. Ein fast richtiger, aber falscher Medientyp. „text/json“ statt „application/json“. „application/xml“, wo der Server „text/xml“ erwartet. Hersteller-spezifische Typen wie application/vnd.api+json, wo Sie „plain“ application/json gesendet haben. Strenge Server prüfen auf exakte Übereinstimmung und sind dabei nicht nachsichtig.
4. Probleme mit dem Zeichensatz. MDN liefert das anschaulichste Beispiel: das Senden von UTF8, wo der Server UTF-8 verlangt. Der Bindestrich ist im registrierten Namen nicht optional, und ein Server, der eine strenge Parameterüberprüfung durchführt, ist berechtigt, dies abzulehnen.
5. „Content-Encoding“, die der Server nicht unterstützt. Sie komprimieren den Request-Body mit gzip und setzen „Content-Encoding: gzip“ bei einem Server, der nur Identity-Encoding verarbeitet. Der RFC sieht diesen Fall ausdrücklich vor, und ein ordnungsgemäß funktionierender Server sollte „Accept-Encoding“ zurückgeben, um Ihnen mitzuteilen, was erforderlich wäre.
6. Der Body stimmt nicht mit dem deklarierten Typ überein. Richtiger Header, falsche Bytes – oft ein Serialisierungsfehler, eine Vorlage, die eine leere Zeichenkette ausgegeben hat, oder ein Body, der irgendwo im Stack doppelt kodiert wurde. Hier kommt die Klausel „direkte Überprüfung der Daten“ zum Tragen.
415 vs. 406 vs. 400 vs. 422
Dies ist die Übersicht zur Vermeidung von Verwechslungen, und die Spezifikation unterscheidet klar zwischen den einzelnen Codes.
| Code | Bedeutung | Richtung | Behebung durch Änderung |
|---|
| 415 | Das von Ihnen gesendete Format wird nicht unterstützt | Anfragetext | Content-Type oder Content-Encoding |
| 406 | Es ist keine von Ihnen akzeptierte Darstellung verfügbar | Antwort | Accept-Header |
| 400 | Die Anfrage ist fehlerhaft | Gesamte Anfrage | Syntax oder Aufbau |
| 422 | Format verstanden, Inhalt nicht verarbeitbar | Anfragetext | Die Daten selbst |
| 413 | Anfragetext zu groß | Anfragetext | Größe der Nutzdaten |
415 im Vergleich zu 406 ist ein Problem der Ausrichtung und am einfachsten zu verstehen, sobald es erklärt wurde. Bei 415 geht es darum, was Sie gesendet haben. Bei 406 geht es darum, was Sie erhalten wollten – RFC 9110 definiert es als den Fall, dass die Ressource „keine aktuelle Darstellung besitzt, die für den Benutzeragenten gemäß den empfangenen Header-Feldern zur proaktiven Verhandlung akzeptabel wäre“. Wenn Sie einen 406-Fehler erhalten, überprüfen Sie Ihren „Accept“-Header, nicht Ihren Body.
415 im Vergleich zu 400. RFC 9110 beschreibt den Status 400 als einen Fall, in dem der Server die Anfrage „aufgrund eines als Client-Fehler wahrgenommenen Problems (z. B. fehlerhafte Syntax der Anfrage, ungültige Struktur der Anfragemeldung oder irreführendes Routing der Anfrage)“ nicht verarbeitet. 400 ist strukturell bedingt – die Anfrage selbst ist fehlerhaft. 415 ist eine wohlgeformte Anfrage, deren Hauptteil jedoch in einem Format vorliegt, das der Server nicht akzeptiert. In der Praxis geben viele Server einen 400-Status zurück, obwohl ein 415 präziser wäre; da du darauf keinen Einfluss hast, solltest du einen 400-Status bei einer Anfrage mit Body als möglicherweise versteckten 415 behandeln.
415 versus 422 ist die Unterscheidung, die der RFC am deutlichsten hervorhebt. In Abschnitt 15.5.21 heißt es, dass 422 anzeigt, dass „der Server den Inhaltstyp des Anfragecontents versteht (daher ist ein 415-Statuscode (Unsupported Media Type) unangemessen) und die Syntax des Anfragecontents korrekt ist, er jedoch die enthaltenen Anweisungen nicht verarbeiten konnte.“
Die Reihenfolge lautet also: 415 bedeutet, dass die Hülle falsch ist, 422 bedeutet, dass die Hülle richtig ist und der Inhalt falsch ist. Wohlgeformtes JSON, bei dem ein erforderliches Feld fehlt, ist ein 422. Dasselbe JSON, das als Formulardaten gekennzeichnet ist, ist ein 415.
Diagnose in weniger als zwei Minuten
Eine festgelegte Vorgehensweise, mit der sich fast alle Fälle lösen lassen.
Schritt 1: Lesen Sie die Antwort-Header. Nicht die Statuszeile, sondern die Header.
curl -i -X POST https://api.example.com/items \
-H "Content-Type: application/json" \
-d '{"name":"test"}'
Suchen Sie in der Antwort nach „Accept“, „Accept-Post“, „Accept-Patch“ oder „Accept-Encoding“. Ist einer dieser Einträge vorhanden, ist dies eine direkte Angabe dessen, was der Server erwartet, und Sie sind fertig.
Schritt 2: Überprüfen Sie, was Sie tatsächlich gesendet haben. Nicht, was Sie senden wollten – sondern was tatsächlich übertragen wurde. Client-Bibliotheken fügen Header hinzu, überschreiben sie oder formatieren sie neu, und der Header, den Sie im Code festgelegt haben, ist nicht immer der Header, der tatsächlich übertragen wurde.
curl -v -X POST https://api.example.com/items \
-H "Content-Type: application/json" \
-d '{"name":"test"}' 2>&1 | grep '^>'
Die Zeilen „>“ stellen Ihre tatsächliche Anfrage dar. Ein überraschend großer Anteil der 415-Fehler lässt sich genau hier beheben, wenn sich herausstellt, dass der von Ihnen sorgfältig festgelegte „Content-Type“ durch einen Standardwert überschrieben wurde.
Schritt 3: Überprüfen Sie die Methode. Derselbe Endpunkt kann einen Typ bei POST akzeptieren und bei PATCH ablehnen. Probieren Sie denselben Body mit einem anderen Verb aus und prüfen Sie, ob sich das Verhalten ändert.
Schritt 4: Überprüfen Sie die genaue Typ-Zeichenkette. Vergleichen Sie sie Zeichen für Zeichen mit der Dokumentation. application/json im Vergleich zu text/json. UTF-8 im Vergleich zu UTF8. Hersteller-Suffixe. Das ist mühsam, aber oft liegt hier die Antwort.
Schritt 5: Lesen Sie die Dokumentation für diesen spezifischen Endpunkt. APIs sind intern nicht einheitlich. Ein Endpunkt für Datei-Uploads, der „multipart/form-data“ in einer ansonsten rein JSON-basierten API erwartet, ist völlig normal.
Behebung auf der Client-Seite
Die häufigsten Fälle bei gängigen Clients.
curl. -d impliziert application/x-www-form-urlencoded, sofern nicht anders angegeben. Dies ist die häufigste Ursache für einen 415-Fehler in der Befehlszeile:
curl -X POST https://api.example.com/items \
-H "Content-Type: application/json" \
-d '{"name":"test"}'
JavaScript fetch. Bei der Übergabe eines String-Inhalts wird Content-Type überhaupt nicht gesetzt:
await fetch(url, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ name: "test" }),
});
Die Ausnahme, die man kennen sollte: Bei „FormData“ dürfen Sie „Content-Type“ nicht selbst setzen. Der Browser muss diesen Wert generieren, da er die Multipart-Grenze enthält. Ein Überschreiben führt zu einer fehlerhaften Anfrage, die sich häufig als 415-Fehler äußert.
Python-Requests. Verwenden Sie „json=“ anstelle von „data=“, dann wird der Header automatisch gesetzt:
requests.post(url, json={"name": "test"}) # application/json
requests.post(url, data={"name": "test"}) # form-encoded
Axios. Setzt „application/json“ für einfache Objekte und etwas anderes für Strings, was häufig zu Überraschungen führt. Wenn Sie Ihre Nutzdaten bereits serialisiert haben, setzen Sie den Header explizit. Die Verhaltensunterschiede zwischen den Clients in diesem Zusammenhang sind genau das, was wir in axios vs. fetch behandelt haben.
Eine allgemeine Regel: Wenn ein Client einen JSON-spezifischen Parameter anbietet, nutzen Sie diesen, anstatt manuell zu serialisieren und darauf zu hoffen, dass der Standard-Header korrekt ist.
Korrekte Rückgabe auf der Serverseite
Wenn Sie auf der Empfängerseite stehen, gibt es einige Dinge, die die Arbeit mit Ihrer API erheblich erleichtern.
Senden Sie zusammen mit dem Statuscode 415 einen „Accept-Post“- oder „Accept-Patch“-Header. Der RFC sieht „Accept“ oder „Accept-Encoding“ vor; die methodenspezifischen Varianten sind präziser und werden von MDN genau für diesen Zweck dokumentiert. Dieser einzelne Header verwandelt eine Debugging-Sitzung in einen schnellen Überblick.
Fügen Sie einen lesbaren Body ein. Ein Statuscode mit leerem Body zwingt den Client zum Raten. Geben Sie an, was Sie erhalten haben und was Sie erwartet haben.
Unterscheiden Sie 415 korrekt von 422. Wenn Sie den Content-Type verstanden und den Body geparst haben, die Validierung jedoch fehlgeschlagen ist, ist das ein 422. Die Rückgabe von 415 bei Validierungsfehlern veranlasst Nutzer dazu, ihre Header zu überprüfen, obwohl diese in Ordnung waren – ein häufiger und kostspieliger Fehler im API-Design.
Seien Sie bei Parametern nachsichtig, wo dies gefahrlos möglich ist. Das Zurückweisen von application/json; charset=utf-8, während application/json akzeptiert wird, ist technisch zwar vertretbar, in der Praxis jedoch wenig hilfreich. Analysieren Sie den Medientyp ordnungsgemäß und ignorieren Sie Parameter, die für Sie irrelevant sind.
Verwenden Sie 415 nicht als generelle Ablehnung. Dieser Statuscode hat eine spezifische Bedeutung. Eine Überladung erschwert die Nutzung Ihrer API und führt zu fehlerhafter Wiederholungslogik auf der Client-Seite.
Wenn ein 415 nicht wirklich ein 415 ist
Fälle, in denen der Statuscode irreführend ist.
Ein Gateway oder eine WAF hat die Anfrage abgelehnt. Manche Sicherheitsschichten geben bei Daten, die sie als verdächtig einstufen, den Status 415 zurück – unabhängig vom tatsächlichen Inhaltstyp. Ein Hinweis darauf ist meist ein Antworttext, der nicht so aussieht, als stamme er von der Anwendung, oder Header, die auf einen Vermittler hinweisen.
Eine Standardfunktion des Frameworks wurde ausgelöst, bevor Ihr Code ausgeführt wurde. Viele Web-Frameworks lehnen unbekannte Inhaltstypen in der Middleware ab. Ihr Handler wurde nie ausgeführt, daher ist nichts in Ihrer Anwendungslogik für die Behebung relevant.
Ein Load Balancer oder ein CDN hat einen Header entfernt. Selten, aber möglich. Wenn die Anfrage bei direkter Übermittlung funktioniert, über die Infrastruktur jedoch fehlschlägt, vergleichen Sie die Header an beiden Enden, bevor Sie davon ausgehen, dass sich die Anwendung geändert hat.
Der Endpunkt existiert nicht. Einige Server antworten auf eine nicht übereinstimmende Route bei einem POST-Aufruf mit 415 statt mit 404, da die Content-Type-Aushandlung stattfindet, bevor das Routing aufgelöst wird. Überprüfen Sie die URL.
Das Überschreiben der HTTP-Methode ist fehlgeschlagen. Wenn Ihr Framework das Überschreiben der Methode über einen Header oder einen Abfrageparameter unterstützt, ist die tatsächlich verwendete Methode möglicherweise nicht die von Ihnen gesendete, und die Unterstützung von Content-Typen erfolgt methodenspezifisch.
In jedem dieser Fälle liegt die Lösung vor Ihrer Nutzlast. Das allgemeine Prinzip lautet: Wenn die Anfrage offensichtlich korrekt ist und der 415-Fehler weiterhin auftritt, hören Sie auf, den Body zu bearbeiten, und versuchen Sie herauszufinden, welche Komponente im Pfad die Antwort erzeugt.
Häufig gestellte Fragen
Was bedeutet der Fehlercode 415 „Unsupported Media Type“?
Der Server hat die Anfrage abgelehnt, da das Format des Anfrage-Hauptteils für diese Methode bei dieser Ressource nicht unterstützt wird. Laut RFC 9110 ist dies auf den Header „Content-Type“, den Header „Content-Encoding“ oder darauf zurückzuführen, dass der Server den Hauptteil direkt überprüft. Es geht um das Format der gesendeten Daten, nicht um deren Richtigkeit.
Wie behebe ich einen 415-Fehler?
Überprüfen Sie zunächst die Antwort-Header – Server geben häufig „Accept“, „Accept-Post“ oder „Accept-Encoding“ zurück, wobei genau angegeben wird, was sie erwarten. Überprüfen Sie anschließend, was Ihr Client tatsächlich übertragen hat, da Bibliotheken Header überschreiben können. Die häufigste Lösung besteht darin, „Content-Type: application/json“ zu einer Anfrage hinzuzufügen, die diesen Header noch nicht enthielt.
Was ist der Unterschied zwischen 415 und 400?
400 bedeutet, dass die Anfrage fehlerhaft aufgebaut ist – falsche Syntax oder Struktur. 415 bedeutet, dass die Anfrage korrekt aufgebaut ist, der Body jedoch ein nicht unterstütztes Format aufweist. In der Praxis geben Server oft einen 400-Fehler zurück, obwohl ein 415-Fehler präziser wäre. Daher lohnt es sich, einen 400-Fehler bei einer Anfrage mit Body als mögliches Problem mit dem Content-Type zu untersuchen.
Was ist der Unterschied zwischen 415 und 422?
RFC 9110 zieht diese Grenze ausdrücklich: 422 bedeutet, dass der Server den Inhaltstyp verstanden hat und die Syntax korrekt war, er die Anweisungen jedoch nicht verarbeiten konnte. Bei 415 ist also die Hülle falsch; bei 422 ist der Inhalt falsch. Gültiges JSON, bei dem ein erforderliches Feld fehlt, führt zu einem 422.
Warum erhalte ich beim Hochladen von Dateien den Fehler 415?
In der Regel liegt es daran, dass bei einer Multipart-Anfrage der Header „Content-Type“ manuell gesetzt wurde. Der Browser oder Client muss diesen Header selbst generieren, da er die Multipart-Grenze enthält. Wenn Sie ihn selbst setzen, wird die Grenze entfernt und es entsteht eine Anfrage, die der Server nicht analysieren kann.
Kann ein Proxy einen 415-Fehler verursachen?
Selten. Der Fehler 415 stammt vom Ursprungsserver und bezieht sich auf den Inhalt Ihrer Anfrage. Ein filternder Proxy oder ein Gateway, das Inhalte überprüft, kann einen solchen Fehler auslösen, aber der übliche proxyspezifische Statuscode ist 407, was bereits im Namen zum Ausdruck kommt. Testen Sie ohne den Proxy – wenn der Fehler 415 weiterhin auftritt, war der Proxy nicht beteiligt.
Bedeutet ein 415-Fehler, dass mein JSON ungültig ist?
Nicht unbedingt. Wenn der Server den Inhaltstyp abgelehnt hat, wurde Ihr JSON gar nicht erst geprüft. Wenn der Server den richtigen Typ deklariert hat und dann feststellte, dass der Body tatsächlich nicht diesem Format entsprach, dann ja – der RFC erlaubt eine Ablehnung nach „direkter Überprüfung der Daten“. Überprüfen Sie zunächst die Frage zum Header; dies ist weitaus häufiger der Fall.
Sollte ich es nach einem 415 erneut versuchen?
Nein. Es handelt sich um einen Client-Fehler, und dieselbe Anfrage wird zum gleichen Ergebnis führen. Ein erneuter Versuch verschwendet Anfragen und kann, falls Sie einer Ratenbegrenzung unterliegen, die Situation noch verschlimmern. Korrigieren Sie den Inhaltstyp und senden Sie die Anfrage einmalig.
Zusammenfassung
Der Statuscode 415 hat eine eng gefasste und präzise Bedeutung: Die Hülle um Ihre Daten entspricht nicht der, die dieser Endpunkt für diese Methode akzeptiert. Es geht nicht darum, dass Ihre Daten ungültig sind – dafür ist der Statuscode 422 vorgesehen – und es geht auch nicht darum, was Sie angefordert haben – dafür ist der Statuscode 406 vorgesehen.
Da die Bedeutung eng gefasst ist, ist die Diagnose kurz. Lesen Sie die Antwort-Header, denn ein ordnungsgemäß funktionierender Server nennt die zulässigen Typen in „Accept“, „Accept-Post“ oder „Accept-Encoding“. Überprüfen Sie dann, was Ihr Client tatsächlich gesendet hat, und nicht, was Sie ihm befohlen haben, da Standardwerte und Middleware den von Ihnen gesetzten Header regelmäßig überschreiben. Mit diesen beiden Schritten lassen sich die meisten Fälle lösen, ohne den Body überhaupt anzutasten.
Und wenn die Anfrage einwandfrei aussieht und der 415-Fehler weiterhin auftritt, stammt die Antwort wahrscheinlich nicht von der Anwendung, von der du es vermutest. Gateways, Framework-Middleware und nicht übereinstimmende Routen erzeugen allesamt 415-Fehler, die nichts mit Ihrer Nutzlast zu tun haben – an diesem Punkt lautet die relevante Frage nicht, was geändert werden muss, sondern welche Komponente im Pfad die Antwort liefert.
