ওয়েব ডেভেলপমেন্টে Multipart Upload: সার, গঠন এবং multipart/form-data কিভাবে কাজ করে

Multipart Upload কী?

Multipart Upload হল HTTP প্রোটোকলের মাধ্যমে ডেটা স্থানান্তরের একটি পদ্ধতি যেখানে অনুরোধের বডি বেশ কয়েকটি যৌক্তিকভাবে পৃথক অংশ নিয়ে গঠিত। প্রতিটি অংশে বিভিন্ন ধরণের ডেটা থাকতে পারে: একটি টেক্সট ফর্ম ফিল্ড, একটি বাইনারি ফাইল, একটি JSON অবজেক্ট বা একটি ইমেজ। সমস্ত অংশ একটি একক POST অনুরোধে প্যাকেজ করা হয়, যা Nটি পৃথক HTTP কল পাঠানোর প্রয়োজনীয়তা দূর করে। Multipart Upload ওয়েব ফর্ম এবং ফাইল আপলোড API-এর একটি অপরিহার্য অংশ।

মাল্টিপার্ট ফরম্যাটটি ইমেল বার্তাগুলির জন্য MIME মানকের অংশ হিসাবে RFC 2046 স্পেসিফিকেশনে সংজ্ঞায়িত করা হয়েছিল এবং পরে 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-এর বাইরে সংরক্ষণ করার এবং অ্যাক্সেস অধিকার যাচাই সহ একটি পৃথক নিয়ন্ত্রকের মাধ্যমে সেগুলি পরিবেশন করার পরামর্শ দেওয়া হয়।