100% Clientseitige Berechnung • Keine Server-Logs • Sofortige Ausführung
Curious TechieEntwickler-Toolbox
HTTP & Web ArchitectureIANA Media Types Registry / RFC 2046✓ Schnellübersichtstabelle (6 Einträge) • DE

HTTP Content-Type & MIME-Types Referenz

Medientypen, Zeichenkodierung (charset) und API-Formate nach RFC 9110

CT
Curious-Techie Engineering TeamVerifizierter Autor

Web Protocols & Security Architecture Research

Veröffentlicht:
•
Aktualisiert:
•6 min read
Maßgebliche Spezifikation:RFC 9110(IETF)
Geprüft von Curious-Techie Architecture Peer Review Group

Übersicht & Anwendungsbereich

Die RFC 9110-Spezifikation verlangt eindeutige Medientyp-Deklarationen zur Verhinderung von MIME-Sniffing und zur fehlerfreien API-Datenverarbeitung.

Spezifikationstabelle & Matrix

Echtzeit-Filter nach Stichwort, Statuscode oder Direktive

Schlüssel / CodeDefinition & DetailsSemantische GEO-HierarchieSpezifikation & Hinweise
application/json
application/json

Standard serialization format for structured key-value data in modern REST and GraphQL APIs.

{"userId": 102, "name": "Antigravity"}
●application/json
↳MIME type
↳application
↳JSON data interchange
RFC 8259

UTF-8 is the mandatory default encoding for JSON; specifying charset=utf-8 is technically redundant but harmless.

application/x-www-form-urlencoded
application/x-www-form-urlencoded

Default encoding for standard HTML form submissions; keys and values are percent-encoded pairs separated by &.

username=alex&password=secret%20password
●application/x-www-form-urlencoded
↳MIME type
↳application
↳percent-encoded form stream
HTML Living Standard

Inefficient for binary files; reserved for simple text inputs.

multipart/form-data
multipart/form-data

Format used for uploading binary files and mixed form payloads via HTTP POST.

multipart/form-data; boundary=----WebKitFormBoundary...
●multipart/form-data
↳MIME type
↳multipart
↳boundary-delimited file stream
RFC 7578

Never set the boundary parameter manually in frontend JavaScript; let fetch(FormData) generate it automatically.

text/html
text/html

HyperText Markup Language format interpreted by web browser rendering engines.

text/html; charset=utf-8
●text/html
↳MIME type
↳text
↳DOM document structure
W3C HTML5

Always specify charset=utf-8 to prevent character encoding attacks and rendering glitches.

text/event-stream
text/event-stream

MIME type for Server-Sent Events (SSE), enabling persistent real-time unidirectional streaming.

data: {"progress": 95}
●text/event-stream
↳MIME type
↳streaming
↳Server-Sent Events stream
W3C Server-Sent Events

Requires Cache-Control: no-cache and Connection: keep-alive.

application/octet-stream
application/octet-stream

Arbitrary binary byte stream used as a generic fallback when specific MIME type is unknown.

Content-Disposition: attachment; filename="data.bin"
●application/octet-stream
↳MIME type
↳application
↳arbitrary binary data
RFC 2046 §4.5.1

Triggers browser file download dialog rather than inline rendering.

Technisches Beispiel & Code

Dispatching JSON vs Multipart Form Data in Fetch API

javascriptCode kopieren
// 1. JSON Payload: Explicit Content-Type required
await fetch('/api/submit', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ title: 'Report', priority: 1 }),
});

// 2. File Upload: DO NOT set Content-Type header!
// The browser automatically sets multipart/form-data WITH the unique boundary string
const formData = new FormData();
formData.append('document', fileInput.files[0]);
await fetch('/api/upload', {
  method: 'POST',
  body: formData, // Browser calculates Content-Type + boundary automatically
});

Manually setting Content-Type on a FormData object breaks the boundary token, resulting in HTTP 400 or 500 errors.

Häufig gestellte Fragen (FAQ)

Standard-Spezifikation Q&A

Why should I never manually set Content-Type for FormData?↓
FormData requires a dynamic boundary delimiter (e.g. boundary=----WebKitFormBoundaryXYZ). If you manually specify "multipart/form-data", the boundary is omitted and the server fails to parse the chunks.
Authoritative Sourcing & Verification

References & Primary Sources

Every source below directly substantiates technical statements and protocol behaviors explained in HTTP Content-Type & MIME-Types Referenz. Curious-Techie prioritizes official Internet standards (IETF RFCs, W3C Recommendations, WHATWG specifications) and established security bodies (OWASP, NIST). Zero sponsored or secondary links.

  1. [1]IETFPrimary SpecificationRFC 9110 • Core Architecture
    Verified Primary Source
    Technical Claim Supported:

    Foundational specification for the stateless client-server request-response architecture, standard status codes (1xx–5xx), and method safety and idempotency.

  2. [2]IETFPrimary SpecificationRFC 9112 • Section 3 & 6
    Verified Primary Source
    Technical Claim Supported:

    Defines ASCII wire protocol framing, chunked transfer encoding, and persistent connection Keep-Alive mechanics.

  3. [3]IETFPrimary SpecificationRFC 9113 • Section 4 & 5
    Verified Primary Source
    Technical Claim Supported:

    Standardizes binary framing, HPACK header compression, and bi-directional stream multiplexing over a single shared TCP connection.

  4. [4]IETFPrimary SpecificationRFC 9114 • Section 3 & 4
    Verified Primary Source
    Technical Claim Supported:

    Eliminates TCP head-of-line blocking by mapping HTTP streams directly over QUIC UDP transport connections with integrated TLS 1.3 encryption.