Multipart Upload in webontwikkeling: essentie, structuur en hoe multipart/form-data werkt

Wat is Multipart Upload?

Multipart Upload is een methode voor gegevensoverdracht via het HTTP-protocol, waarbij de body van het verzoek uit meerdere logisch gescheiden delen bestaat. Elk deel kan verschillende soorten gegevens bevatten: een tekstveld van een formulier, een binair bestand, een JSON-object of een afbeelding. Alle delen worden in één POST-verzoek verpakt, wat de noodzaak om N afzonderlijke HTTP-aanroepen te verzenden overbodig maakt. Multipart Upload is een integraal onderdeel van webformulieren en API's voor het uploaden van bestanden.

Het multipart-formaat werd gedefinieerd in specificatie RFC 2046 als onderdeel van de MIME-standaard voor e-mailberichten en vervolgens aangepast voor HTTP in RFC 1867. Tegenwoordig wordt in webontwikkeling bijna uitsluitend multipart/form-data gebruikt — een van de subtypen van multipart, bedoeld voor formulieren met bestanden. Andere subtypen — multipart/mixed (voor willekeurige bijlagen) en multipart/byteranges (voor gedeeltelijk downloaden van bestanden) — worden veel minder gebruikt.

Het fundamentele verschil tussen multipart en eenvoudig application/x-www-form-urlencoded is dat laatstgenoemde alle gegevens codeert in een URI-compatibele string en binaire bestanden niet ondersteunt. Multipart/form-data daarentegen verzendt elk bestand in zijn oorspronkelijke binaire vorm zonder codering, wat efficiënter is en geen precisie verliest. De verzoekgrootte bij multipart is slechts 5-15% groter dan de som van de bestandsgroottes vanwege de overhead voor deelheaders en grenzen.

Wanneer wordt Multipart Upload gebruikt

Multipart Upload wordt overal gebruikt waar bestandsupload vereist is: avatars en profielfoto's op sociale netwerken, bijlagen in messengers, documenten in CRM-systemen, productafbeeldingen in webwinkels. In mobiele applicaties wordt Multipart Upload gebruikt voor het verzenden van mediabestanden naar de server — foto's van de camera van het apparaat, spraakopnames, videofragmenten. Volgens Cloudflare Research gebruikt ongeveer 15% van alle POST-verzoeken op het web multipart/form-data.

Verschil tussen multipart en chunked transfer

Multipart Upload en Chunked Transfer zijn verschillende mechanismen. Multipart verdeelt het verzoek in inhoudelijke delen (velden en bestanden), terwijl Chunked Transfer de gegevensstroom in fragmenten verdeelt voor verzending zonder kennis van de totale grootte. Multipart kan worden verzonden binnen Chunked Transfer: de server stuurt het multipart-antwoord in delen, zonder de volledige omvang te kennen. Deze mechanismen zijn niet tegenstrijdig en lossen verschillende taken op verschillende niveaus op.

Hoe multipart/form-data werkt

Wanneer de browser een formulier met het attribuut enctype="multipart/form-data" verzendt, construeert hij de request-body in multipart-formaat. Elk formulierveld wordt een afzonderlijk blok, gescheiden van andere door een grenslijn (boundary). De grens wordt automatisch gegenereerd en is een unieke reeks tekens die gegarandeerd niet in de gegevens voorkomt. De client voegt deze grens toe aan de Content-Type-header: multipart/form-data; boundary=----WebKitFormBoundaryX7K.

Elk blok begint met --boundary en bevat Content-Disposition-headers met de veldnaam (name) en, voor bestanden, de oorspronkelijke bestandsnaam (filename). Na een lege regel volgen direct de veldgegevens of de bestandsinhoud in binaire vorm. Het verzoek eindigt met de string --boundary--. De server parseert de ontvangen stroom: eerst vindt hij de grens, dan extraheert hij de headers van elk deel, bepaalt het gegevenstype en geeft ze door aan de formulierhandler of API-controller.

Volgens IETF RFC 7578 vereist multipart/form-data geen opgave van charset voor elk deel, omdat tekstvelden als UTF-8 worden beschouwd en binaire delen bestanden in hun oorspronkelijke codering bevatten. De grootte van één deel wordt niet beperkt door het protocol — beperkingen worden geconfigureerd op serverniveau: bijvoorbeeld in Nginx via client_max_body_size, in Spring Boot via spring.servlet.multipart.max-file-size.

Formaat van boundary en het genereren ervan

Boundary is een unieke string die niet mag voorkomen in de verzonden gegevens. Meestal begint deze met een prefix (bijv. ----WebKitFormBoundary of ----Boundary) en bevat willekeurige tekens. Browsers en HTTP-clients genereren de boundary automatisch. De lengte van de boundary mag niet meer dan 70 tekens bedragen volgens RFC 2046. Elk deel wordt gescheiden door de string --boundary\r\n, en het einde van het verzoek door --boundary--\r\n.

Structuur van een multipart-verzoek

Een multipart-verzoek heeft een strikte structuur zoals gedefinieerd door de MIME- en HTTP-standaarden. De request-header stelt Content-Type: multipart/form-data in met de parameter boundary. De request-body bestaat uit een reeks delen, die elk hun eigen headers en body bevatten. Deelheaders omvatten Content-Disposition (verplicht) en Content-Type (optioneel — voor bestanden). Een lege regel tussen de deelheaders en de gegevens is verplicht.

Voorbeeld van een multipart-verzoek

Laten we een realistisch voorbeeld bekijken van een multipart-verzoek dat een tekstveld en een afbeeldingsbestand verzendt. De client vormt de Content-Type-header met een unieke boundary. De request-body bevat achtereenvolgens alle formuliervelden. De server parseert bij ontvangst deze delen en geeft de ontwikkelaar toegang tot elk veld als een afzonderlijk object. Deze aanpak maakt het mogelijk complexe formulieren met bestanden in één HTTP-aanroep te verwerken.

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("Geüpload: ${response.isSuccessful}")
    }
}

Parseren van multipart-antwoord op de server

Aan de serverzijde wordt het multipart-verzoek geparseerd door het framework of handmatig. In Spring Boot is de annotatie @RequestParam("avatar") MultipartFile file voldoende, en het framework extraheert automatisch het bestand uit het multipart-verzoek. In Ktor op Kotlin wordt receiveMultipart() gebruikt, in Express.js — de multer middleware. De server krijgt toegang tot elk formulierveld en elk geüpload bestand onafhankelijk, slaat het bestand op schijf of in cloudopslag op en retourneert de URL of identifier aan de client.

Voordelen van multicomponent uploaden

Multipart Upload biedt verschillende belangrijke voordelen ten opzichte van alternatieve manieren van gegevensoverdracht. Één verzoek in plaats van meerdere — alle formuliervelden en bestanden worden in één HTTP-aanroep verzonden, wat de netwerk- en serverbelasting vermindert. Het is niet nodig N verbindingen te openen om N bestanden te uploaden — alles wordt in één POST verpakt. Dit is vooral belangrijk voor mobiele applicaties, waar elke HTTP-verbinding vertraging en batterijverbruik betekent.

Binaire overdracht zonder codering — in tegenstelling tot application/x-www-form-urlencoded, waar binaire gegevens in base64 worden gecodeerd (33% grotere omvang), verzendt multipart/form-data bestanden in hun oorspronkelijke binaire vorm. Dit is efficiënter qua omvang en snelheid. Voor grote bestanden vanaf 10 MB wordt het verschil kritisch: een multipart-verzoek is 30% kleiner dan een URL-encoded verzoek met hetzelfde bestand.

Willekeurige structuur — multipart maakt het mogelijk velden van verschillende typen in willekeurige volgorde te combineren. Een formulier kan tegelijkertijd tekstvelden, meerdere bestanden, JSON-gegevens en verborgen velden bevatten. Elk deel heeft zijn eigen Content-Type, wat het mogelijk maakt tekst- en binaire gegevens te mengen. Ter vergelijking: base64-codering voegt 33% toe aan de omvang, terwijl multipart slechts ongeveer 5-15% toevoegt voor service-headers.

Vergelijking van multipart met andere overdrachtsformaten

Volgens het onderzoek HTTP Archive, 2025 wordt multipart/form-data gebruikt in 94% van de bestandsuploads op het web. Alternatieven — base64 in JSON (4%) en directe overdracht via WebSocket (2%). JSON met base64 is handig voor API's waar alle andere gegevens ook in JSON zijn, maar inefficiënt voor grote bestanden. WebSocket is geschikt voor real-time, maar wordt niet door alle HTTP-infrastructuren ondersteund. Multipart blijft de standaard voor bestandsupload vanwege zijn eenvoud en efficiëntie.

Multipart Upload in mobiele ontwikkeling

In mobiele applicaties wordt Multipart Upload gebruikt voor het verzenden van media-inhoud van gebruikersapparaten: foto's uit de galerij, camerabeelden, spraakopnames, documentbestanden. Op Android is de standaardmanier OkHttp met MultipartBody.Builder, waarmee eenvoudig multipart-verzoeken kunnen worden gevormd. Retrofit ondersteunt ook multipart via de annotaties @Multipart en @Part. De ontwikkelaar specificeert het gegevenstype voor elk deel, de HTTP-client genereert automatisch de juiste headers.

Op iOS worden dezelfde taken opgelost via URLSession met aangepaste HTTPBodyStream of via Alamofire met multipartFormData. Alamofire biedt de handige methode upload(multipartFormData:) voor het verzenden van multipart-verzoeken. Op beide platforms is het belangrijk rekening te houden met de grootte van de te uploaden bestanden — voor grote bestanden (meer dan 10-20 MB) wordt aangeraden achtergrondupload te gebruiken, zodat de applicatie niet wordt afgesloten bij minimaliseren. Op Android wordt hiervoor DownloadManager of WorkManager gebruikt, op iOS — URLSession met background-configuratie.

Bij het uploaden van bestanden in mobiele applicaties moet rekening worden gehouden met de netwerkstatus. Connectivity Manager op Android helpt bepalen of Wi-Fi of mobiele data beschikbaar is en het optimale moment voor upload te kiezen. Voor grote bestanden zoals video wordt aangeraden de upload uit te stellen tot verbinding met Wi-Fi, om de mobiele data van de gebruiker niet te verbruiken. WorkManager op Android maakt het mogelijk dergelijke beperkingen te configureren via NetworkType.UNMETERED.

Optimalisatie van upload: compressie en formaatwijziging

Voordat een bestand via Multipart Upload wordt verzonden, comprimeren en wijzigen mobiele applicaties vaak de afbeeldingsgrootte. JPEG-compressie met een kwaliteit van 85% vermindert de bestandsgrootte 3-5 keer zonder merkbaar kwaliteitsverlies voor weergave op het scherm. Het wijzigen van de afbeeldingsgrootte naar 1920px aan de lange zijde verkleint de omvang verder. Op Android wordt hiervoor Bitmap.compress() gebruikt, op iOS — UIImageJPEGRepresentation met compressieparameter 0.85. Dergelijke optimalisatie versnelt de upload en bespaart mobiele data.

Fouten en beperkingen van Multipart Upload

De meest voorkomende fout bij Multipart Upload — overschrijding van de verzoekgrootte-limiet op de server. Standaard beperkt Nginx de request-body-grootte tot 1 MB (client_max_body_size) en Tomcat tot 2 MB (maxSwallowSize). Als de ontwikkelaar deze limieten niet verhoogt, retourneert de server de fout 413 Request Entity Too Large. Oplossing — expliciet de maximale uploadgrootte op de server configureren en een waarschuwing op de client tonen als het bestand de toegestane grootte overschrijdt.

Het tweede probleem — onjuiste verwerking van multipart-verzoeken bij het streamen van de body. Sommige servers proberen het hele multipart-verzoek in het geheugen te laden vóór het parsen, wat leidt tot OutOfMemoryError voor grote bestanden. Moderne servers (Nginx, Spring Boot, Ktor) ondersteunen streaming parsing van multipart, waarbij elk deel wordt verwerkt zodra het binnenkomt. De ontwikkelaar moet ervoor zorgen dat de server is geconfigureerd voor streaming verwerking van multipart-verzoeken.

De derde categorie problemen — time-outs bij het uploaden van grote bestanden. HTTP-clients hebben readTimeout- en connectTimeout-instellingen die kunnen worden geactiveerd bij langdurig uploaden van een bestand groter dan 50-100 MB. Oplossing — verhoog de time-outs voor upload-endpoints of gebruik chunked transfer encoding binnen multipart. Op mobiele apparaten is het ook belangrijk de onderbreking van de upload af te handelen en hervatting (resume) te implementeren bij verbindingsverlies.

Beveiliging van Multipart Upload

Het uploaden van bestanden via multipart is een van de meest kwetsbare endpoints van een webapplicatie. Een aanvaller kan een uitvoerbaar script uploaden door het te hernoemen naar image.jpg. De server moet het MIME-type van het geüploade bestand controleren niet op extensie, maar op inhoud (magic bytes), toegestane typen beperken en bestanden scannen met antivirus. Het wordt aanbevolen geüploade bestanden buiten de document-root van de webserver op te slaan en ze via een aparte controller met toegangsrechtencontrole aan te bieden.