Aufbau eines Medientyps
Ein MIME-Typ – korrekt Media Type genannt – ist das Etikett, das ein Server an eine Antwort hängt, damit der Client weiß, wie er die folgenden Bytes behandeln soll. Er hat zwei durch einen Schrägstrich getrennte Teile: einen Top-Level-Typ wie text, image, audio, video, font, model oder application und einen Subtyp, der das spezifische Format benennt. image/png und application/json sind beides vollständige Medientypen; image allein ist keiner.
Subtypen haben eigene Konventionen. Ein führendes x- markierte früher einen experimentellen Typ, wie in application/x-tar, und obwohl die Praxis veraltet ist, sind die überlebenden Namen zu weit verbreitet, um sie zu ändern. Ein nachgestelltes +suffix besagt, dass das Format auf einer allgemeineren Syntax aufbaut: image/svg+xml ist XML, application/ld+json ist JSON, und ein Parser kann auf die Basissyntax zurückfallen, wenn er das spezifische Format nicht erkennt.
Einige Typen akzeptieren Parameter nach einem Semikolon. Das wichtigste ist charset, wie in text/html; charset=utf-8. Es wegzulassen bei einer Textantwort lädt den Browser ein, die Kodierung zu erraten, was eine klassische Quelle für Mojibake ist, also ist das explizite Deklarieren von UTF-8 die wenigen Zeichen immer wert.
Warum der Header wichtiger ist als die Erweiterung
Browser entscheiden anhand des Content-Type-Headers, was sie mit einer Antwort machen, nicht anhand des Dateinamens in der URL. Eine PNG als text/plain auszuliefern zeigt eine Wand aus Binärmüll; JSON als text/html auszuliefern kann dazu führen, dass ein Fetch-Client es ablehnt. Den richtigen Header zu setzen sorgt dafür, dass ein Download in der korrekten Anwendung öffnet und ein eingebettetes Asset gerendert statt heruntergeladen wird.
Die Diskrepanz hat auch Sicherheitsfolgen. Ältere Browser praktizierten MIME-Sniffing, untersuchten die ersten Bytes einer Antwort und überschrieben einen Header, den sie für falsch hielten. Ein Angreifer, der eine Datei hochladen konnte, die wie HTML aussah, konnte sie im Ursprung der Site ausführen, selbst wenn der Server sie als Bild markiert hatte. Der Header X-Content-Type-Options: nosniff deaktiviert dieses Verhalten und ist heute Standardpraxis auf jedem Endpunkt, der von Nutzern hochgeladene Inhalte ausliefert.
Für Downloads, kombinieren Sie den Medientyp mit Content-Disposition: attachment; filename="report.pdf". Der Medientyp beschreibt, was die Bytes sind, die Disposition beschreibt, was der Browser damit tun soll, und beide beantworten verschiedene Fragen.
Wo die Zuordnung tatsächlich lebt
Es gibt keine einzelne autoritative Tabelle von Erweiterung zu Typ, was Menschen überrascht. IANA registriert die Medientypen selbst, aber die Zuordnung von einer Dateierweiterung zu einem Typ ist eine lokale Konvention, die von jedem Server gepflegt wird. Apache liest mime.types, nginx hat seine eigene mime.types-Datei, und Anwendungs-Frameworks liefern ihre eigenen Nachschlagetabellen mit. Das ist der Grund, warum dieselbe .wasm-Datei von einem Server korrekt und von einem anderen, der nicht aktualisiert wurde, als application/octet-stream ausgeliefert werden kann.
application/octet-stream ist der generische Fallback und bedeutet "beliebige Binärdaten". Es ist die ehrliche Antwort, wenn das Format wirklich unbekannt ist, aber es verhindert das eingebettete Rendern, also lohnt es sich, eine explizite Zuordnung für jedes Format hinzuzufügen, das Ihre Site regelmäßig ausliefert. Neuere Formate wie AVIF, JXL und WebAssembly sind die, die am häufigsten in einer älteren Serverkonfiguration fehlen.