वेब डेवलपमेंट में Multipart Upload: सार, संरचना और multipart/form-data कैसे काम करता है

Multipart Upload क्या है?

Multipart Upload HTTP प्रोटोकॉल के माध्यम से डेटा स्थानांतरण की एक विधि है जिसमें अनुरोध का मुख्य भाग कई तार्किक रूप से अलग किए गए भागों से बना होता है। प्रत्येक भाग में विभिन्न प्रकार का डेटा हो सकता है: एक टेक्स्ट फ़ॉर्म फ़ील्ड, एक बाइनरी फ़ाइल, एक JSON ऑब्जेक्ट या एक छवि। सभी भागों को एक ही POST अनुरोध में पैक किया जाता है, जिससे N अलग-अलग HTTP कॉल भेजने की आवश्यकता समाप्त हो जाती है। Multipart Upload वेब फ़ॉर्म और फ़ाइल अपलोड API का एक अनिवार्य हिस्सा है।

मल्टीपार्ट प्रारूप को RFC 2046 विनिर्देश में ईमेल संदेशों के लिए MIME मानक के भाग के रूप में परिभाषित किया गया था, और बाद में RFC 1867 में HTTP के लिए अनुकूलित किया गया। आज, वेब डेवलपमेंट में लगभग विशेष रूप से multipart/form-data का उपयोग किया जाता है — फ़ाइलों वाले फ़ॉर्म के लिए डिज़ाइन किया गया एक मल्टीपार्ट उपप्रकार। अन्य उपप्रकार — multipart/mixed (मनमाने अनुलग्नकों के लिए) और multipart/byteranges (फ़ाइलों के आंशिक डाउनलोड के लिए) — बहुत कम उपयोग किए जाते हैं।

मल्टीपार्ट और साधारण application/x-www-form-urlencoded के बीच मूलभूत अंतर यह है कि बाद वाला सभी डेटा को URI-संगत स्ट्रिंग में एन्कोड करता है और बाइनरी फ़ाइलों का समर्थन नहीं करता है। दूसरी ओर, Multipart/form-data, प्रत्येक फ़ाइल को बिना एन्कोडिंग के उसके मूल बाइनरी रूप में स्थानांतरित करता है, जो अधिक कुशल है और सटीकता नहीं खोता है। अनुरोध का आकार मल्टीपार्ट के साथ भाग हेडर और सीमाओं के ओवरहेड के कारण फ़ाइल आकारों के योग से हमेशा 5-15% बड़ा होता है।

Multipart Upload का उपयोग कब किया जाता है

Multipart Upload का उपयोग हर जगह किया जाता है जहाँ फ़ाइल अपलोड की आवश्यकता होती है: सोशल नेटवर्क में अवतार और प्रोफ़ाइल फ़ोटो, मैसेंजर में अनुलग्नक, CRM सिस्टम में दस्तावेज़, ऑनलाइन स्टोर में उत्पाद छवियाँ। मोबाइल अनुप्रयोगों में, Multipart Upload का उपयोग सर्वर पर मीडिया फ़ाइलें भेजने के लिए किया जाता है — डिवाइस कैमरे से फ़ोटो, वॉइस रिकॉर्डिंग, वीडियो क्लिप। Cloudflare Research के अनुसार, वेब पर लगभग 15% सभी POST अनुरोध multipart/form-data का उपयोग करते हैं।

मल्टीपार्ट और चंक्ड ट्रांसफर के बीच अंतर

Multipart Upload और Chunked Transfer अलग-अलग तंत्र हैं। मल्टीपार्ट एक अनुरोध को सार्थक भागों (फ़ील्ड और फ़ाइलें) में विभाजित करता है, जबकि चंक्ड ट्रांसफर कुल आकार जाने बिना संचरण के लिए डेटा स्ट्रीम को टुकड़ों में विभाजित करता है। मल्टीपार्ट को चंक्ड ट्रांसफर के अंदर प्रेषित किया जा सकता है: सर्वर अपना पूरा आकार जाने बिना मल्टीपार्ट प्रतिक्रिया भागों में भेजता है। ये तंत्र संघर्ष नहीं करते हैं और विभिन्न स्तरों पर विभिन्न समस्याओं का समाधान करते हैं।

multipart/form-data कैसे काम करता है

जब कोई ब्राउज़र enctype="multipart/form-data" विशेषता वाला फ़ॉर्म सबमिट करता है, तो यह अनुरोध मुख्य भाग को मल्टीपार्ट प्रारूप में बनाता है। प्रत्येक फ़ॉर्म फ़ील्ड एक अलग ब्लॉक बन जाता है, जो दूसरों से एक सीमा स्ट्रिंग (boundary) द्वारा अलग किया जाता है। सीमा स्वचालित रूप से उत्पन्न होती है और वर्णों का एक अद्वितीय अनुक्रम है जो डेटा के भीतर नहीं आने की गारंटी है। क्लाइंट इस सीमा को Content-Type हेडर में जोड़ता है: multipart/form-data; boundary=----WebKitFormBoundaryX7K।

प्रत्येक ब्लॉक --boundary से शुरू होता है और इसमें फ़ील्ड नाम (name) और, फ़ाइलों के लिए, मूल फ़ाइल नाम (filename) के साथ Content-Disposition हेडर होते हैं। एक खाली पंक्ति के बाद वास्तविक फ़ील्ड डेटा या बाइनरी रूप में फ़ाइल सामग्री आती है। अनुरोध स्ट्रिंग --boundary-- के साथ समाप्त होता है। सर्वर प्राप्त स्ट्रीम को पार्स करता है: पहले यह सीमा ढूंढता है, फिर प्रत्येक भाग के हेडर निकालता है, डेटा प्रकार निर्धारित करता है और उन्हें फ़ॉर्म हैंडलर या API नियंत्रक को भेजता है।

IETF RFC 7578 के अनुसार, multipart/form-data को प्रत्येक भाग के लिए charset निर्दिष्ट करने की आवश्यकता नहीं है, क्योंकि टेक्स्ट फ़ील्ड UTF-8 में मानी जाती हैं, और बाइनरी भागों में फ़ाइलें उनके मूल एन्कोडिंग में होती हैं। एक भाग का आकार प्रोटोकॉल द्वारा सीमित नहीं है — सीमाएँ सर्वर स्तर पर निर्धारित की जाती हैं: उदाहरण के लिए, Nginx में client_max_body_size के माध्यम से, Spring Boot में spring.servlet.multipart.max-file-size के माध्यम से।

Boundary प्रारूप और इसकी उत्पत्ति

Boundary एक अद्वितीय स्ट्रिंग है जो प्रेषित डेटा में नहीं आनी चाहिए। यह आमतौर पर एक उपसर्ग (जैसे ----WebKitFormBoundary या ----Boundary) से शुरू होती है और इसमें यादृच्छिक वर्ण होते हैं। ब्राउज़र और HTTP क्लाइंट स्वचालित रूप से boundary उत्पन्न करते हैं। RFC 2046 के अनुसार boundary की लंबाई 70 वर्णों से अधिक नहीं होनी चाहिए। प्रत्येक भाग स्ट्रिंग --boundary\r\n द्वारा अलग किया जाता है, और अनुरोध का अंत स्ट्रिंग --boundary--\r\n द्वारा चिह्नित किया जाता है।

Multipart अनुरोध की संरचना

एक मल्टीपार्ट अनुरोध की MIME और HTTP मानकों द्वारा परिभाषित सख्त संरचना होती है। अनुरोध हेडर boundary पैरामीटर के साथ Content-Type: multipart/form-data सेट करता है। अनुरोध मुख्य भाग भागों के अनुक्रम से बना होता है, प्रत्येक में अपने स्वयं के हेडर और मुख्य भाग होते हैं। भाग हेडर में Content-Disposition (अनिवार्य) और Content-Type (वैकल्पिक — फ़ाइलों के लिए) शामिल हैं। भाग हेडर और उसके डेटा के बीच एक खाली पंक्ति अनिवार्य है।

मल्टीपार्ट अनुरोध का उदाहरण

एक टेक्स्ट फ़ील्ड और एक छवि फ़ाइल भेजने वाले मल्टीपार्ट अनुरोध के वास्तविक उदाहरण पर विचार करें। क्लाइंट एक अद्वितीय boundary के साथ Content-Type हेडर बनाता है। अनुरोध मुख्य भाग में क्रमिक रूप से सभी फ़ॉर्म फ़ील्ड होते हैं। प्राप्त होने पर, सर्वर इन भागों को पार्स करता है और डेवलपर को प्रत्येक फ़ील्ड तक एक अलग ऑब्जेक्ट के रूप में पहुँच प्रदान करता है। यह दृष्टिकोण एक ही HTTP कॉल में फ़ाइलों के साथ जटिल फ़ॉर्म को संसाधित करने की अनुमति देता है।

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("अपलोड किया गया: ${response.isSuccessful}")
    }
}

सर्वर पर मल्टीपार्ट प्रतिक्रिया को पार्स करना

सर्वर साइड पर, मल्टीपार्ट अनुरोध फ्रेमवर्क या मैन्युअल रूप से पार्स किया जाता है। Spring Boot में, @RequestParam("avatar") MultipartFile file एनोटेशन पर्याप्त है, और फ्रेमवर्क स्वचालित रूप से मल्टीपार्ट अनुरोध से फ़ाइल निकालता है। Kotlin पर Ktor में receiveMultipart() का उपयोग किया जाता है, Express.js में — multer मिडलवेयर। सर्वर को प्रत्येक फ़ॉर्म फ़ील्ड और प्रत्येक अपलोड की गई फ़ाइल तक स्वतंत्र रूप से पहुँच मिलती है, फ़ाइल को डिस्क या क्लाउड स्टोरेज में सहेजता है और क्लाइंट को URL या पहचानकर्ता लौटाता है।

बहु-घटक अपलोड के लाभ

Multipart Upload डेटा स्थानांतरण के वैकल्पिक तरीकों की तुलना में कई प्रमुख लाभ प्रदान करता है। कई के बजाय एक अनुरोध — सभी फ़ॉर्म फ़ील्ड और फ़ाइलें एक ही HTTP कॉल में प्रेषित होती हैं, जिससे नेटवर्क और सर्वर लोड कम होता है। N फ़ाइलें अपलोड करने के लिए N कनेक्शन खोलने की आवश्यकता नहीं है — सब कुछ एक POST में पैक किया जाता है। यह विशेष रूप से मोबाइल अनुप्रयोगों के लिए महत्वपूर्ण है, जहाँ प्रत्येक HTTP कनेक्शन का अर्थ विलंबता और बैटरी खपत है।

बिना एन्कोडिंग के बाइनरी स्थानांतरण — application/x-www-form-urlencoded के विपरीत, जहाँ बाइनरी डेटा base64 में एन्कोड किया जाता है (आकार में 33% की वृद्धि), multipart/form-data फ़ाइलों को उनके मूल बाइनरी रूप में स्थानांतरित करता है। यह आकार और गति में अधिक कुशल है। 10 MB से अधिक की बड़ी फ़ाइलों के लिए, अंतर महत्वपूर्ण हो जाता है: एक मल्टीपार्ट अनुरोध उसी फ़ाइल के साथ URL-एन्कोडेड अनुरोध से 30% छोटा होगा।

मनमानी संरचना — मल्टीपार्ट विभिन्न प्रकार के फ़ील्ड को किसी भी क्रम में संयोजित करने की अनुमति देता है। एक फ़ॉर्म में एक साथ टेक्स्ट फ़ील्ड, कई फ़ाइलें, JSON डेटा और छिपे हुए फ़ील्ड हो सकते हैं। प्रत्येक भाग का अपना Content-Type होता है, जो टेक्स्ट और बाइनरी डेटा को मिश्रित करने की अनुमति देता है। तुलना के लिए: base64 एन्कोडिंग आकार में 33% जोड़ता है, जबकि मल्टीपार्ट सेवा हेडर के लिए केवल लगभग 5-15% जोड़ता है।

मल्टीपार्ट की अन्य स्थानांतरण प्रारूपों से तुलना

HTTP Archive, 2025 के शोध के अनुसार, वेब पर 94% फ़ाइल अपलोड मामलों में multipart/form-data का उपयोग किया जाता है। विकल्प — JSON में base64 (4%) और WebSocket के माध्यम से प्रत्यक्ष स्थानांतरण (2%)। JSON के साथ base64 API के लिए सुविधाजनक है जहाँ अन्य सभी डेटा भी JSON में है, लेकिन बड़ी फ़ाइलों के लिए अकुशल है। WebSocket वास्तविक समय के डेटा के लिए उपयुक्त है लेकिन सभी HTTP बुनियादी ढाँचे द्वारा समर्थित नहीं है। मल्टीपार्ट अपनी सरलता और दक्षता के कारण फ़ाइल अपलोड के लिए मानक बना हुआ है।

मोबाइल डेवलपमेंट में Multipart Upload

मोबाइल अनुप्रयोगों में, Multipart Upload का उपयोग उपयोगकर्ताओं के उपकरणों से मीडिया सामग्री भेजने के लिए किया जाता है: गैलरी से फ़ोटो, कैमरा शॉट्स, वॉइस रिकॉर्डिंग, दस्तावेज़ फ़ाइलें। Android पर, मानक दृष्टिकोण MultipartBody.Builder के साथ OkHttp है, जो मल्टीपार्ट अनुरोध बनाना आसान बनाता है। Retrofit भी @Multipart और @Part एनोटेशन के माध्यम से मल्टीपार्ट का समर्थन करता है। डेवलपर प्रत्येक भाग के लिए डेटा प्रकार निर्दिष्ट करता है, HTTP क्लाइंट स्वचालित रूप से सही हेडर उत्पन्न करता है।

iOS पर, वही कार्य URLSession के साथ कस्टम HTTPBodyStream के साथ या Alamofire के साथ multipartFormData के माध्यम से हल किए जाते हैं। Alamofire मल्टीपार्ट अनुरोध भेजने के लिए एक सुविधाजनक upload(multipartFormData:) विधि प्रदान करता है। दोनों प्लेटफ़ॉर्म पर अपलोड की गई फ़ाइलों के आकार पर विचार करना महत्वपूर्ण है — बड़ी फ़ाइलों (10-20 MB से अधिक) के लिए, पृष्ठभूमि अपलोड का उपयोग करने की अनुशंसा की जाती है ताकि छोटा करने पर एप्लिकेशन समाप्त न हो। Android पर, यह DownloadManager या WorkManager के माध्यम से किया जाता है, iOS पर — पृष्ठभूमि कॉन्फ़िगरेशन के साथ URLSession के माध्यम से।

मोबाइल अनुप्रयोगों में फ़ाइलें अपलोड करते समय, नेटवर्क स्थिति पर विचार किया जाना चाहिए। Connectivity Manager Android पर यह निर्धारित करने में मदद करता है कि Wi-Fi या मोबाइल डेटा उपलब्ध है या नहीं और अपलोड के लिए इष्टतम समय चुनता है। वीडियो जैसी बड़ी फ़ाइलों के लिए, उपयोगकर्ता के मोबाइल डेटा का उपभोग न करने के लिए Wi-Fi से कनेक्ट होने तक अपलोड स्थगित करने की अनुशंसा की जाती है। Android पर WorkManager NetworkType.UNMETERED के माध्यम से ऐसी बाधाएँ निर्धारित करने की अनुमति देता है।

अपलोड अनुकूलन: संपीड़न और आकार परिवर्तन

Multipart Upload के माध्यम से फ़ाइल भेजने से पहले, मोबाइल एप्लिकेशन अक्सर छवि को संपीड़ित और आकार बदलते हैं। JPEG संपीड़न 85% गुणवत्ता के साथ फ़ाइल आकार को स्क्रीन पर देखने के लिए ध्यान देने योग्य गुणवत्ता हानि के बिना 3-5 गुना कम कर देता है। छवि को लंबी भुजा पर 1920px तक आकार बदलने से आकार और कम हो जाता है। Android पर, इसके लिए Bitmap.compress() का उपयोग किया जाता है, iOS पर — 0.85 के संपीड़न पैरामीटर के साथ UIImageJPEGRepresentation। ऐसा अनुकूलन अपलोड को गति देता है और मोबाइल डेटा बचाता है।

Multipart Upload की त्रुटियाँ और सीमाएँ

Multipart Upload में सबसे आम त्रुटि सर्वर पर अनुरोध आकार सीमा से अधिक होना है। डिफ़ॉल्ट रूप से, Nginx अनुरोध मुख्य भाग के आकार को 1 MB (client_max_body_size) और Tomcat को 2 MB (maxSwallowSize) तक सीमित करता है। यदि डेवलपर इन सीमाओं को नहीं बढ़ाता है, तो सर्वर 413 Request Entity Too Large त्रुटि लौटाएगा। समाधान सर्वर पर अधिकतम अपलोड आकार स्पष्ट रूप से कॉन्फ़िगर करना और क्लाइंट पर चेतावनी दिखाना है यदि फ़ाइल अनुमत आकार से अधिक है।

दूसरी समस्या बॉडी स्ट्रीमिंग के दौरान मल्टीपार्ट अनुरोधों का गलत प्रसंस्करण है। कुछ सर्वर पार्स करने से पहले पूरे मल्टीपार्ट अनुरोध को मेमोरी में लोड करने का प्रयास करते हैं, जो बड़ी फ़ाइलों के लिए OutOfMemoryError की ओर ले जाता है। आधुनिक सर्वर (Nginx, Spring Boot, Ktor) स्ट्रीमिंग मल्टीपार्ट पार्सिंग का समर्थन करते हैं, जहाँ प्रत्येक भाग आने पर संसाधित होता है। डेवलपर को यह सुनिश्चित करना चाहिए कि सर्वर मल्टीपार्ट अनुरोधों के स्ट्रीमिंग प्रसंस्करण के लिए कॉन्फ़िगर किया गया है।

समस्याओं की तीसरी श्रेणी बड़ी फ़ाइलें अपलोड करते समय टाइमआउट है। HTTP क्लाइंट में readTimeout और connectTimeout सेटिंग्स होती हैं जो 50-100 MB से अधिक की फ़ाइलों की लंबी अपलोड के दौरान सक्रिय हो सकती हैं। समाधान अपलोड एंडपॉइंट के लिए टाइमआउट बढ़ाना या मल्टीपार्ट के अंदर चंक्ड ट्रांसफर एन्कोडिंग का उपयोग करना है। मोबाइल उपकरणों पर, अपलोड रुकावट को संभालना और कनेक्शन खोने पर फिर से शुरू (resume) करना भी महत्वपूर्ण है।

Multipart Upload सुरक्षा

फ़ाइल अपलोड मल्टीपार्ट के माध्यम से वेब एप्लिकेशन के सबसे कमजोर एंडपॉइंट में से एक है। एक हमलावर image.jpg में नाम बदलकर एक निष्पादन योग्य स्क्रिप्ट अपलोड कर सकता है। सर्वर को अपलोड की गई फ़ाइल के MIME प्रकार की जाँच एक्सटेंशन से नहीं बल्कि सामग्री (मैजिक बाइट्स) से करनी चाहिए, अनुमत प्रकारों को सीमित करना चाहिए और एंटीवायरस से फ़ाइलों को स्कैन करना चाहिए। अपलोड की गई फ़ाइलों को वेब सर्वर के document-root के बाहर संग्रहीत करने और एक्सेस अधिकारों की जाँच के साथ एक अलग नियंत्रक के माध्यम से प्रदान करने की अनुशंसा की जाती है।