ওয়েব ডেভেলপমেন্টে Content-Type: এটি কী, MIME প্রকার এবং এটি কীভাবে কাজ করে

Content-Type কী?

Content-Type হল উপস্থাপনা হেডারের গ্রুপ থেকে একটি HTTP হেডার যা প্রাপককে বার্তার মূল অংশে ডেটার ফরম্যাট জানায়। এটি HTTP অনুরোধ এবং প্রতিক্রিয়ার জন্য বাধ্যতামূলক যাতে মূল অংশ থাকে এবং এটি ছাড়া ক্লায়েন্ট প্রাপ্ত বাইটগুলি সঠিকভাবে ব্যাখ্যা করতে পারে না। Content-Type-এর ভিত্তিতে, ব্রাউজার বা মোবাইল অ্যাপ একটি পার্সার নির্বাচন করে: text/html-এর জন্য HTML ইঞ্জিন চালু করে, image/png-এর জন্য — PNG ডিকোডার, application/json-এর জন্য — JSON পার্সার।

Content-Type মান হল একটি MIME প্রকার — ডেটা ফরম্যাটের জন্য একটি মানক শনাক্তকারী। MIME-এর পূর্ণরূপ Multipurpose Internet Mail Extensions, কারণ এই মানকটি মূলত ইমেল সংযুক্তির জন্য তৈরি করা হয়েছিল। তবে এটি HTTP-এর ভিত্তি হয়ে উঠেছে এবং আজ সর্বত্র ব্যবহৃত হয় — ওয়েব পৃষ্ঠা প্রেরণ থেকে REST API-তে ডেটা আদান-প্রদান পর্যন্ত। প্রতিটি MIME প্রকার দুটি অংশ নিয়ে গঠিত: একটি প্রধান শ্রেণী এবং একটি যোগ্যতাসম্পন্ন উপপ্রকার, স্ল্যাশ দ্বারা বিভক্ত।

charset প্যারামিটার টেক্সট ফরম্যাটের জন্য Content-Type-কে পরিপূরক করে। উদাহরণস্বরূপ, Content-Type: text/html; charset=utf-8 নির্দেশ করে যে UTF-8 এনকোডিংয়ে একটি HTML নথি প্রেরিত হচ্ছে। IETF RFC 7231, বিভাগ 3.1.1.5 অনুযায়ী, Content-Type হেডার HTTP বার্তাগুলির জন্য বাধ্যতামূলক যাতে মূল অংশ থাকে এবং এর অনুপস্থিতি application/octet-stream হিসেবে গণ্য হয় বা MIME sniffing-এর দিকে নিয়ে যায়।

HTTP-তে MIME প্রকারের ইতিহাস

HTTP/0.9 প্রোটোকল, যা 1991 সালে প্রকাশিত হয়েছিল, শুধুমাত্র HTML পৃষ্ঠা প্রেরণ করত, তাই ডেটার প্রকার ডিফল্টভাবে ধরা হত। RFC 1945-এ HTTP/1.0-এর আবির্ভাবের সাথে, ডেভেলপাররা ছবি, স্টাইলশিট এবং স্ক্রিপ্ট প্রেরণের প্রয়োজনীয়তা উপলব্ধি করেছিলেন। তারা ইমেল প্রোটোকল থেকে MIME মানক অভিযোজিত করেছিল এবং Content-Type HTTP-এর একটি অবিচ্ছেদ্য অংশ হয়ে ওঠে। তারপর থেকে, IANA রেজিস্ট্রি শত শত মান পর্যন্ত প্রসারিত হয়েছে — পরিচিত text/html থেকে আধুনিক image/avif এবং application/manifest+json পর্যন্ত।

নিরাপত্তায় Content-Type-এর ভূমিকা

Content-Type আক্রমণ থেকে সুরক্ষায় একটি গুরুত্বপূর্ণ ভূমিকা পালন করে। যদি সার্ভার text/plain MIME প্রকারসহ একটি HTML ফাইল পাঠায়, ব্রাউজার JavaScript নির্বাহ করবে না বা DOM তৈরি করবে না — এটি XSS আক্রমণ প্রতিরোধ করে। X-Content-Type-Options: nosniff হেডার, যা OWASP দ্বারা সুপারিশকৃত, ব্রাউজারকে সম্পূর্ণরূপে বিষয়বস্তুর ভিত্তিতে MIME প্রকার অনুমান করতে নিষেধ করে। PortSwigger Research অনুযায়ী, MIME sniffing আক্রমণ বিশেষ করে Internet Explorer 6-9-এ প্রচলিত ছিল, যেখানে ব্রাউজার Content-Type উপেক্ষা করত এবং ফাইলের প্রথম বাইট থেকে প্রকার নির্ধারণ করত।

MIME প্রকারের গঠন

MIME প্রকার type/subtype ফরম্যাটে নির্দিষ্ট করা হয়, যেখানে type ডেটার সাধারণ শ্রেণী এবং subtype তার মধ্যে নির্দিষ্ট ফরম্যাট। উদাহরণস্বরূপ, image/png-এ, শ্রেণী image একটি ছবি নির্দেশ করে এবং উপপ্রকার png Portable Network Graphics ফরম্যাট নির্দিষ্ট করে। মাত্র কয়েকটি শ্রেণী রয়েছে: text, image, audio, video, application, multipart এবং message। বাকি বৈচিত্র্য উপপ্রকার থেকে আসে, যার সংখ্যা শত শত।

অতিরিক্ত প্যারামিটার উপপ্রকারের পরে সেমিকোলনের মাধ্যমে প্রেরণ করা হয়। সবচেয়ে সাধারণ প্যারামিটার হল এনকোডিং নির্দিষ্ট করার জন্য charset। Content-Type: application/json; charset=utf-8 নির্দেশ করে যে UTF-8 এনকোডিংয়ে একটি JSON নথি প্রেরিত হচ্ছে। আনুষ্ঠানিকভাবে, application/json-এর জন্য charset অপ্রয়োজনীয় কারণ RFC 8259 অনুসারে JSON সর্বদা UTF-8-এ থাকে, তবে স্পষ্ট নির্দিষ্টকরণ পুরনো HTTP ক্লায়েন্টের সাথে সামঞ্জস্যতা উন্নত করে।

মানক এবং অ-মানক MIME প্রকার

মানক MIME প্রকার IANA রেজিস্ট্রিতে নিবন্ধিত এবং একটি প্রধান শ্রেণীর উপসর্গ থাকে। অ-মানক (বিক্রেতা-নির্দিষ্ট) প্রকার x- উপসর্গ বা vnd.company.type ফরম্যাট ব্যবহার করে — উদাহরণস্বরূপ, Google-এর KML ফরম্যাটের জন্য application/vnd.google-earth.kml+xml। ব্রাউজার অ-মানক প্রকার চিনতে নাও পারে, তাই অজানা সংযুক্তির জন্য application/octet-stream ব্যবহৃত হয় — একটি সর্বজনীন বাইনারি স্ট্রিম যা ব্রাউজার প্রদর্শনের চেষ্টা করে না বরং ফাইল হিসেবে ডাউনলোড করার প্রস্তাব দেয়।

অনুশীলনে charset প্যারামিটার

charset প্যারামিটার সঠিক টেক্সট প্রদর্শনের জন্য গুরুত্বপূর্ণ। এটি ছাড়া, ব্রাউজার অক্ষর ভুলভাবে ব্যাখ্যা করতে পারে, যা mojibake-এর দিকে নিয়ে যায়। ওয়েবের জন্য মানক হল UTF-8, তবে পশ্চিম ইউরোপীয় ভাষার জন্য ISO-8859-1 (Latin-1) এবং পুরনো সাইটে সিরিলিকের জন্য windows-1251-ও পাওয়া যায়। W3C সুপারিশ হল text/html এবং text/plain-এর জন্য সর্বদা charset=utf-8 নির্দিষ্ট করা, যখন application/json-এর জন্য charset প্রয়োজন নেই।

সাধারণ Content-Type প্রকার

অনুশীলনে, ওয়েব ডেভেলপার এবং মোবাইল ডেভেলপার MIME প্রকারের একটি সীমিত সেট নিয়ে কাজ করেন। এই প্রকারগুলি জানা সার্ভার সঠিকভাবে কনফিগার করার, HTTP ক্লায়েন্ট লেখার এবং স্থির ফাইল পরিচালনার জন্য অপরিহার্য। text/html ওয়েব পৃষ্ঠার জন্য প্রধান প্রকার, যা Apache এবং Nginx সার্ভার HTML ফাইলের জন্য ডিফল্টভাবে ফেরত দেয়। application/xhtml+xml কম ব্যবহৃত হয় এবং শুধুমাত্র XHTML নথির জন্য।

application/json REST API-র জন্য মানক হয়ে উঠেছে। সার্ভার এই MIME প্রকারসহ JSON ডেটা ফেরত দেয় এবং ক্লায়েন্ট এটি POST এবং PUT অনুরোধে পাঠায়। text/javascript (অপ্রচলিত) এবং application/javascript JavaScript ফাইলের জন্য ব্যবহৃত হয়। W3Techs Survey, 2025 অনুযায়ী, JSON ওয়েবে সবচেয়ে দ্রুত বর্ধনশীল ডেটা ফরম্যাট, যা 2018 সালে XML-কে ছাড়িয়ে গেছে। SOAP পরিষেবার জন্য, এখনও text/xml বা application/soap+xml ব্যবহৃত হয়।

ছবির জন্য, MIME প্রকার ফাইল ফরম্যাট দ্বারা নির্ধারিত হয়: JPEG-এর জন্য image/jpeg, PNG-এর জন্য image/png, GIF-এর জন্য image/gif, আধুনিক WebP ফরম্যাটের জন্য image/webp। image/svg+xml ভেক্টর গ্রাফিক্সের জন্য ব্যবহৃত হয় এবং এম্বেডেড স্টাইল এবং স্ক্রিপ্ট সমর্থন করে। video/mp4, audio/mpeg এবং application/pdf অন্যান্য প্রায়শই পাওয়া প্রকার। ওয়েব ফন্টের জন্য font/woff2, font/woff এবং font/ttf ব্যবহৃত হয়।

ফাইল আপলোডে Content-Type

HTML ফর্মের মাধ্যমে ফাইল আপলোড করার সময়, multipart/form-data ব্যবহৃত হয় — একটি যৌগিক MIME প্রকার যা অনুরোধকে একাধিক অংশে বিভক্ত করে। প্রতিটি অংশের নিজস্ব Content-Type হেডার এবং Content-Disposition থাকে যা ফিল্ডের নাম এবং মূল ফাইলের নাম নির্দিষ্ট করে। সার্ভার ব্রাউজার দ্বারা নির্ধারিত প্রকৃত MIME প্রকারসহ ফাইল গ্রহণ করে এবং ব্যাকএন্ড পক্ষে এটি যাচাই করতে পারে। application/octet-stream অজানা প্রকারের ফাইলের জন্য ব্যবহৃত হয় — ব্রাউজার বিষয়বস্তু প্রদর্শনের চেষ্টা করে না বরং ডিস্কে সংরক্ষণের প্রস্তাব দেয়।

ক্যাশিং-এ Content-Type-এর প্রভাব

MIME প্রকার CDN এবং ব্রাউজারের ক্যাশিং নীতি প্রভাবিত করে। স্থিতিশীল URL-যুক্ত ছবি সাধারণত দীর্ঘ সময়ের জন্য (এক বছর বা তার বেশি) ক্যাশ করা হয়, যখন HTML পৃষ্ঠা মিনিট বা সেকেন্ডের জন্য ক্যাশ করা হয়। CDN সার্ভার যেমন Cloudflare এবং Akamai কম্প্রেশন অ্যালগরিদম নির্বাচনের জন্য Content-Type ব্যবহার করে: text/* gzip বা brotli দিয়ে কম্প্রেস করা হয়, image/* করা হয় না, কারণ ছবি ইতিমধ্যে কম্প্রেস করা থাকে। সার্ভারে সঠিক Content-Type কনফিগারেশন সরাসরি ওয়েব পৃষ্ঠা এবং মোবাইল অ্যাপ্লিকেশনের লোডিং কর্মক্ষমতা প্রভাবিত করে।

সার্ভার এবং ক্লায়েন্ট কীভাবে Content-Type ব্যবহার করে

সার্ভার অনুরোধকৃত ফাইলের প্রকার বা গতিশীলভাবে উৎপন্ন বিষয়বস্তুর ভিত্তিতে HTTP প্রতিক্রিয়ায় Content-Type হেডার সেট করে। জনপ্রিয় ওয়েব সার্ভার যেমন Nginx এবং Apache-তে অন্তর্নির্মিত MIME প্রকার সারণী থাকে যা ফাইল এক্সটেনশনকে সংশ্লিষ্ট Content-Type-এর সাথে ম্যাপ করে। উদাহরণস্বরূপ, index.html text/html পায় এবং style.css text/css পায়। গতিশীল প্রতিক্রিয়ার জন্য, ডেভেলপার PHP, Python, Java বা Kotlin-এ অ্যাপ্লিকেশন কোডে Content-Type সেট করে।

ক্লায়েন্ট হ্যান্ডলার নির্বাচনের জন্য Content-Type ব্যবহার করে। যদি সার্ভার text/html ফেরত দেয়, ব্রাউজার HTML পার্সার শুরু করে এবং DOM ট্রি তৈরি করে। যদি image/png — PNG ডিকোডার শুরু করে। যদি Content-Type অনুপস্থিত বা ভুল হয়, ক্লায়েন্ট MIME sniffing প্রয়োগ করে — ফাইলের শুরুতে স্বাক্ষর (ম্যাজিক বাইট) দ্বারা প্রকার অনুমান করার চেষ্টা করে। JPEG বাইট FF D8 FF দিয়ে শুরু হয়, PNG 89 50 4E 47 দিয়ে শুরু হয় এবং PDF 25 50 44 46 দিয়ে শুরু হয়। এই প্রক্রিয়া সম্ভাব্য বিপজ্জনক এবং X-Content-Type-Options: nosniff হেডার দ্বারা নিষ্ক্রিয় করা হয়।

মোবাইল অ্যাপ্লিকেশনে, Content-Type HTTP ক্লায়েন্ট দ্বারা পরিচালিত হয়। অ্যান্ড্রয়েডে OkHttp স্বয়ংক্রিয়ভাবে প্রতিক্রিয়া থেকে Content-Type হেডার পার্স করে এবং Response.header("Content-Type") পদ্ধতির মাধ্যমে সরবরাহ করে। iOS URLSession ক্লায়েন্ট URLResponse.mimeType বৈশিষ্ট্যের মাধ্যমে একই কাজ করে। উভয় প্ল্যাটফর্মে, Content-Type পার্সার নির্বাচনের জন্য ব্যবহৃত হয়: JSON — অ্যান্ড্রয়েডে Moshi বা Gson-এর মাধ্যমে, iOS-এ Codable-এর মাধ্যমে; ছবি — Glide, Coil বা SDWebImage-এর মাধ্যমে।

Accept এবং Content-Type-এর মাধ্যমে বিষয়বস্তু আলোচনা

বিষয়বস্তু আলোচনা একটি HTTP প্রক্রিয়া যেখানে ক্লায়েন্ট Accept হেডারের মাধ্যমে পছন্দসই প্রতিক্রিয়া ফরম্যাট নির্দিষ্ট করে এবং সার্ভার উপযুক্ত ফরম্যাট নির্বাচন করে সংশ্লিষ্ট Content-Type-সহ ফেরত দেয়। উদাহরণস্বরূপ, ক্লায়েন্ট Accept: application/json পাঠায়, সার্ভার Content-Type: application/json-সহ প্রতিক্রিয়া জানায়। যদি সার্ভার অনুরোধকৃত ফরম্যাট সরবরাহ করতে না পারে, এটি 406 Not Acceptable ফেরত দেয়। REST API-তে, এই প্রক্রিয়া একটি একক এন্ডপয়েন্টকে JSON, XML বা HTML-এ ডেটা ফেরত দিতে অনুমতি দেয়।

অনুরোধ এবং প্রতিক্রিয়ায় Content-Type

Content-Type হেডার HTTP অনুরোধ এবং HTTP প্রতিক্রিয়া উভয় ক্ষেত্রেই ব্যবহৃত হয়। অনুরোধে, এটি অনুরোধের মূল অংশের ফরম্যাট নির্দিষ্ট করে, উদাহরণস্বরূপ POST-এর মাধ্যমে JSON পাঠানোর সময়। প্রতিক্রিয়ায়, এটি ফেরত দেওয়া ডেটার ফরম্যাট নির্দিষ্ট করে। মূল পার্থক্য হল যে অনুরোধের Content-Type ক্লায়েন্ট দ্বারা সেট করা হয়, যখন প্রতিক্রিয়ার Content-Type সার্ভার দ্বারা সেট করা হয়। অনুরোধে Content-Type ভুলভাবে সেট করা সার্ভারকে মূল অংশ পার্স করতে অক্ষম করে, যা 400 Bad Request বা 415 Unsupported Media Type ত্রুটি ফেরত দেয়।

HTTP অনুরোধে, Content-Type POST, PUT এবং PATCH পদ্ধতির জন্য বাধ্যতামূলক যদি অনুরোধে মূল অংশ থাকে। GET, HEAD এবং DELETE সাধারণত মূল অংশ ব্যবহার করে না, তাই তাদের জন্য Content-Type নির্দিষ্ট করা হয় না বা উপেক্ষা করা হয়। enctype="multipart/form-data" বৈশিষ্ট্যসহ HTML ফর্ম জমা দেওয়ার সময়, ব্রাউজার স্বয়ংক্রিয়ভাবে Content-Type: multipart/form-data একটি অনন্য সীমানা স্ট্রিং-সহ সেট করে যা যৌগিক অনুরোধের অংশগুলি পৃথক করে। প্রতিটি অংশ --boundary দ্বারা পৃথক করা হয় এবং অনুরোধের শেষ --boundary-- দ্বারা চিহ্নিত করা হয়।

HTTP প্রতিক্রিয়ায়, Content-Type সার্ভার দ্বারা সেট করা হয়। যদি সার্ভার Content-Type নির্দিষ্ট না করে, ক্লায়েন্ট হয় MIME sniffing সক্রিয় করে বা প্রতিক্রিয়াকে application/octet-stream হিসেবে প্রক্রিয়া করে। HTTP HEAD পদ্ধতি মূল অংশ প্রেরণ ছাড়াই Content-Type-সহ প্রতিক্রিয়া হেডার প্রাপ্তির অনুমতি দেয়। এটি সম্পূর্ণরূপে লোড করার আগে সম্পদের প্রকার পরীক্ষা করার জন্য দরকারী। CDN সার্ভার বিষয়বস্তু রূপান্তর করার সময় Content-Type ওভাররাইড করতে পারে — উদাহরণস্বরূপ, ছবি WebP-তে রূপান্তর করার সময়।

import okhttp3.*

fun checkContentType() {
    val client = OkHttpClient()
    val request = Request.Builder()
        .url("https://api.example.com/resource")
        .head()
        .build()

    client.newCall(request).execute().use { response ->
        val contentType = response.header("Content-Type")
        val mediaType = MediaType.parse(contentType)
        println("প্রকার: ${mediaType?.type}, উপপ্রকার: ${mediaType?.subtype}")
    }
}

মোবাইল HTTP ক্লায়েন্টে Content-Type

মোবাইল ডেভেলপমেন্টে, Content-Type হেডার HTTP ক্লায়েন্ট দ্বারা স্বয়ংক্রিয়ভাবে পরিচালিত হয়। অ্যান্ড্রয়েডে OkHttp-তে, Content-Type RequestBody-এর মাধ্যমে সেট করা হয়: val body = "{}".toRequestBody("application/json".toMediaType())। Retrofit অ্যানোটেশনের মাধ্যমে Content-Type পরিচালনা করে: JSON-এর জন্য @Body, মাল্টিপার্টের জন্য @Part। iOS-এ, URLSession HTTPBody-র জন্য Content-Type সেট করে এবং Alamofire এটি encoding প্যারামিটারের মাধ্যমে করে: JSONEncoding.default বা URLEncoding.default। ম্যানুয়াল Content-Type সেটিং raw সকেট বা কাস্টম প্রোটোকলের সাথে কাজ করার সময় প্রয়োজন।

Content-Type ত্রুটি

ভুল Content-Type ওয়েব পরিষেবা উন্নয়ন এবং একীকরণের সবচেয়ে সাধারণ সমস্যাগুলির মধ্যে একটি। সবচেয়ে ঘন ঘন ত্রুটি হল যখন সার্ভার application/json-এর পরিবর্তে text/html ফেরত দেয়। ক্লায়েন্ট JSON-কে HTML স্ট্রিং হিসেবে গ্রহণ করে, এটি পার্স করতে পারে না এবং একটি ব্যতিক্রম নিক্ষেপ করে। এটি ঘটে যখন ওয়েব ফ্রেমওয়ার্ক ডিফল্টভাবে HTML-এর জন্য কনফিগার করা থাকে এবং ডেভেলপার API এন্ডপয়েন্টের জন্য Content-Type ওভাররাইড করতে ভুলে যায়। PHP-তে এটি header('Content-Type: application/json') অনুপস্থিত থাকলে প্রকাশ পায়, Spring Boot-এ — produces অ্যানোটেশন অনুপস্থিত থাকলে।

দ্বিতীয় সবচেয়ে সাধারণ ত্রুটি হল ভুল বা অনুপস্থিত charset। যদি সার্ভার text/html; charset=iso-8859-1 পাঠায় এবং ব্রাউজার UTF-8 আশা করে, সিরিলিক অক্ষর mojibake হিসেবে প্রদর্শিত হয়। এই সমস্যাটি পুরনো সাইটের জন্য সাধারণ যা UTF-8-তে স্থানান্তরিত হয়নি। JSON-এর জন্য, এই ত্রুটি কম সাধারণ কারণ RFC 8259 অতিরিক্ত আলোচনা ছাড়াই UTF-8 নির্ধারণ করে। সমাধান হল সার্ভার কনফিগারেশনে টেক্সট MIME প্রকারের জন্য সর্বদা স্পষ্টভাবে charset=utf-8 নির্দিষ্ট করা।

তৃতীয় সমস্যা হল প্রকৃত বিষয়বস্তুর সাথে Content-Type-এর অমিল। যদি সার্ভার Content-Type: image/png পাঠায় কিন্তু প্রতিক্রিয়ার মূল অংশে WebP ছবি থাকে, ব্রাউজার এটি ডিকোড নাও করতে পারে। CDN সার্ভার কখনও কখনও ফরম্যাট পরিবর্তনের সাথে ছবি সংকুচিত করে কিন্তু Content-Type হেডার আপডেট করে না। প্রকৃত বিষয়বস্তুর সাথে Content-Type-এর সামঞ্জস্য পরীক্ষা করা API পরীক্ষা এবং মোবাইল অ্যাপ্লিকেশনের ইন্টিগ্রেশন পরীক্ষার একটি বাধ্যতামূলক পদক্ষেপ।

Content-Type ত্রুটি নির্ণয় এবং সংশোধন

ডিবাগিংয়ের জন্য, ব্রাউজার ডেভেলপার টুল (Network ট্যাব), প্রতিক্রিয়া হেডার পরীক্ষার জন্য -I ফ্ল্যাগ-সহ curl, বা Charles Proxy এবং Wireshark-এর মতো ট্রাফিক স্নিফার ব্যবহার করুন। Nginx include mime.types নির্দেশের মাধ্যমে কনফিগার করা হয়, Apache — AddType এবং AddDefaultCharset-এর মাধ্যমে। স্থির ফাইলের জন্য, সর্বদা পরীক্ষা করুন যে ফাইল এক্সটেনশন তার MIME প্রকারের সাথে মেলে। সমস্ত প্রোগ্রামিং ভাষায় গতিশীল প্রতিক্রিয়ার জন্য, ডেটা আউটপুটের আগে স্পষ্টভাবে Content-Type সেট করুন — এটি অধিকাংশ সমস্যা প্রতিরোধ করে।