Veb ishlab chiqishda Content-Type: bu nima, MIME turlari va qanday ishlaydi

Content-Type nima?

Content-Type — bu representation headers guruhiga kiruvchi, qabul qiluvchiga xabar tanasidagi ma'lumotlar formati haqida xabar beruvchi HTTP sarlavhasidir. Tanasi (body) bo'lgan HTTP so'rov va javoblari uchun majburiydir va usiz mijoz olingan baytlarni to'g'ri talqin qila olmaydi. Brauzer yoki mobil ilova Content-Type asosida parserni tanlaydi: text/html uchun HTML mexanizmini, image/png uchun PNG dekoderini, application/json uchun JSON parserini ishga tushiradi.

Content-Type qiymati MIME turidir — standartlashtirilgan ma'lumot formati identifikatori. MIME qisqartmasi Multipurpose Internet Mail Extensions ma'nosini anglatadi, chunki bu standart dastlab e-poçta ilovalari uchun yaratilgan edi. Biroq u HTTP ning asosiga aylandi va bugun hamma joyda qo'llaniladi — veb sahifalarni uzatishdan tortib REST API da ma'lumot almashinuvigacha. Har bir MIME turi ikki qismdan iborat: asosiy kategoriya va aniqroq pastki tur, qiyshiq chiziq bilan ajratiladi.

Charset parametri matnli formatlar uchun Content-Type ni to'ldiradi. Masalan, Content-Type: text/html; charset=utf-8 UTF-8 kodlashidagi HTML hujjati uzatilayotganini anglatadi. IETF RFC 7231, 3.1.1.5 bo'limiga ko'ra, Content-Type sarlavhasi tanasi bo'lgan HTTP xabarlari uchun majburiydir va uning yo'qligi application/octet-stream deb talqin qilinadi yoki MIME sniffing ga olib keladi.

MIME turlarining HTTP da paydo bo'lish tarixi

1991 yilda chiqarilgan HTTP/0.9 protokoli faqat HTML sahifalarini uzatar edi, shuning uchun ma'lumot turi standart sifatida belgilangan edi. RFC 1945 spetsifikatsiyasida HTTP/1.0 ning paydo bo'lishi bilan dasturchilar rasmlar, uslublar jadvallari va skriptlarni uzatish zaruriyatini angladilar. Ular elektron pochta protokolidan MIME standartini moslashtirdilar va Content-Type HTTP ning ajralmas qismiga aylandi. O'shandan beri IANA reestri yuzlab qiymatlargacha kengaydi — tanish text/html dan zamonaviy image/avif va application/manifest+json gacha.

Xavfsizlikda Content-Type ning roli

Content-Type hujumlardan himoya qilishda muhim rol o'ynaydi. Agar server HTML faylni text/plain MIME turi bilan yuborsa, brauzer JavaScript ni bajarmaydi va DOM qurmaydi — bu XSS hujumlarining oldini oladi. OWASP tomonidan tavsiya etilgan X-Content-Type-Options: nosniff sarlavhasi brauzerga mazmun asosida MIME turini taxmin qilishni butunlay taqiqlaydi. PortSwigger Research ma'lumotlariga ko'ra, MIME sniffing dan foydalanadigan hujumlar ayniqsa Internet Explorer 6-9 da keng tarqalgan edi, bunda brauzer Content-Type ni e'tiborsiz qoldirib, turni faylning birinchi baytlari bo'yicha aniqlar edi.

MIME turining tuzilishi

MIME turi type/subtype formatida ko'rsatiladi, bu type ma'lumotlarning umumiy kategoriyasi, subtype esa uning ichidagi aniq formatdir. Masalan, image/png qiymatida image kategoriyasi rasmni, png pastki turi Portable Network Graphics formatini ko'rsatadi. Kategoriyalar bir nechta: text, image, audio, video, application, multipart va message. Qolgan xilma-xillik yuzlab sonli pastki turlar tomonidan ta'minlanadi.

Qo'shimcha parametrlar pastki turdan keyin nuqtali vergul orqali uzatiladi. Eng keng tarqalgan parametr kodlashni ko'rsatish uchun charset dir. Content-Type: application/json; charset=utf-8 UTF-8 kodlashidagi JSON hujjati uzatilayotganini bildiradi. Rasmiy ravishda application/json uchun charset kerak emas, chunki JSON har doim RFC 8259 spetsifikatsiyasiga ko'ra UTF-8 da bo'ladi, ammo aniq ko'rsatish eski HTTP mijozlari bilan moslikni yaxshilaydi.

Standart va nostandart MIME turlari

Standart MIME turlari IANA reestrida ro'yxatdan o'tkaziladi va asosiy kategoriya prefiksiga ega. Nostandart (vendor-specific) turlari x- prefiksidan yoki vnd.company.type formatidan foydalanadi — masalan, Google dan KML formati uchun application/vnd.google-earth.kml+xml. Brauzerlar nostandart turlarni tanimasligi mumkin, shuning uchun noma'lum ilovalar uchun application/octet-stream ishlatiladi — brauzer uni ko'rsatishga urinmay, fayl sifatida yuklab olishni taklif qiladigan universal ikkilik oqim.

Amalda charset parametri

Charset parametri matnni to'g'ri ko'rsatish uchun juda muhimdir. Usiz brauzer belgilarni noto'g'ri talqin qilishi mumkin, bu mojibake ga (buzuq belgilar) olib keladi. Veb uchun standart UTF-8 dir, ammo ISO-8859-1 (Latin-1) G'arbiy Yevropa tillari uchun va windows-1251 eski saytlarda kirill uchun ham uchraydi. W3C tavsiyasi — text/html va text/plain uchun har doim charset=utf-8 ni ko'rsating, application/json uchun charset talab qilinmaydi.

Content-Type ning asosiy turlari

Amalda veb dasturchilar va mobil dasturchilar cheklangan MIME turlari to'plami bilan ishlaydilar. Bu turlarni bilish serverni to'g'ri sozlash, HTTP mijozlarini yozish va statik fayllarni qayta ishlash uchun zarurdir. text/html — Apache va Nginx serverlari tomonidan HTML fayllari uchun standart sifatida qaytariladigan veb sahifalar uchun asosiy tur. application/xhtml+xml kamroq ishlatiladi va faqat XHTML hujjatlari uchun.

application/json REST API uchun standartga aylandi. Serverlar JSON ma'lumotlarini ushbu MIME turi bilan qaytaradi, mijozlar esa uni POST va PUT so'rovlarida yuboradi. text/javascript (eskirgan) va application/javascript JavaScript fayllari uchun ishlatiladi. W3Techs Survey, 2025 ma'lumotlariga ko'ra, JSON 2018 yilda XML ni ortda qoldirib, vebdagi eng tez o'sayotgan ma'lumot formatidir. SOAP xizmatlari uchun hali ham text/xml yoki application/soap+xml ishlatiladi.

Rasmlar uchun MIME turi fayl formati bilan aniqlanadi: JPEG uchun image/jpeg, PNG uchun image/png, GIF uchun image/gif, WebP uchun image/webp. image/svg+xml vektor grafika uchun ishlatiladi va ichki uslublar va skriptlarni qo'llab-quvvatlaydi. video/mp4, audio/mpeg va application/pdf boshqa tez-tez uchraydigan turlardir. Veb shriftlar uchun font/woff2, font/woff va font/ttf ishlatiladi.

Fayl yuklashda Content-Type

HTML formasi orqali fayllarni yuborishda multipart/form-data ishlatiladi — so'rovni bir necha qismga bo'luvchi murakkab MIME turi. Har bir qismning o'z Content-Type va maydon nomini va faylning asl nomini ko'rsatadigan Content-Disposition sarlavhasi bor. Server faylni brauzer tomonidan aniqlangan haqiqiy MIME turi bilan oladi va uni backend tomonda tekshirishi mumkin. application/octet-stream noma'lum turdagi fayllar uchun qo'llaniladi — brauzer mazmunni ko'rsatishga urinmaydi, balki diskda saqlashni taklif qiladi.

Content-Type ning keshlashga ta'siri

MIME turi CDN va brauzer keshlash siyosatiga ta'sir qiladi. Barqaror URL larga ega rasmlar odatda uzoq muddatga (bir yil va undan ko'p) keshlanadi, HTML sahifalar esa daqiqalar yoki soniyalar uchun. CDN serverlari Cloudflare va Akamai siqish algoritmini tanlash uchun Content-Type dan foydalanadi: text/* gzip yoki brotli bilan siqiladi, image/* — yo'q, chunki rasmlar allaqachon siqilgan. Serverda Content-Type ni to'g'ri sozlash sahifalar va mobil ilovalarning yuklanish samaradorligiga bevosita ta'sir qiladi.

Server va mijoz Content-Type dan qanday foydalanadi

Server HTTP javobida Content-Type sarlavhasini so'ralgan faylning turi yoki dinamik yaratilgan mazmun asosida o'rnatadi. Mashhur Nginx va Apache veb serverlari fayl kengaytmasini tegishli Content-Type bilan bog'laydigan ichki MIME tur jadvallariga ega. Masalan, index.html fayli text/html, style.css esa text/css oladi. Dinamik javoblar uchun dasturchi PHP, Python, Java yoki Kotlin ilova kodida Content-Type ni o'rnatadi.

Mijoz ishlov beruvchini tanlash uchun Content-Type dan foydalanadi. Agar server text/html qaytarsa, brauzer HTML parserini ishga tushiradi va DOM daraxtini quradi. Agar image/png bo'lsa — PNG dekoderini ishga tushiradi. Agar Content-Type yo'q bo'lsa yoki noto'g'ri ko'rsatilgan bo'lsa, mijoz MIME sniffing ni qo'llaydi — fayl boshidagi imzo (magic bytes) asosida turni taxmin qilishga harakat qiladi. JPEG FF D8 FF baytlari bilan, PNG 89 50 4E 47 bilan, PDF esa 25 50 44 46 bilan boshlanadi. Bu jarayon potentsial xavflidir va X-Content-Type-Options: nosniff sarlavhasi bilan o'chiriladi.

Mobil ilovalarda Content-Type HTTP mijozlari tomonidan qayta ishlanadi. Android da OkHttp javobdan Content-Type sarlavhasini avtomatik tahlil qiladi va uni Response.header("Content-Type") metodi orqali taqdim etadi. iOS mijoz URLSession xuddi shunday URLResponse.mimeType xususiyati orqali amalga oshiradi. Ikkala platformada Content-Type parser tanlash uchun ishlatiladi: JSON — Android da Moshi yoki Gson orqali, iOS da Codable bilan; rasmlar — Glide, Coil yoki SDWebImage orqali.

Accept va Content-Type orqali Content Negotiation

Content negotiation (mazmunni kelishish) — HTTP mexanizmi bo'lib, unda mijoz Accept sarlavhasi orqali kerakli javob formatini ko'rsatadi, server esa mos formatni tanlaydi va uni tegishli Content-Type bilan qaytaradi. Masalan, mijoz Accept: application/json yuboradi, server Content-Type: application/json bilan javob beradi. Agar server so'ralgan formatni taqdim eta olmasa, 406 Not Acceptable qaytaradi. REST API da bu mexanizm bir endpoint ga JSON, XML yoki HTML da ma'lumot qaytarish imkonini beradi.

Content-Type so'rov va javoblarda

Content-Type sarlavhasi ham HTTP so'rovlarida (Request), ham HTTP javoblarida (Response) ishlatiladi. So'rovlarda u so'rov tanasining formatini ko'rsatadi, masalan JSON ni POST orqali yuborishda. Javoblarda — qaytarilgan ma'lumotlarning formatini. Asosiy farq shundaki, so'rovning Content Type ini mijoz, javobning Content Type ini esa server o'rnatadi. So'rovda noto'g'ri Content-Type o'rnatilishi serverning tanani tahlil qila olmasligiga olib keladi, 400 Bad Request yoki 415 Unsupported Media Type xatosi qaytariladi.

HTTP so'rovlarida Content-Type POST, PUT va PATCH metodlari uchun majburiydir, agar so'rov tana (body) o'z ichiga olsa. GET, HEAD va DELETE odatda tanadan foydalanmaydi, shuning uchun Content-Type ular uchun ko'rsatilmaydi yoki e'tiborga olinmaydi. enctype="multipart/form-data" atributiga ega HTML formasini yuborishda brauzer avtomatik ravishda Content-Type: multipart/form-data ni noyob chegara (boundary) qatori bilan o'rnatadi, u murakkab so'rov qismlarini ajratadi. Har bir qism --boundary bilan ajratiladi, so'rovning oxiri esa --boundary-- bilan belgilanadi.

HTTP javoblarida Content-Type server tomonidan o'rnatiladi. Agar server Content-Type ni ko'rsatmasa, mijoz yoki MIME sniffing ni ishga tushiradi, yoki javobni application/octet-stream sifatida qayta ishlaydi. HTTP HEAD metodi tanani uzatmasdan Content Type ni o'z ichiga olgan javob sarlavhalarini olish imkonini beradi. Bu to'liq yuklashdan oldin resurs turini tekshirish uchun foydalidir. CDN serverlari mazmun transformatsiyasi paytida Content Type ni o'zgartirishi mumkin — masalan, rasmlarni WebP ga aylantirishda.

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("Tur: ${mediaType?.type}, Pastki tur: ${mediaType?.subtype}")
    }
}

Mobil HTTP mijozlarida Content-Type

Mobil dasturlashda Content-Type sarlavhasi HTTP mijozlari tomonidan avtomatik qayta ishlanadi. Android da OkHttp da Content-Type RequestBody orqali o'rnatiladi: val body = "{}".toRequestBody("application/json".toMediaType()). Retrofit Content Type ni annotatsiyalar orqali boshqaradi: JSON uchun @Body, multipart uchun @Part. iOS da URLSession HTTPBody uchun Content Type ni o'rnatadi, Alamofire esa buni encoding parametri orqali amalga oshiradi: JSONEncoding.default yoki URLEncoding.default. Content Type ni qo'lda o'rnatish xom soketlar yoki maxsus protokollar bilan ishlashda talab qilinadi.

Content-Type bilan ishlashdagi xatolar

Noto'g'ri Content-Type — veb xizmatlarni ishlab chiqish va integratsiya qilishdagi eng keng tarqalgan muammolardan biridir. Eng keng tarqalgan xato serverning application/json o'rniga text/html qaytarishidir. Mijoz JSON ni HTML qatori sifatida oladi, uni tahlil qila olmaydi va istisno yaratadi. Bu veb freymvork standart sifatida HTML ga sozlanganida va dasturchi API endpointi uchun Content Type ni o'zgartirishni unutganida sodir bo'ladi. PHP da bu header('Content-Type: application/json') yo'qligi, Spring Boot da esa produces annotatsiyasining yo'qligi bilan namoyon bo'ladi.

Ikkinchi eng keng tarqalgan xato — noto'g'ri yoki yo'q charset. Agar server text/html; charset=iso-8859-1 yuborsa va brauzer UTF-8 kutsa, kirill belgilari buzilgan holda ko'rsatiladi. Bu muammo UTF-8 ga o'tmagan eski saytlar uchun xosdir. JSON uchun bunday xato kamroq uchraydi, chunki RFC 8259 qo'shimcha kelishuvsiz UTF-8 ni talab qiladi. Yechim — server konfiguratsiyasida matnli MIME turlari uchun har doim aniq charset=utf-8 ni ko'rsatish.

Uchinchi muammo — Content-Type ning haqiqiy mazmunga mos kelmasligi. Agar server Content-Type: image/png yuborsa, lekin javob tanasida WebP rasmi bo'lsa, brauzer uni dekodlay olmasligi mumkin. CDN serverlari ba'zan formatni o'zgartirib rasmlarni siqadi, ammo Content-Type sarlavhasini yangilamaydi. Content-Type ning haqiqiy mazmunga muvofiqligini tekshirish API testi va mobil ilovalarning integrasion testining majburiy bosqichidir.

Content-Type xatolarini diagnostika qilish va tuzatish

Disk raskadrovka uchun brauzerning ishlab chiquvchi vositalaridan (Network yorlig'i), javob sarlavhalarini tekshirish uchun -I bayrog'i bilan curl dan yoki Charles Proxy va Wireshark kabi trafik snifferlaridan foydalaning. Nginx include mime.types direktivasi orqali, Apache esa AddType va AddDefaultCharset orqali sozlanadi. Statik fayllar uchun har doim fayl kengaytmasining uning MIME turiga mos kelishini tekshiring. Dinamik javoblar uchun barcha dasturlash tillarida ma'lumotni chiqarishdan oldin aniq Content-Type ni o'rnating — bu muammolarning katta qismining oldini oladi.