Veb inkişafında Content-Type: bu nədir, MIME növləri və necə işləyir

Content-Type nədir?

Content-Type — bu, representation headers qrupundan olan, alıcıya mesajın gövdəsindəki məlumatların formatı barədə məlumat verən HTTP başlığıdır. Tərkibində gövdə (body) olan HTTP sorğu və cavabları üçün məcburidir və onsuz müştəri alınan baytları düzgün şərh edə bilməz. Brauzer və ya mobil tətbiq Content-Type əsasında parser seçir: text/html üçün HTML mühərrikini, image/png üçün PNG dekoderini, application/json üçün JSON parserini işə salır.

Content-Type dəyəri MIME növüdür — standartlaşdırılmış məlumat formatı identifikatorudur. MIME açılımı Multipurpose Internet Mail Extensions deməkdir, çünki bu standart əslində e-poçt əlavələri üçün yaradılmışdır. Lakin o, HTTP-nin əsasına çevrildi və bu gün hər yerdə istifadə olunur — veb səhifələrin ötürülməsindən REST API-də məlumat mübadiləsinə qədər. Hər bir MIME növü iki hissədən ibarətdir: əsas kateqoriya və dəqiqləşdirici alt növ, kəsik işarəsi ilə ayrılır.

Charset parametri mətn formatları üçün Content-Type-ı tamamlayır. Məsələn, Content-Type: text/html; charset=utf-8 o deməkdir ki, UTF-8 kodlaşdırmasında HTML sənədi ötürülür. IETF RFC 7231, bölmə 3.1.1.5-ə görə, Content-Type başlığı gövdəsi olan HTTP mesajları üçün məcburidir və onun olmaması application/octet-stream kimi şərh edilir və ya MIME sniffing-ə səbəb olur.

MIME növlərinin HTTP-də meydana gəlmə tarixi

1991-ci ildə buraxılmış HTTP/0.9 protokolu yalnız HTML səhifələri ötürürdü, buna görə məlumat növü standart olaraq təyin edilmişdi. RFC 1945 spesifikasiyasında HTTP/1.0-ın meydana gəlməsi ilə tərtibatçılar şəkilləri, stil vərəqlərini və skriptləri ötürmək zərurətini dərk etdilər. Onlar e-poçt protokolundan MIME standartını uyğunlaşdırdılar və Content-Type HTTP-nin ayrılmaz hissəsinə çevrildi. O vaxtdan bəri IANA reyestri yüzlərlə dəyərə qədər genişləndi — tanınmış text/html-dən müasir image/avif və application/manifest+json-a qədər.

Təhlükəsizlikdə Content-Type-ın rolu

Content-Type hücumlardan qorunmada kritik rol oynayır. Əgər server HTML faylını text/plain MIME növü ilə göndərirsə, brauzer JavaScript-i icra etməyəcək və DOM qurmayacaq — bu, XSS hücumlarının qarşısını alır. OWASP tərəfindən tövsiyə olunan X-Content-Type-Options: nosniff başlığı brauzerə məzmun əsasında MIME növünü təxmin etməyi tamamilə qadağan edir. PortSwigger Research məlumatlarına görə, MIME sniffing istifadə edən hücumlar xüsusilə Internet Explorer 6-9-da geniş yayılmışdı, burada brauzer Content-Type-ı nəzərdən qaçırır və növü faylın ilk baytlarına görə təyin edirdi.

MIME növünün strukturu

MIME növü type/subtype formatında göstərilir, burada type məlumatların ümumi kateqoriyası, subtype isə onun daxilindəki konkret formatdır. Məsələn, image/png dəyərində image kateqoriyası şəkli, png alt növü isə Portable Network Graphics formatını göstərir. Kateqoriyalar bir neçədir: text, image, audio, video, application, multipart və message. Qalan müxtəliflik yüzlərlə sayda olan alt növlər tərəfindən təmin edilir.

Əlavə parametrlər alt növdən sonra nöqtəli vergül vasitəsilə ötürülür. Ən geniş yayılmış parametr kodlaşdırmanı göstərmək üçün charset-dir. Content-Type: application/json; charset=utf-8 o deməkdir ki, UTF-8 kodlaşdırmasında JSON sənədi ötürülür. Formal olaraq application/json üçün charset lazım deyil, çünki JSON həmişə RFC 8259 spesifikasiyasına uyğun olaraq UTF-8-dədir, lakin açıq göstərmə köhnə HTTP müştəriləri ilə uyğunluğu yaxşılaşdırır.

Standart və qeyri-standart MIME növləri

Standart MIME növləri IANA reyestrində qeydiyyatdan keçirilir və əsas kateqoriya prefiksinə malikdir. Qeyri-standart (vendor-specific) növlər x- prefiksindən və ya vnd.company.type formatından istifadə edir — məsələn, Google-dan KML formatı üçün application/vnd.google-earth.kml+xml. Brauzerlər qeyri-standart növləri tanımayabilər, buna görə məlum olmayan əlavələr üçün application/octet-stream istifadə olunur — brauzerin göstərməyə çalışmayıb fayl kimi yükləməyi təklif etdiyi universal ikilik axın.

Praktikada charset parametri

Charset parametri mətnin düzgün göstərilməsi üçün kritik əhəmiyyət daşıyır. Olmadan brauzer simvolları səhv şərh edə bilər, bu da mojibake (krakozyabrlara) səbəb olur. Veb üçün standart UTF-8-dir, lakin qərbi Avropa dilləri üçün ISO-8859-1 (Latin-1) və köhnə saytlarda kiril üçün windows-1251 də rast gəlinir. W3C tövsiyəsi — text/html və text/plain üçün həmişə charset=utf-8 göstərmək, application/json üçün charset tələb olunmur.

Content-Type-ın əsas növləri

Praktikada veb tərtibatçılar və mobil tərtibatçılar məhdud MIME növləri dəsti ilə işləyirlər. Bu növləri bilmək serverin düzgün konfiqurasiyası, HTTP müştərilərinin yazılması və statik faylların işlənməsi üçün zəruridir. text/html — Apache və Nginx serverləri tərəfindən HTML faylları üçün standart olaraq qaytarılan veb səhifələr üçün əsas növdür. application/xhtml+xml daha az istifadə olunur və yalnız XHTML sənədləri üçündür.

application/json REST API üçün standarta çevrildi. Serverlər JSON məlumatlarını bu MIME növü ilə qaytarır, müştərilər isə onu POST və PUT sorğularında göndərir. text/javascript (köhnəlmiş) və application/javascript JavaScript faylları üçün istifadə olunur. W3Techs Survey, 2025 məlumatlarına görə, JSON 2018-ci ildə XML-i qabaqlayaraq vebdə ən sürətli böyüyən məlumat formatıdır. SOAP xidmətləri üçün hələ də text/xml və ya application/soap+xml istifadə olunur.

Şəkillər üçün MIME növü fayl formatı ilə müəyyən edilir: JPEG üçün image/jpeg, PNG üçün image/png, GIF üçün image/gif, WebP üçün image/webp. image/svg+xml vektor qrafikası üçün istifadə olunur və daxili stilləri və skriptləri dəstəkləyir. video/mp4, audio/mpeg və application/pdf digər tez-tez rast gəlinən növlərdir. Veb şriftləri üçün font/woff2, font/woff və font/ttf istifadə olunur.

Fayl yükləmə zamanı Content-Type

HTML forması vasitəsilə fayllar göndərərkən multipart/form-data istifadə olunur — sorğunu bir neçə hissəyə bölən mürəkkəb MIME növü. Hər hissənin öz Content-Type və sahə adını və faylın orijinal adını göstərən Content-Disposition başlığı var. Server faylı brauzer tərəfindən müəyyən edilmiş faktiki MIME növü ilə alır və onu backend tərəfində yoxlaya bilər. application/octet-stream məlum olmayan növdən fayllar üçün tətbiq edilir — brauzer məzmunu göstərməyə çalışmır, onu diskdə saxlamağı təklif edir.

Content-Type-ın keşləməyə təsiri

MIME növü CDN və brauzer keşləmə siyasətinə təsir edir. Stabil URL-ləri olan şəkillər adətən uzun müddətə (bir il və daha çox) keşlənir, HTML səhifələr isə dəqiqələr və ya saniyələr üçün. CDN serverləri Cloudflare və Akamai sıxışdırma alqoritmi seçmək üçün Content-Type-dan istifadə edir: text/* gzip və ya brotli ilə sıxışdırılır, image/* — yox, çünki şəkillər artıq sıxışdırılmışdır. Serverdə Content-Type-ın düzgün konfiqurasiyası səhifələrin və mobil tətbiqlərin yüklənmə performansına birbaşa təsir edir.

Server və müştəri Content-Type-ı necə istifadə edir

Server HTTP cavabında Content-Type başlığını tələb olunan faylın növünə və ya dinamik yaradılmış məzmuna əsasən təyin edir. Məşhur Nginx və Apache veb serverləri fayl genişlənməsini müvafiq Content-Type ilə əlaqələndirən daxili MIME növ cədvəllərinə malikdir. Məsələn, index.html faylı text/html, style.css isə text/css alır. Dinamik cavablar üçün tərtibatçı PHP, Python, Java və ya Kotlin tətbiq kodunda Content-Type-ı təyin edir.

Müştəri emal qurğusunu seçmək üçün Content-Type-dan istifadə edir. Server text/html qaytarırsa, brauzer HTML parserini işə salır və DOM ağacını qurur. image/png olarsa — PNG dekoderini işə salır. Content-Type yoxdursa və ya səhv göstərilirsə, müştəri MIME sniffing tətbiq edir — faylın əvvəlindəki imza (magic bytes) əsasında növü təxmin etməyə çalışır. JPEG FF D8 FF baytları ilə, PNG 89 50 4E 47 ilə, PDF isə 25 50 44 46 ilə başlayır. Bu proses potensial təhlükəlidir və X-Content-Type-Options: nosniff başlığı ilə söndürülür.

Mobil tətbiqlərdə Content-Type HTTP müştəriləri tərəfindən emal olunur. Android-də OkHttp cavabdan Content-Type başlığını avtomatik təhlil edir və onu Response.header("Content-Type") metodu vasitəsilə təmin edir. iOS müştərisi URLSession eyni şeyi URLResponse.mimeType xassəsi vasitəsilə edir. Hər iki platformada Content-Type parser seçimi üçün istifadə olunur: JSON — Android-də Moshi və ya Gson vasitəsilə, iOS-da Codable ilə; şəkillər — Glide, Coil və ya SDWebImage vasitəsilə.

Accept və Content-Type vasitəsilə Content Negotiation

Content negotiation (məzmunun razılaşdırılması) — HTTP mexanizmidir, burada müştəri Accept başlığı vasitəsilə istənilən cavab formatını göstərir, server isə uyğun formatı seçir və onu müvafiq Content-Type ilə qaytarır. Məsələn, müştəri Accept: application/json göndərir, server Content-Type: application/json ilə cavab verir. Server tələb olunan formatı təmin edə bilmirsə, 406 Not Acceptable qaytarır. REST API-də bu mexanizm bir endpoint-ə JSON, XML və ya HTML-də məlumat qaytarmağa imkan verir.

Content-Type sorğu və cavablarda

Content-Type başlığı həm HTTP sorğularında (Request), həm də HTTP cavablarında (Response) istifadə olunur. Sorğularda o, sorğu gövdəsinin formatını göstərir, məsələn JSON-u POST vasitəsilə göndərərkən. Cavablarda — qaytarılan məlumatların formatını. Əsas fərq ondadır ki, sorğunun Content-Type-nı müştəri, cavabın Content-Type-nı isə server təyin edir. Sorğuda səhv Content-Type təyini serverin gövdəni təhlil edə bilməməsinə səbəb olur, 400 Bad Request və ya 415 Unsupported Media Type xətası qaytarılır.

HTTP sorğularında Content-Type POST, PUT və PATCH metodları üçün məcburidir, əgər sorğu gövdə (body) ehtiva edirsə. GET, HEAD və DELETE adətən gövdə istifadə etmir, buna görə Content-Type onlar üçün göstərilmir və ya nəzərdən qaçırılır. enctype="multipart/form-data" atributu olan HTML forması göndərərkən brauzer avtomatik olaraq Content-Type: multipart/form-data təyin edir və mürəkkəb sorğunun hissələrini ayıran unikal sərhəd sətri (boundary) əlavə edir. Hər hissə --boundary ilə ayrılır, sorğunun sonu isə --boundary-- ilə qeyd olunur.

HTTP cavablarında Content-Type server tərəfindən təyin edilir. Server Content-Type göstərməzsə, müştəri ya MIME sniffing işə salır, ya da cavabı application/octet-stream kimi emal edir. HTTP HEAD metodu gövdəni ötürmədən Content-Type daxil olmaqla cavab başlıqlarını almağa imkan verir. Bu, tam yükləmədən əvvəl resursun növünü yoxlamaq üçün faydalıdır. CDN serverləri məzmun transformasiyası zamanı Content-Type-ı dəyişə bilər — məsələn, şəkilləri WebP-ə çevirərkən.

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("Növ: ${mediaType?.type}, Alt növ: ${mediaType?.subtype}")
    }
}

Mobil HTTP müştərilərində Content-Type

Mobil tərtibatda Content-Type başlığı HTTP müştəriləri tərəfindən avtomatik emal olunur. Android-də OkHttp-də Content-Type RequestBody vasitəsilə təyin edilir: val body = "{}".toRequestBody("application/json".toMediaType()). Retrofit Content-Type-ı annotasiyalar vasitəsilə idarə edir: JSON üçün @Body, multipart üçün @Part. iOS-da URLSession HTTPBody üçün Content-Type təyin edir, Alamofire isə bunu encoding parametri vasitəsilə edir: JSONEncoding.default və ya URLEncoding.default. Content-Type-ın əl ilə təyini xam soketlər və ya fərdi protokollarla işləyərkən tələb olunur.

Content-Type ilə işləyərkən səhvlər

Səhv Content-Type — veb xidmətlərin hazırlanması və inteqrasiyası zamanı ən geniş yayılmış problemlərdən biridir. Ən geniş yayılmış səhv serverin text/html qaytarmasıdır application/json əvəzinə. Müştəri JSON-u HTML sətri kimi alır, onu təhlil edə bilmir və istisna yaradır. Bu, veb freymvork standart olaraq HTML-ə konfiqurasiya edildikdə və tərtibatçı API endpointi üçün Content-Type-ı dəyişdirməyi unutduqda baş verir. PHP-də bu, header('Content-Type: application/json') olmaması, Spring Boot-da isə produces annotasiyasının olmaması ilə özünü göstərir.

Tezlik baxımından ikinci səhv səhv və ya çatışmayan charset-dir. Server text/html; charset=iso-8859-1 göndərir, brauzer isə UTF-8 gözləyirsə, kiril simvolları krakozyabr kimi göstərilir. Bu problem UTF-8-ə keçməmiş köhnə saytlar üçün xarakterikdir. JSON üçün belə səhv daha az rast gəlinir, çünki RFC 8259 əlavə razılaşdırma olmadan UTF-8 tələb edir. Həll — server konfiqurasiyasında mətn MIME növləri üçün həmişə açıq şəkildə charset=utf-8 göstərmək.

Üçüncü problem — Content-Type-ın real məzmuna uyğun gəlməməsi. Server Content-Type: image/png göndərir, lakin cavabın gövdəsində WebP şəkli var, brauzer onu dekod edə bilməz. CDN serverləri bəzən formatı dəyişdirərək şəkilləri sıxışdırır, lakin Content-Type başlığını yeniləmir. Content-Type-ın faktiki məzmuna uyğunluğunun yoxlanılması API testinin və mobil tətbiqlərin inteqrasiya testinin məcburi mərhələsidir.

Content-Type səhvlərinin diaqnostikası və düzəldilməsi

Debug üçün brauzerin tərtibatçı alətlərindən (Network sekmesi), cavab başlıqlarını yoxlamaq üçün -I bayrağı ilə curl-dan və ya Charles Proxy və Wireshark kimi trafik sniffersindən istifadə edin. Nginx include mime.types direktivi ilə, Apache isə AddType və AddDefaultCharset vasitəsilə konfiqurasiya olunur. Statik fayllar üçün həmişə fayl genişlənməsinin onun MIME növünə uyğun olduğunu yoxlayın. Dinamik cavablar üçün bütün proqramlaşdırma dillərində məlumat çıxarmazdan əvvəl açıq şəkildə Content-Type təyin edin — bu, problemlərin böyük əksəriyyətinin qarşısını alır.