Content-Type

Verwendung

Der Content-Type-Header teilt dem Client (bei Anfrage-Bodys dem Server) den Medientyp des enthaltenen Inhalts mit. Der Medientyp bestimmt, wie der Empfänger den Body parst und darstellt. Fehlt dieser Header, greifen Clients auf MIME-Sniffing zurück, was Sicherheitsrisiken und uneinheitliches Verhalten mit sich bringt.

Hinweis

Accept deklariert, was der Client empfangen möchte. Content-Type deklariert, was gesendet wird. Accept erscheint in Anfragen. Content-Type erscheint sowohl in Anfragen (sofern ein Body vorhanden ist) als auch in Antworten. GET-Anfragen haben typischerweise keinen Body und benötigen kein Content-Type. POST- und PUT-Anfragen mit Body erfordern den Header.

Ein Medientyp besteht aus einem Top-Level-Typ und einem Subtyp, getrennt durch einen Schrägstrich, optional gefolgt von Parametern. Der Accept-Anfrage-Header arbeitet bei der Content Negotiation mit Content-Type zusammen und erlaubt es dem Client, bevorzugte Medientypen auszudrücken, bevor der Server einen auswählt.

Server und Zwischenstationen wenden vor der Übertragung mitunter Content-Encoding (etwa gzip oder br) an. Der Content-Type-Header beschreibt stets den ursprünglichen Medientyp vor der Kodierung, nicht das kodierte Format.

Der MIME-Version-Header geht auf die E-Mail-Ursprünge der MIME-Typen zurück und erscheint in manchen HTTP-Nachrichten, obwohl HTTP diesen Header für die Verarbeitung von Medientypen nicht voraussetzt.

media-type

Der Wert des Medientyps folgt dem bei der IANA registrierten Format type/subtype. Zu den gängigen Typen zählen text/html, application/json, image/png und application/octet-stream. Ein vollständiges Register wird von der IANA gepflegt.

charset

Der charset-Parameter gibt die Zeichenkodierung textbasierter Medientypen an. UTF-8 ist die im Web vorherrschende Kodierung.

Content-Type: text/html; charset=UTF-8

boundary

Der boundary-Parameter ist für Medientypen der Form multipart/* erforderlich. Die boundary-Zeichenkette trennt die einzelnen Teile des mehrteiligen Bodys. Der boundary-Wert darf in keinem der Body-Teile vorkommen.

Content-Type: multipart/form-data; boundary=----FormBoundary

Beispiel

Ein Server liefert eine HTML-Seite mit UTF-8-Kodierung zurück. Der Browser nutzt den Medientyp, um den Inhalt als Webseite darzustellen, und das charset, um den Text korrekt zu dekodieren.

Content-Type: text/html; charset=UTF-8

Eine API gibt eine JSON-Antwort zurück. Der Medientyp application/json weist den Client an, den Body als JSON zu parsen.

Content-Type: application/json

Eine API-Fehlerantwort verwendet den Medientyp application/problem+json, um eine strukturierte Nutzlast mit Problemdetails zu signalisieren.

Content-Type: application/problem+json

Ein CDN wandelt eine HTML-Seite spontan in Markdown um, wenn der Client Accept: text/markdown sendet. Die Antwort führt text/markdown als Inhaltstyp und zeigt damit an, dass der Body Markdown statt HTML ist.

Content-Type: text/markdown; charset=utf-8

KI-Agenten und Content-Type

CDN-Anbieter wie Cloudflare geben Content-Type: text/markdown zusammen mit einem x-markdown-tokens-Header zurück, der die Token-Anzahl des konvertierten Dokuments schätzt. Agenten nutzen den Inhaltstyp, um den richtigen Parser auszuwählen, und die Token-Schätzung, um das Budget des Kontextfensters zu verwalten.

Ein Datei-Upload verwendet multipart/form-data mit einer boundary-Zeichenkette, die Formularfelder und Dateidaten innerhalb des Anfrage-Bodys trennt.

Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

Ein Server liefert einen binären Datei-Download aus. Der Typ application/octet-stream signalisiert rohe Binärdaten und wird häufig mit einem auf attachment gesetzten Content-Disposition-Header kombiniert.

Content-Type: application/octet-stream

Eine multipart/byteranges-Antwort liefert mehrere Byte-Bereiche aus einer einzigen Ressource. Jeder Teil besitzt einen eigenen Content-Type- und Content-Range-Header.

Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

Fehlersuche

Darstellungsfehler und Parsing-Fehler lassen sich häufig auf einen fehlenden oder falschen Content-Type-Header zurückführen.

Ein fehlender charset-Parameter führt zu verstümmeltem Text. Browser fallen auf eine Standardkodierung (oft ISO-8859-1) zurück, wenn kein charset deklariert ist. Nicht-ASCII-Zeichen erscheinen als Zeichensalat. Fügen Sie den charset-Parameter explizit hinzu: Content-Type: text/html; charset=UTF-8. In nginx:

charset utf-8;

In Apache:

AddDefaultCharset UTF-8

Der Browser wendet trotz korrektem Content-Type MIME-Sniffing an. Browser ignorieren den deklarierten Typ mitunter und schnüffeln den Body-Inhalt aus, um den Typ zu bestimmen. Dieses Verhalten schafft XSS-Angriffsvektoren, wenn von Nutzern hochgeladene Inhalte als HTML ausgeliefert werden. Setzen Sie den Header X-Content-Type-Options auf nosniff, um MIME-Sniffing zu unterbinden:

X-Content-Type-Options: nosniff

Eine API gibt text/html statt application/json zurück. Clients, die JSON von einer API parsen, erhalten HTML-Fehlerseiten oder Standardantworten des Frameworks. Das geschieht, wenn ein Fehler-Handler oder ein Reverse Proxy die Antwort abfängt und den Body ersetzt, ohne den Content-Type zu aktualisieren. Prüfen Sie die gesamte Antwortkette: Ursprungsserver, Anwendungsframework, Reverse Proxy und CDN. In Express.js setzt der Aufruf von res.json() den korrekten Header automatisch. In Django geben Sie JsonResponse statt HttpResponse zurück.

Eine nicht übereinstimmende Multipart-Boundary bricht Datei-Uploads. Die im Content-Type-Header deklarierte boundary-Zeichenkette muss mit dem im Anfrage-Body verwendeten Trennzeichen übereinstimmen. Bei einer Abweichung kann der Server den mehrteiligen Body nicht parsen. Untersuchen Sie die rohe Anfrage im Network-Tab der DevTools in den Abschnitten Headers und Payload. Vermeiden Sie es, die boundary manuell zu setzen, wenn Sie fetch() oder XMLHttpRequest mit FormData-Objekten verwenden. Der Browser erzeugt die korrekte boundary automatisch, sobald der Content-Type-Header in der Anfrage weggelassen wird.

Der Standard-Content-Type des Frameworks überschreibt eine explizite Einstellung. Manche Frameworks setzen Content-Type erst nach dem Ablauf des Anwendungscodes. Middleware in Express.js, Django oder Spring Boot kann den Header zurücksetzen. Prüfen Sie die Ausführungsreihenfolge der Middleware. Stellen Sie in Express.js sicher, dass res.type() oder res.set(‘Content-Type’, …) nach aller Middleware aufgerufen wird, die Header verändert.

Content-Type-Probleme mit den DevTools diagnostizieren. Öffnen Sie den Network-Tab der Browser-DevTools, wählen Sie die Anfrage aus und prüfen Sie im Abschnitt Response Headers den Content-Type-Wert. Vergleichen Sie den deklarierten Typ mit dem tatsächlichen Body-Inhalt, der im Tab Response oder Preview angezeigt wird. Verwenden Sie curl -I https://example.re/api/data, um die Header ohne Einflussnahme des Browsers von der Kommandozeile aus zu prüfen.