Multipart Upload i webbutveckling: kärnan, strukturen och hur multipart/form-data fungerar

Vad är Multipart Upload?

Multipart Upload är en metod för dataöverföring via HTTP-protokollet där begäran består av flera logiskt separerade delar. Varje del kan innehålla data av olika typ: ett textfält från ett formulär, en binär fil, ett JSON-objekt eller en bild. Alla delar packas i en enda POST-begäran, vilket eliminerar behovet av att skicka N separata HTTP-anrop. Multipart Upload är en integrerad del av webbformulär och API:er för filuppladdning.

Multipart-formatet definierades i specifikationen RFC 2046 som en del av MIME-standarden för e-postmeddelanden och anpassades sedan för HTTP i RFC 1867. Idag används inom webbutveckling nästan uteslutande multipart/form-data — en av subtyperna av multipart, avsedd för formulär som innehåller filer. Andra subtyper — multipart/mixed (för godtyckliga bilagor) och multipart/byteranges (för partiell nedladdning av filer) — används mycket mer sällan.

Den grundläggande skillnaden mellan multipart och enkel application/x-www-form-urlencoded är att den senare kodar all data till en URI-kompatibel sträng och inte stöder binära filer. Multipart/form-data överför däremot varje fil i sin ursprungliga binära form utan kodning, vilket är effektivare och inte förlorar precision. Begärans storlek vid multipart är endast 5-15% större än summan av filstorlekarna på grund av omkostnader för delrubriker och gränser.

När används Multipart Upload

Multipart Upload används överallt där filuppladdning krävs: avatarer och profilbilder på sociala nätverk, bilagor i meddelandeprogram, dokument i CRM-system, produktbilder i nätbutiker. I mobilapplikationer används Multipart Upload för att skicka mediainnehåll till servern — foton från enhetens kamera, röstinspelningar, videofragment. Enligt Cloudflare Research använder cirka 15% av alla POST-begäranden på webben multipart/form-data.

Skillnad mellan multipart och chunked transfer

Multipart Upload och Chunked Transfer är olika mekanismer. Multipart delar upp begäran i innehållsrika delar (fält och filer), medan Chunked Transfer delar upp dataströmmen i fragment för överföring utan kännedom om total storlek. Multipart kan överföras inom Chunked Transfer: servern skickar multipart-svaret i delar utan att känna till dess fulla volym. Dessa mekanismer står inte i konflikt med varandra och löser olika uppgifter på olika nivåer.

Hur multipart/form-data fungerar

När webbläsaren skickar ett formulär med attributet enctype="multipart/form-data" konstruerar den begärans kropp i multipart-format. Varje fält i formuläret blir ett separat block, separerat från andra av en gränssträng (boundary). Gränsen genereras automatiskt och är en unik sekvens av tecken som garanterat inte förekommer inuti data. Klienten lägger till denna gräns i Content-Type-rubriken: multipart/form-data; boundary=----WebKitFormBoundaryX7K.

Varje block börjar med --boundary och innehåller Content-Disposition-rubriker med fältnamn (name) och, för filer, det ursprungliga filnamnet (filename). Efter en tom rad följer direkt fältdata eller filinnehåll i binär form. Begäran avslutas med strängen --boundary--. Servern tolkar den mottagna strömmen: först hittar den gränsen, sedan extraherar den rubrikerna för varje del, bestämmer datatypen och skickar dem till formulärhanteraren eller API-kontrollern.

Enligt IETF RFC 7578 kräver multipart/form-data inte angivelse av charset för varje del, eftersom textfält anses vara UTF-8 och binära delar innehåller filer i sin ursprungliga kodning. Storleken på en enskild del begränsas inte av protokollet — begränsningar konfigureras på servernivå: till exempel i Nginx via client_max_body_size, i Spring Boot via spring.servlet.multipart.max-file-size.

Format för boundary och dess generering

Boundary är en unik sträng som inte får förekomma i de överförda data. Den börjar vanligtvis med ett prefix (t.ex. ----WebKitFormBoundary eller ----Boundary) och innehåller slumpmässiga tecken. Webbläsare och HTTP-klienter genererar boundary automatiskt. Längden på boundary bör enligt RFC 2046 inte överstiga 70 tecken. Varje del separeras av strängen --boundary\r\n, och slutet av begäran av --boundary--\r\n.

Struktur för en multipart-begäran

En multipart-begäran har en strikt struktur definierad av MIME- och HTTP-standarderna. Begärans rubrik anger Content-Type: multipart/form-data med parametern boundary. Begärans kropp består av en sekvens av delar, som var och en innehåller egna rubriker och kropp. Delrubriker inkluderar Content-Disposition (obligatorisk) och Content-Type (valfri — för filer). En tom rad mellan delrubrikerna och dess data är obligatorisk.

Exempel på multipart-begäran

Låt oss titta på ett verkligt exempel på en multipart-begäran som skickar ett textfält och en bildfil. Klienten skapar Content-Type-rubriken med en unik boundary. Begärans kropp innehåller i tur och ordning alla formulärfält. Servern vid mottagning tolkar dessa delar och ger utvecklaren åtkomst till varje fält som ett separat objekt. Detta tillvägagångssätt gör det möjligt att bearbeta komplexa formulär med filer i ett enda HTTP-anrop.

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

Tolkning av multipart-svar på servern

På serversidan tolkas multipart-begäran av ramverket eller manuellt. I Spring Boot räcker annotationen @RequestParam("avatar") MultipartFile file, och ramverket extraherar automatiskt filen från multipart-begäran. I Ktor på Kotlin används receiveMultipart(), i Express.js — multer middleware. Servern får tillgång till varje formulärfält och varje uppladdad fil oberoende av varandra, sparar filen på disk eller i molnlagring och returnerar URL eller identifierare till klienten.

Fördelar med flerkomponentsuppladdning

Multipart Upload erbjuder flera viktiga fördelar jämfört med alternativa metoder för dataöverföring. En begäran istället för flera — alla formulärfält och filer överförs i ett enda HTTP-anrop, vilket minskar nätverks- och serverbelastningen. Det behövs inte N anslutningar för att ladda upp N filer — allt paketeras i en enda POST. Detta är särskilt viktigt för mobilapplikationer, där varje HTTP-anslutning innebär fördröjning och batteriförbrukning.

Binär överföring utan kodning — till skillnad från application/x-www-form-urlencoded, där binära data kodas i base64 (33% storleksökning), överför multipart/form-data filer i sin ursprungliga binära form. Detta är effektivare både i storlek och hastighet. För stora filer från 10 MB och uppåt blir skillnaden kritisk: en multipart-begäran kommer att vara 30% mindre än en URL-kodad begäran med samma fil.

Godtycklig struktur — multipart gör det möjligt att kombinera fält av olika typer i valfri ordning. Ett formulär kan samtidigt innehålla textfält, flera filer, JSON-data och dolda fält. Varje del har sin egen Content-Type, vilket gör det möjligt att blanda text- och binärdata. Som jämförelse: base64-kodning lägger till 33% i storlek, medan multipart endast lägger till cirka 5-15% för service-rubriker.

Jämförelse av multipart med andra överföringsformat

Enligt studien HTTP Archive, 2025 används multipart/form-data i 94% av filuppladdningsfallen på webben. Alternativ — base64 i JSON (4%) och direkt överföring via WebSocket (2%). JSON med base64 är praktiskt för API:er där alla andra data också är i JSON, men ineffektivt för stora filer. WebSocket passar för realtid, men stöds inte av alla HTTP-infrastrukturer. Multipart förblir standarden för filuppladdning tack vare sin enkelhet och effektivitet.

Multipart Upload i mobilutveckling

I mobilapplikationer används Multipart Upload för att skicka mediainnehåll från användarens enheter: foton från galleriet, bilder från kameran, röstinspelningar, dokumentfiler. På Android är standardsättet OkHttp med MultipartBody.Builder, som gör det enkelt att skapa multipart-begäranden. Retrofit stöder också multipart via annotationerna @Multipart och @Part. Utvecklaren anger datatyp för varje del, HTTP-klienten genererar automatiskt korrekta rubriker.

På iOS löses samma uppgifter via URLSession med anpassad HTTPBodyStream eller via Alamofire med multipartFormData. Alamofire tillhandahåller den praktiska metoden upload(multipartFormData:) för att skicka multipart-begäranden. På båda plattformarna är det viktigt att ta hänsyn till storleken på filer som laddas upp — för stora filer (över 10-20 MB) rekommenderas bakgrundsuppladdning så att applikationen inte stängs vid minimering. På Android används DownloadManager eller WorkManager för detta, på iOS — URLSession med bakgrundskonfiguration.

Vid uppladdning av filer i mobilapplikationer måste nätverkets status beaktas. Connectivity Manager på Android hjälper till att avgöra om Wi-Fi eller mobildata är tillgängligt och välja den optimala tidpunkten för uppladdning. För stora filer som video rekommenderas att skjuta upp uppladdningen tills anslutning till Wi-Fi, för att inte förbruka användarens mobila trafik. WorkManager på Android gör det möjligt att konfigurera sådana begränsningar via NetworkType.UNMETERED.

Optimering av uppladdning: komprimering och storleksändring

Innan en fil skickas via Multipart Upload komprimerar och ändrar mobilapplikationer ofta bildens storlek. JPEG-komprimering med 85% kvalitet minskar filstorleken 3-5 gånger utan märkbar kvalitetsförlust för visning på skärmen. Storleksändring av bilden till 1920px på den längre sidan minskar storleken ytterligare. På Android används Bitmap.compress() för detta, på iOS — UIImageJPEGRepresentation med komprimeringsparameter 0.85. Sådan optimering påskyndar uppladdningen och sparar mobildata.

Fel och begränsningar med Multipart Upload

Det vanligaste felet vid Multipart Upload — överskridande av begärans storleksgräns på servern. Som standard begränsar Nginx storleken på begärans kropp till 1 MB (client_max_body_size) och Tomcat till 2 MB (maxSwallowSize). Om utvecklaren inte ökar dessa gränser returnerar servern felet 413 Request Entity Too Large. Lösning — konfigurera explicit den maximala uppladdningsstorleken på servern och visa en varning på klienten om filen överskrider den tillåtna storleken.

Det andra problemet — felaktig bearbetning av multipart-begäranden vid strömning av kroppen. Vissa servrar försöker ladda hela multipart-begäran i minnet före tolkning, vilket leder till OutOfMemoryError för stora filer. Moderna servrar (Nginx, Spring Boot, Ktor) stöder strömningstolkning av multipart, där varje del bearbetas när den anländer. Utvecklaren bör säkerställa att servern är konfigurerad för strömningsbearbetning av multipart-begäranden.

Den tredje kategorin av problem — timeout vid uppladdning av stora filer. HTTP-klienter har inställningarna readTimeout och connectTimeout som kan aktiveras vid långvarig uppladdning av en fil större än 50-100 MB. Lösning — öka timeout för uppladdningsändpunkter eller använd chunked transfer encoding inom multipart. På mobila enheter är det också viktigt att hantera avbrott i uppladdningen och implementera återupptagning (resume) vid förlust av anslutning.

Säkerhet för Multipart Upload

Uppladdning av filer via multipart är en av de mest sårbara ändpunkterna i en webbapplikation. En angripare kan ladda upp ett körbart skript genom att byta namn på det till image.jpg. Servern måste kontrollera MIME-typen för den uppladdade filen inte efter filändelse, utan efter innehåll (magic bytes), begränsa tillåtna typer och skanna filer med antivirus. Det rekommenderas att spara uppladdade filer utanför webbserverns document-root och leverera dem via en separat kontroll med åtkomsträttighetskontroll.