Multipart Upload in der Webentwicklung: Wesen, Struktur und Funktionsweise von multipart/form-data

Was ist Multipart Upload?

Multipart Upload ist eine Methode zur Datenübertragung über das HTTP-Protokoll, bei der der Anforderungskörper aus mehreren logisch getrennten Teilen besteht. Jeder Teil kann Daten eines anderen Typs enthalten: ein Textformularfeld, eine Binärdatei, ein JSON-Objekt oder ein Bild. Alle Teile werden in einer einzigen POST-Anfrage verpackt, wodurch die Notwendigkeit entfällt, N separate HTTP-Aufrufe zu senden. Multipart Upload ist ein wesentlicher Bestandteil von Webformularen und Datei-Upload-APIs.

Das Multipart-Format wurde in der RFC 2046-Spezifikation als Teil des MIME-Standards für E-Mail-Nachrichten definiert und später in RFC 1867 für HTTP angepasst. Heute verwendet die Webentwicklung fast ausschließlich multipart/form-data — einen der Multipart-Subtypen, der für Formulare mit Dateien entwickelt wurde. Andere Subtypen — multipart/mixed (für beliebige Anhänge) und multipart/byteranges (für partiellen Dateidownload) — werden viel seltener verwendet.

Der grundlegende Unterschied zwischen Multipart und einfachem application/x-www-form-urlencoded besteht darin, dass letzteres alle Daten in eine URI-kompatible Zeichenfolge kodiert und keine Binärdateien unterstützt. Multipart/form-data überträgt dagegen jede Datei in ihrer ursprünglichen binären Form ohne Kodierung, was effizienter ist und keine Genauigkeit verliert. Die Anforderungsgröße ist bei Multipart aufgrund des Overheads durch Teil-Header und Grenzen immer 5-15% größer als die Summe der Dateigrößen.

Wann wird Multipart Upload verwendet

Multipart Upload wird überall dort eingesetzt, wo Datei-Uploads erforderlich sind: Avatare und Profilfotos in sozialen Netzwerken, Anhänge in Messengern, Dokumente in CRM-Systemen, Produktbilder in Online-Shops. In Mobilanwendungen wird Multipart Upload verwendet, um Mediendateien an den Server zu senden — Fotos von der Gerätekamera, Sprachaufnahmen, Videoclips. Laut Cloudflare Research verwenden etwa 15% aller POST-Anfragen im Web multipart/form-data.

Unterschied zwischen Multipart und Chunked Transfer

Multipart Upload und Chunked Transfer sind unterschiedliche Mechanismen. Multipart teilt eine Anfrage in sinnvolle Teile (Felder und Dateien), während Chunked Transfer einen Datenstrom in Fragmente zur Übertragung aufteilt, ohne die Gesamtgröße zu kennen. Multipart kann innerhalb von Chunked Transfer übertragen werden: Der Server sendet eine Multipart-Antwort in Teilen, ohne ihre vollständige Größe zu kennen. Diese Mechanismen stehen nicht in Konflikt und lösen verschiedene Probleme auf unterschiedlichen Ebenen.

Wie multipart/form-data funktioniert

Wenn ein Browser ein Formular mit dem Attribut enctype="multipart/form-data" absendet, konstruiert er den Anforderungskörper im Multipart-Format. Jedes Formularfeld wird zu einem separaten Block, der durch eine Boundary-Zeichenfolge von anderen getrennt ist. Die Grenze wird automatisch generiert und ist eine eindeutige Zeichensequenz, die garantiert nicht innerhalb der Daten vorkommt. Der Client fügt diese Grenze zum Content-Type-Header hinzu: multipart/form-data; boundary=----WebKitFormBoundaryX7K.

Jeder Block beginnt mit --boundary und enthält Content-Disposition-Header mit dem Feldnamen (name) und, bei Dateien, dem ursprünglichen Dateinamen (filename). Nach einer Leerzeile folgen die eigentlichen Felddaten oder der Dateiinhalt in binärer Form. Die Anfrage endet mit der Zeichenfolge --boundary--. Der Server parst den empfangenen Stream: Zuerst findet er die Grenze, dann extrahiert er die Header jedes Teils, bestimmt den Datentyp und übergibt sie an den Formular-Handler oder API-Controller.

Gemäß IETF RFC 7578 erfordert multipart/form-data keine Angabe eines Zeichensatzes für jeden Teil, da Textfelder als UTF-8 betrachtet werden und binäre Teile Dateien in ihrer ursprünglichen Kodierung enthalten. Die Größe eines Teils ist nicht durch das Protokoll begrenzt — Grenzen werden auf Serverebene festgelegt: z.B. in Nginx über client_max_body_size, in Spring Boot über spring.servlet.multipart.max-file-size.

Boundary-Format und seine Erzeugung

Boundary ist eine eindeutige Zeichenfolge, die in den übertragenen Daten nicht vorkommen darf. Sie beginnt normalerweise mit einem Präfix (z.B. ----WebKitFormBoundary oder ----Boundary) und enthält zufällige Zeichen. Browser und HTTP-Clients generieren den Boundary automatisch. Die Länge des Boundary darf gemäß RFC 2046 70 Zeichen nicht überschreiten. Jeder Teil wird durch die Zeichenfolge --boundary\r\n getrennt, und das Ende der Anfrage wird durch --boundary--\r\n markiert.

Struktur einer Multipart-Anfrage

Eine Multipart-Anfrage hat eine strenge, durch MIME- und HTTP-Standards definierte Struktur. Der Anforderungsheader setzt Content-Type: multipart/form-data mit einem Boundary-Parameter. Der Anforderungskörper besteht aus einer Folge von Teilen, jeder mit eigenen Headern und Körper. Die Teil-Header umfassen Content-Disposition (obligatorisch) und Content-Type (optional — für Dateien). Eine Leerzeile zwischen den Teil-Headern und den Daten ist obligatorisch.

Beispiel einer Multipart-Anfrage

Betrachten wir ein reales Beispiel einer Multipart-Anfrage, die ein Textfeld und eine Bilddatei sendet. Der Client bildet den Content-Type-Header mit einem eindeutigen Boundary. Der Anforderungskörper enthält nacheinander alle Formularfelder. Beim Empfang parst der Server diese Teile und gewährt dem Entwickler Zugriff auf jedes Feld als separates Objekt. Dieser Ansatz ermöglicht die Verarbeitung komplexer Formulare mit Dateien in einem einzigen HTTP-Aufruf.

import okhttp3.*
import java.io.File

fun uploadFile() {
    val client = OkHttpClient()
    val imageFile = File("/path/to/photo.jpg")

    val requestBody = MultipartBody.Builder()
        .setType(MediaType.parse("multipart/form-data"))
        .addFormDataPart("username", "john_doe")
        .addFormDataPart(
            "avatar", "photo.jpg",
            RequestBody.create(
                MediaType.parse("image/jpeg"), imageFile
            )
        )
        .build()

    val request = Request.Builder()
        .url("https://api.example.com/upload")
        .post(requestBody)
        .build()

    client.newCall(request).execute().use { response ->
        println("Hochgeladen: ${response.isSuccessful}")
    }
}

Parsen einer Multipart-Antwort auf dem Server

Auf der Serverseite wird die Multipart-Anfrage vom Framework oder manuell geparst. In Spring Boot reicht die Annotation @RequestParam("avatar") MultipartFile file aus, und das Framework extrahiert automatisch die Datei aus der Multipart-Anfrage. In Ktor auf Kotlin wird receiveMultipart() verwendet, in Express.js — die Multer-Middleware. Der Server erhält Zugriff auf jedes Formularfeld und jede hochgeladene Datei unabhängig, speichert die Datei auf der Festplatte oder in der Cloud und gibt eine URL oder Kennung an den Client zurück.

Vorteile des Mehrkomponenten-Uploads

Multipart Upload bietet mehrere wichtige Vorteile gegenüber alternativen Datenübertragungsmethoden. Eine Anfrage statt vieler — alle Formularfelder und Dateien werden in einem einzigen HTTP-Aufruf übertragen, was die Netzwerk- und Serverlast reduziert. Es müssen keine N Verbindungen zum Hochladen von N Dateien geöffnet werden — alles wird in einem POST verpackt. Dies ist besonders wichtig für Mobilanwendungen, bei denen jede HTTP-Verbindung Latenz und Batterieverbrauch bedeutet.

Binäre Übertragung ohne Kodierung — im Gegensatz zu application/x-www-form-urlencoded, bei dem Binärdaten in base64 kodiert werden (Größensteigerung um 33%), überträgt multipart/form-data Dateien in ihrer ursprünglichen binären Form. Dies ist effizienter in Bezug auf Größe und Geschwindigkeit. Bei großen Dateien über 10 MB wird der Unterschied kritisch: Eine Multipart-Anfrage ist 30% kleiner als eine URL-kodierte Anfrage mit derselben Datei.

Beliebige Struktur — Multipart ermöglicht die Kombination von Feldern verschiedener Typen in beliebiger Reihenfolge. Ein Formular kann gleichzeitig Textfelder, mehrere Dateien, JSON-Daten und versteckte Felder enthalten. Jeder Teil hat seinen eigenen Content-Type, was die Mischung von Text- und Binärdaten ermöglicht. Zum Vergleich: base64-Kodierung fügt 33% zur Größe hinzu, während Multipart nur etwa 5-15% für Service-Header hinzufügt.

Vergleich von Multipart mit anderen Übertragungsformaten

Laut der Studie HTTP Archive, 2025 wird multipart/form-data in 94% der Datei-Upload-Fälle im Web verwendet. Alternativen — base64 in JSON (4%) und direkte Übertragung über WebSocket (2%). JSON mit base64 ist praktisch für APIs, bei denen alle anderen Daten ebenfalls im JSON-Format vorliegen, aber ineffizient für große Dateien. WebSocket eignet sich für Echtzeitdaten, wird aber nicht von allen HTTP-Infrastrukturen unterstützt. Multipart bleibt aufgrund seiner Einfachheit und Effizienz der Standard für Datei-Uploads.

Multipart Upload in der Mobilanwendung

In Mobilanwendungen wird Multipart Upload verwendet, um Medieninhalte von Benutzergeräten zu senden: Fotos aus der Galerie, Kameraaufnahmen, Sprachaufnahmen, Dokumentdateien. Auf Android ist der Standardansatz OkHttp mit MultipartBody.Builder, der die einfache Erstellung von Multipart-Anfragen ermöglicht. Retrofit unterstützt ebenfalls Multipart über die Annotationen @Multipart und @Part. Der Entwickler gibt den Datentyp für jeden Teil an, und der HTTP-Client generiert automatisch die richtigen Header.

Auf iOS werden dieselben Aufgaben mit URLSession mit benutzerdefiniertem HTTPBodyStream oder über Alamofire mit multipartFormData gelöst. Alamofire bietet eine praktische Methode upload(multipartFormData:) zum Senden von Multipart-Anfragen. Auf beiden Plattformen ist die Größe der hochgeladenen Dateien zu berücksichtigen — für große Dateien (über 10-20 MB) wird empfohlen, den Hintergrund-Upload zu verwenden, damit die Anwendung beim Minimieren nicht beendet wird. Auf Android geschieht dies über DownloadManager oder WorkManager, auf iOS über URLSession mit Hintergrundkonfiguration.

Beim Hochladen von Dateien in Mobilanwendungen muss der Netzwerkstatus berücksichtigt werden. Connectivity Manager auf Android hilft festzustellen, ob Wi-Fi oder mobile Daten verfügbar sind, und den optimalen Zeitpunkt für den Upload zu wählen. Für große Dateien wie Videos wird empfohlen, den Upload bis zur Verbindung mit Wi-Fi zu verschieben, um die mobilen Daten des Benutzers nicht zu verbrauchen. WorkManager auf Android ermöglicht die Festlegung solcher Einschränkungen über NetworkType.UNMETERED.

Upload-Optimierung: Komprimierung und Größenänderung

Vor dem Senden einer Datei über Multipart Upload komprimieren und ändern Mobilanwendungen häufig die Bildgröße. JPEG-Komprimierung mit 85% Qualität reduziert die Dateigröße um das 3- bis 5-fache ohne merklichen Qualitätsverlust für die Bildschirmanzeige. Die Größenänderung des Bildes auf 1920px auf der längeren Seite reduziert die Größe weiter. Auf Android wird dies mit Bitmap.compress() erreicht, auf iOS mit UIImageJPEGRepresentation mit einem Komprimierungsparameter von 0,85. Eine solche Optimierung beschleunigt den Upload und spart mobile Daten.

Fehler und Einschränkungen von Multipart Upload

Der häufigste Fehler bei Multipart Upload ist die Überschreitung des Server-Anfragegrößenlimits. Standardmäßig begrenzt Nginx die Anforderungskörpergröße auf 1 MB (client_max_body_size) und Tomcat auf 2 MB (maxSwallowSize). Wenn der Entwickler diese Grenzen nicht erhöht, gibt der Server einen 413 Request Entity Too Large-Fehler zurück. Die Lösung besteht darin, die maximale Upload-Größe auf dem Server explizit zu konfigurieren und auf dem Client eine Warnung anzuzeigen, wenn die Datei die zulässige Größe überschreitet.

Das zweite Problem ist die falsche Handhabung von Multipart-Anfragen während des Body-Streamings. Einige Server versuchen, die gesamte Multipart-Anfrage vor dem Parsen in den Speicher zu laden, was bei großen Dateien zu OutOfMemoryError führt. Moderne Server (Nginx, Spring Boot, Ktor) unterstützen das Streaming-Parsing von Multipart, bei dem jeder Teil bei seinem Eintreffen verarbeitet wird. Der Entwickler muss sicherstellen, dass der Server für die Streaming-Verarbeitung von Multipart-Anfragen konfiguriert ist.

Die dritte Problemkategorie sind Timeouts beim Hochladen großer Dateien. HTTP-Clients haben readTimeout- und connectTimeout-Einstellungen, die bei langen Uploads von Dateien über 50-100 MB ausgelöst werden können. Die Lösung besteht darin, die Timeouts für Upload-Endpunkte zu erhöhen oder die Chunked-Transfer-Kodierung innerhalb von Multipart zu verwenden. Auf mobilen Geräten ist es auch wichtig, Upload-Unterbrechungen zu behandeln und eine Wiederaufnahme (Resume) bei Verbindungsverlust zu implementieren.

Sicherheit von Multipart Upload

Datei-Upload über Multipart ist einer der am stärksten gefährdeten Endpunkte einer Webanwendung. Ein Angreifer kann ein ausführbares Skript hochladen, indem er es in image.jpg umbenennt. Der Server muss den MIME-Typ der hochgeladenen Datei nicht anhand der Erweiterung, sondern anhand des Inhalts (magic bytes) überprüfen, die zulässigen Typen einschränken und die Dateien mit einem Virenscanner überprüfen. Es wird empfohlen, hochgeladene Dateien außerhalb des document-root des Webservers zu speichern und über einen separaten Controller mit Zugriffsrechteprüfung bereitzustellen.