Multipart Upload a webfejlesztésben: lényeg, szerkezet és a multipart/form-data működése

Mi az a Multipart Upload?

Multipart Upload egy adattovábbítási módszer a HTTP protokollon keresztül, ahol a kérés törzse több logikailag elkülönített részből áll. Minden rész különböző típusú adatokat tartalmazhat: űrlap szöveges mező, bináris fájl, JSON-objektum vagy kép. Az összes rész egyetlen POST-kérésbe van csomagolva, ami kiküszöböli N különálló HTTP-hívás elküldésének szükségességét. A Multipart Upload a webes űrlapok és a fájlfeltöltő API-k szerves része.

A multipart formátumot a RFC 2046 specifikáció határozta meg az e-mail üzenetek MIME szabványának részeként, majd az RFC 1867-ben adaptálták HTTP-re. Ma a webfejlesztésben szinte kizárólag a multipart/form-data-t használják — a multipart egyik altípusát, amelyet fájlokat tartalmazó űrlapokhoz terveztek. Más altípusok — multipart/mixed (tetszőleges mellékletekhez) és multipart/byteranges (fájlok részleges letöltéséhez) — sokkal ritkábban fordulnak elő.

Az alapvető különbség a multipart és az egyszerű application/x-www-form-urlencoded között az, hogy az utóbbi az összes adatot URI-kompatibilis sztringgé kódolja, és nem támogatja a bináris fájlokat. A multipart/form-data ezzel szemben minden fájlt az eredeti bináris formájában továbbít kódolás nélkül, ami hatékonyabb és nem veszít pontosságból. A kérés mérete multipart esetén csak 5-15%-kal nagyobb a fájlméretek összegénél a részek fejlécei és határolói miatti többletköltségek következtében.

Mikor használják a Multipart Upload-ot

Multipart Upload-ot mindenhol alkalmazzák, ahol fájlfeltöltésre van szükség: avatárok és profilképek a közösségi hálózatokon, mellékletek az üzenetküldőkben, dokumentumok CRM-rendszerekben, termékképek az online áruházakban. Mobil alkalmazásokban a Multipart Upload a médiatartalmak szerverre küldésére szolgál — fényképek a készülék kamerájáról, hangfelvételek, videórészletek. A Cloudflare Research adatai szerint az összes webes POST-kérés körülbelül 15%-a használ multipart/form-data-t.

Különbség a multipart és a chunked transfer között

Multipart Upload és a Chunked Transfer különböző mechanizmusok. A multipart a kérést tartalmi részekre (mezők és fájlok) bontja, míg a Chunked Transfer az adatfolyamot darabolja fel fragmentumokra a teljes méret ismerete nélkül történő továbbításhoz. A multipart továbbítható a Chunked Transferen belül: a szerver a multipart választ részenként küldi el anélkül, hogy ismerné a teljes méretét. Ezek a mechanizmusok nem ellentétesek, és különböző szinteken oldanak meg különböző feladatokat.

Hogyan működik a multipart/form-data

Amikor a böngésző elküld egy űrlapot enctype="multipart/form-data" attribútummal, multipart formátumban hozza létre a kérés törzsét. Az űrlap minden mezője külön blokká válik, amelyeket határolósztring (boundary) választ el egymástól. A határoló automatikusan generálódik, és egy egyedi karaktersorozat, amely garantáltan nem fordul elő az adatokon belül. A kliens hozzáadja ezt a határolót a Content-Type fejléchez: multipart/form-data; boundary=----WebKitFormBoundaryX7K.

Minden blokk --boundary-val kezdődik, és tartalmazza a Content-Disposition fejléceket a mező nevével (name) és fájlok esetén az eredeti fájlnévvel (filename). Egy üres sor után közvetlenül a mező adatai vagy a fájl tartalma következik bináris formában. A kérés a --boundary-- sztringgel végződik. A szerver elemzi a beérkező adatfolyamot: először megtalálja a határolót, majd kinyeri az egyes részek fejléceit, meghatározza az adattípust, és továbbítja az űrlapkezelőnek vagy az API-vezérlőnek.

Az IETF RFC 7578 szerint a multipart/form-data nem igényel a charset megadását minden részhez, mivel a szöveges mezők UTF-8-nak tekintendők, a bináris részek pedig a fájlokat az eredeti kódolásban tartalmazzák. Egyetlen rész méretét nem korlátozza a protokoll — a korlátozások szerver szinten konfigurálhatók: például az Nginxben a client_max_body_size, a Spring Bootban a spring.servlet.multipart.max-file-size segítségével.

A boundary formátuma és generálása

Boundary egy egyedi sztring, amely nem fordulhat elő a továbbított adatokban. Általában előtaggal kezdődik (pl. ----WebKitFormBoundary vagy ----Boundary), és véletlenszerű karaktereket tartalmaz. A böngészők és HTTP-kliensek automatikusan generálják a boundary-t. A boundary hossza az RFC 2046 szerint nem haladhatja meg a 70 karaktert. Minden részt a --boundary\r\n sztring választ el, a kérés végét pedig a --boundary--\r\n sztring jelzi.

A multipart kérés szerkezete

A multipart kérés szigorú szerkezettel rendelkezik, amelyet a MIME és HTTP szabványok határoznak meg. A kérés fejléce beállítja a Content-Type: multipart/form-data-t a boundary paraméterrel. A kérés törzse részek sorozatából áll, amelyek mindegyike saját fejlécekkel és törzzsel rendelkezik. A rész fejlécei tartalmazzák a Content-Disposition-t (kötelező) és a Content-Type-ot (opcionális — fájlok esetén). Kötelező az üres sor a rész fejlécei és az adatok között.

Példa multipart kérésre

Vizsgáljunk meg egy valós példát egy multipart kérésre, amely egy szöveges mezőt és egy képfájlt küld. A kliens létrehozza a Content-Type fejlécet egy egyedi boundary-val. A kérés törzse sorrendben tartalmazza az űrlap összes mezőjét. A szerver fogadáskor elemzi ezeket a részeket, és hozzáférést biztosít a fejlesztőnek minden mezőhöz, mint külön objektumhoz. Ez a megközelítés lehetővé teszi összetett, fájlokat tartalmazó űrlapok feldolgozását egyetlen HTTP-hívásban.

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

Multipart válasz elemzése a szerveren

A szerver oldalon a multipart kérést a keretrendszer vagy manuálisan elemzi. Spring Bootban elegendő a @RequestParam("avatar") MultipartFile file annotáció, és a keretrendszer automatikusan kinyeri a fájlt a multipart kérésből. A Kotlin Ktorban a receiveMultipart(), az Express.js-ben a multer middleware használatos. A szerver hozzáférést kap az űrlap minden mezőjéhez és minden feltöltött fájlhoz függetlenül, elmenti a fájlt a lemezre vagy felhőtárhelyre, és visszaadja a kliensnek az URL-t vagy azonosítót.

A többkomponensű feltöltés előnyei

A Multipart Upload számos kulcsfontosságú előnyt kínál az alternatív adattovábbítási módszerekkel szemben. Egyetlen kérés több helyett — az űrlap összes mezője és fájlja egyetlen HTTP-hívásban kerül továbbításra, ami csökkenti a hálózati és szerverterhelést. Nem kell N kapcsolatot nyitni N fájl feltöltéséhez — minden egyetlen POST-ba van csomagolva. Ez különösen fontos a mobil alkalmazásoknál, ahol minden HTTP-kapcsolat késleltetést és akkumulátorfogyasztást jelent.

Bináris továbbítás kódolás nélkül — az application/x-www-form-urlencoded-del ellentétben, ahol a bináris adatok base64-be vannak kódolva (33%-os méretnövekedés), a multipart/form-data a fájlokat eredeti bináris formában továbbítja. Ez méret és sebesség szempontjából is hatékonyabb. A 10 MB-tól nagyobb fájlok esetén a különbség kritikussá válik: a multipart kérés 30%-kal kisebb lesz, mint egy URL-kódolt kérés ugyanazzal a fájllal.

Tetszőleges szerkezet — a multipart lehetővé teszi különböző típusú mezők tetszőleges sorrendben történő kombinálását. Az űrlap egyszerre tartalmazhat szöveges mezőket, több fájlt, JSON-adatokat és rejtett mezőket. Minden rész saját Content-Type-nal rendelkezik, ami lehetővé teszi a szöveges és bináris adatok keverését. Összehasonlításképpen: a base64 kódolás 33%-ot ad hozzá a mérethez, míg a multipart csak körülbelül 5-15%-ot a szolgáltatásfejlécekre.

A multipart összehasonlítása más továbbítási formátumokkal

A HTTP Archive, 2025 tanulmánya szerint a multipart/form-data-t a fájlfeltöltések 94%-ában használják a weben. Alternatívák — base64 JSON-ban (4%) és közvetlen továbbítás WebSocketen keresztül (2%). A JSON base64-dzsel kényelmes az olyan API-khoz, ahol az összes többi adat is JSON-ban van, de nem hatékony nagy fájlok esetén. A WebSocket valós idejű használatra alkalmas, de nem minden HTTP-infrastruktúra támogatja. A multipart egyszerűsége és hatékonysága miatt marad a fájlfeltöltés szabványa.

Multipart Upload a mobilfejlesztésben

Mobil alkalmazásokban a Multipart Upload a felhasználók eszközeiről származó médiatartalmak küldésére szolgál: galériából származó fényképek, kameraképek, hangfelvételek, dokumentumfájlok. Androidon a szabványos módszer az OkHttp a MultipartBody.Builder-rel, amely lehetővé teszi a multipart kérések egyszerű létrehozását. A Retrofit is támogatja a multipart-ot a @Multipart és @Part annotációkon keresztül. A fejlesztő meghatározza az adattípust minden részhez, a HTTP-kliens automatikusan létrehozza a megfelelő fejléceket.

iOS-en ugyanezeket a feladatokat URLSession-nel oldják meg egyéni HTTPBodyStream-mel vagy Alamofire-rel multipartFormData-val. Az Alamofire kényelmes upload(multipartFormData:) metódust biztosít a multipart kérések küldéséhez. Mindkét platformon fontos figyelembe venni a feltöltött fájlok méretét — nagy fájlok (több mint 10-20 MB) esetén ajánlott a háttérben történő feltöltés használata, hogy az alkalmazás ne záródjon be minimalizáláskor. Androidon ehhez DownloadManager vagy WorkManager, iOS-en — URLSession background konfigurációval.

A fájlok mobil alkalmazásokban történő feltöltésekor figyelembe kell venni a hálózat állapotát. Connectivity Manager Androidon segít meghatározni, hogy Wi-Fi vagy mobil adat áll-e rendelkezésre, és kiválasztani az optimális pillanatot a feltöltéshez. Nagy fájlok, például videók esetén ajánlott a feltöltést elhalasztani a Wi-Fi-hez való csatlakozásig, hogy ne használja fel a felhasználó mobil adatforgalmát. Androidon a WorkManager lehetővé teszi ilyen korlátozások konfigurálását a NetworkType.UNMETERED segítségével.

A feltöltés optimalizálása: tömörítés és átméretezés

A fájl Multipart Upload-on keresztül történő elküldése előtt a mobil alkalmazások gyakran tömörítik és átméretezik a képet. JPEG tömörítés 85%-os minőséggel 3-5-szörösére csökkenti a fájlméretet anélkül, hogy észrevehető minőségromlás következne be a képernyőn történő megtekintéshez. A kép hosszabb oldalának 1920px-re történő átméretezése tovább csökkenti a méretet. Androidon ehhez a Bitmap.compress(), iOS-en a UIImageJPEGRepresentation 0,85-ös tömörítési paraméterrel használatos. Az ilyen optimalizálás felgyorsítja a feltöltést és mobil adatforgalmat takarít meg.

A Multipart Upload hibái és korlátai

A Multipart Upload leggyakoribb hibája — a kérés méretkorlátjának túllépése a szerveren. Alapértelmezés szerint az Nginx 1 MB-ra (client_max_body_size), a Tomcat 2 MB-ra (maxSwallowSize) korlátozza a kérés törzsének méretét. Ha a fejlesztő nem növeli ezeket a korlátokat, a szerver 413 Request Entity Too Large hibát ad vissza. Megoldás — explicit módon konfigurálni a maximális feltöltési méretet a szerveren, és figyelmeztetést megjeleníteni a kliensen, ha a fájl meghaladja a megengedett méretet.

A második probléma — a multipart kérések helytelen feldolgozása a törzs streamelésekor. Egyes szerverek a teljes multipart kérést a memóriába próbálják betölteni az elemzés előtt, ami OutOfMemoryError-hoz vezet nagy fájlok esetén. A modern szerverek (Nginx, Spring Boot, Ktor) támogatják a multipart streamelő elemzését, amikor minden rész feldolgozásra kerül, amint megérkezik. A fejlesztőnek meg kell győződnie arról, hogy a szerver streamelő feldolgozásra van konfigurálva a multipart kérésekhez.

A harmadik problémakategória — időtúllépések nagy fájlok feltöltésekor. A HTTP-kliensek readTimeout és connectTimeout beállításokkal rendelkeznek, amelyek aktiválódhatnak egy 50-100 MB-nál nagyobb fájl hosszan tartó feltöltésekor. Megoldás — növelni az időtúllépéseket a feltöltési végpontokhoz, vagy chunked transfer encoding-ot használni a multiparton belül. Mobileszközökön szintén fontos a feltöltés megszakításának kezelése és a folytatás (resume) megvalósítása kapcsolat megszakadása esetén.

A Multipart Upload biztonsága

Fájlok feltöltése multiparton keresztül a webes alkalmazás egyik legsérülékenyebb végpontja. A támadó feltölthet egy végrehajtható szkriptet, átnevezve azt image.jpg-re. A szervernek a feltöltött fájl MIME-típusát nem a kiterjesztés, hanem a tartalom alapján (magic bytes) kell ellenőriznie, korlátoznia kell a megengedett típusokat, és vírusirtóval kell ellenőriznie a fájlokat. Ajánlott a feltöltött fájlokat a webszerver document-root-ján kívül tárolni, és azokat egy külön vezérlőn keresztül szolgáltatni hozzáférési jogosultságok ellenőrzésével.