Web Geliştirmede Content-Type: Nedir, MIME Türleri ve Nasıl Çalışır

Content-Type Nedir?

Content-Type, temsil başlıkları grubundan, alıcıya mesaj gövdesindeki verilerin biçimini bildiren bir HTTP başlığıdır. Gövde içeren HTTP istekleri ve yanıtları için zorunludur ve onsuz istemci, alınan baytları doğru şekilde yorumlayamaz. Content-Type'a bağlı olarak, tarayıcı veya mobil uygulama bir ayrıştırıcı seçer: text/html için HTML motorunu başlatır, image/png için PNG kod çözücüsünü, application/json için JSON ayrıştırıcısını başlatır.

Content-Type değeri bir MIME türüdür — veri biçimleri için standartlaştırılmış bir tanımlayıcı. MIME kısaltması Multipurpose Internet Mail Extensions anlamına gelir, çünkü bu standart aslen e-posta ekleri için oluşturulmuştur. Ancak, HTTP'nin temeli haline gelmiş ve günümüzde web sayfalarının iletilmesinden REST API'lerde veri alışverişine kadar her yerde kullanılmaktadır. Her MIME türü iki bölümden oluşur: eğik çizgiyle ayrılmış bir ana kategori ve bir nitelikli alt tür.

charset parametresi, metin biçimleri için Content-Type'ı tamamlar. Örneğin, Content-Type: text/html; charset=utf-8, UTF-8 kodlamasında bir HTML belgesinin iletildiğini belirtir. IETF RFC 7231, bölüm 3.1.1.5'e göre, Content-Type başlığı gövde içeren HTTP mesajları için zorunludur ve yokluğu application/octet-stream olarak ele alınır veya MIME sniffing'e yol açar.

HTTP'de MIME Türlerinin Tarihi

1991'de yayınlanan HTTP/0.9 protokolü yalnızca HTML sayfalarını iletiyordu, bu nedenle veri türü varsayılan olarak örtüktü. RFC 1945'te HTTP/1.0'ın tanıtılmasıyla, geliştiriciler resimler, stil sayfaları ve betikleri iletme ihtiyacını fark ettiler. E-posta protokolünden MIME standardını uyarladılar ve Content-Type, HTTP'nin ayrılmaz bir parçası haline geldi. O zamandan beri, IANA kaydı yüzlerce değere genişledi — tanıdık text/html'den modern image/avif ve application/manifest+json'a kadar.

Güvenlikte Content-Type'ın Rolü

Content-Type, saldırılara karşı korumada kritik bir rol oynar. Bir sunucu, text/plain MIME türüyle bir HTML dosyası gönderirse, tarayıcı JavaScript'i çalıştırmaz veya DOM'u oluşturmaz — bu, XSS saldırılarını önler. OWASP tarafından önerilen X-Content-Type-Options: nosniff başlığı, tarayıcının içeriğe dayalı olarak MIME türünü tahmin etmesini tamamen yasaklar. PortSwigger Research'e göre, MIME sniffing saldırıları özellikle Internet Explorer 6-9'da yaygındı; burada tarayıcı Content-Type'ı yok sayar ve türü dosyanın ilk baytlarından belirlerdi.

MIME Türü Yapısı

Bir MIME türü type/subtype biçiminde belirtilir; burada type verinin genel kategorisi ve subtype bunun içindeki belirli biçimdir. Örneğin, image/png'de kategori image bir resmi belirtir ve alt tür png, Portable Network Graphics biçimini belirtir. Yalnızca birkaç kategori vardır: text, image, audio, video, application, multipart ve message. Geri kalan çeşitlilik, yüzlerce olan alt türlerden gelir.

Ek parametreler, alt türden sonra noktalı virgülle iletilir. En yaygın parametre, kodlamayı belirtmek için charset'tir. Content-Type: application/json; charset=utf-8, UTF-8 kodlamasında bir JSON belgesinin iletildiğini belirtir. Resmi olarak, application/json için charset gereksizdir çünkü RFC 8259'a göre JSON her zaman UTF-8'dedir, ancak açık belirtim eski HTTP istemcileriyle uyumluluğu artırır.

Standart ve Standart Olmayan MIME Türleri

Standart MIME türleri IANA kaydına kayıtlıdır ve bir ana kategori önekine sahiptir. Standart olmayan (satıcıya özel) türler x- önekini veya vnd.company.type biçimini kullanır — örneğin, Google'ın KML biçimi için application/vnd.google-earth.kml+xml. Tarayıcılar standart olmayan türleri tanımayabilir, bu nedenle bilinmeyen ekler için application/octet-stream kullanılır — tarayıcının görüntülemeye çalışmadığı, dosya olarak indirmeyi önerdiği evrensel bir ikili akış.

Pratikte charset Parametresi

charset parametresi, doğru metin görüntüleme için kritiktir. Bu olmadan, tarayıcı karakterleri yanlış yorumlayabilir ve bu da mojibake'e yol açar. Web için standart UTF-8'dir, ancak Batı Avrupa dilleri için ISO-8859-1 (Latin-1) ve eski sitelerde Kiril için windows-1251 de bulunur. W3C tavsiyesi, text/html ve text/plain için her zaman charset=utf-8 belirtmektir, application/json için charset gerekli değildir.

Yaygın Content-Type Türleri

Pratikte, web geliştiricileri ve mobil geliştiriciler sınırlı bir MIME türü kümesiyle çalışır. Bu türleri bilmek, sunucuları doğru yapılandırmak, HTTP istemcileri yazmak ve statik dosyaları işlemek için gereklidir. text/html, web sayfaları için ana türdür ve Apache ve Nginx sunucuları tarafından HTML dosyaları için varsayılan olarak döndürülür. application/xhtml+xml daha az kullanılır ve yalnızca XHTML belgeleri içindir.

application/json, REST API'leri için standart haline gelmiştir. Sunucular bu MIME türüyle JSON verilerini döndürür ve istemciler bunu POST ve PUT isteklerinde gönderir. text/javascript (kullanımdan kaldırıldı) ve application/javascript, JavaScript dosyaları için kullanılır. W3Techs Anketi, 2025'e göre JSON, web'de en hızlı büyüyen veri biçimidir ve 2018'de XML'i geçmiştir. SOAP hizmetleri için hala text/xml veya application/soap+xml kullanılır.

Görüntüler için MIME türü dosya biçimine göre belirlenir: JPEG için image/jpeg, PNG için image/png, GIF için image/gif, modern WebP biçimi için image/webp. image/svg+xml, vektör grafikleri için kullanılır ve gömülü stilleri ve betikleri destekler. video/mp4, audio/mpeg ve application/pdf sık karşılaşılan diğer türlerdir. Web yazı tipleri için font/woff2, font/woff ve font/ttf kullanılır.

Dosya Yüklemelerinde Content-Type

HTML formu aracılığıyla dosya yüklerken, multipart/form-data kullanılır — isteği birden çok parçaya bölen bileşik bir MIME türü. Her parçanın kendi Content-Type başlığı ve alan adını ve orijinal dosya adını belirten Content-Disposition'ı vardır. Sunucu, dosyayı tarayıcı tarafından belirlenen gerçek MIME türüyle alır ve arka uç tarafında doğrulayabilir. application/octet-stream, türü bilinmeyen dosyalar için kullanılır — tarayıcı içeriği görüntülemeye çalışmaz, diske kaydetmeyi önerir.

Content-Type'ın Önbelleğe Alma Üzerindeki Etkisi

MIME türü, CDN ve tarayıcıların önbelleğe alma politikasını etkiler. Kararlı URL'lere sahip görüntüler genellikle uzun bir süre (bir yıl veya daha fazla) önbelleğe alınırken, HTML sayfaları dakikalar veya saniyeler boyunca önbelleğe alınır. Cloudflare ve Akamai gibi CDN sunucuları, sıkıştırma algoritmasını seçmek için Content-Type'ı kullanır: text/* gzip veya brotli ile sıkıştırılır, image/* sıkıştırılmaz çünkü görüntüler zaten sıkıştırılmıştır. Sunucuda doğru Content-Type yapılandırması, web sayfalarının ve mobil uygulamaların yüklenme performansını doğrudan etkiler.

Sunucu ve İstemci Content-Type'ı Nasıl Kullanır

Sunucu, istenen dosyanın türüne veya dinamik olarak oluşturulan içeriğe bağlı olarak HTTP yanıtında Content-Type başlığını ayarlar. Nginx ve Apache gibi popüler web sunucuları, dosya uzantılarını ilgili Content-Type ile eşleştiren yerleşik MIME türü tablolarına sahiptir. Örneğin, index.html text/html alır ve style.css text/css alır. Dinamik yanıtlar için geliştirici, PHP, Python, Java veya Kotlin'de uygulama kodunda Content-Type'ı ayarlar.

İstemci, bir işleyici seçmek için Content-Type'ı kullanır. Sunucu text/html döndürürse, tarayıcı HTML ayrıştırıcısını başlatır ve DOM ağacını oluşturur. image/png ise PNG kod çözücüsünü başlatır. Content-Type eksik veya yanlışsa, istemci MIME sniffing uygular — dosyanın başındaki imzadan (sihirli baytlar) türü tahmin etmeye çalışır. JPEG, FF D8 FF baytlarıyla başlar, PNG 89 50 4E 47 ile ve PDF 25 50 44 46 ile başlar. Bu süreç potansiyel olarak tehlikelidir ve X-Content-Type-Options: nosniff başlığı tarafından devre dışı bırakılır.

Mobil uygulamalarda, Content-Type HTTP istemcileri tarafından işlenir. Android'de OkHttp, yanıttan Content-Type başlığını otomatik olarak ayrıştırır ve Response.header("Content-Type") yöntemiyle sağlar. iOS URLSession istemcisi, URLResponse.mimeType özelliği aracılığıyla aynısını yapar. Her iki platformda da Content-Type, bir ayrıştırıcı seçmek için kullanılır: JSON — Android'de Moshi veya Gson aracılığıyla, iOS'ta Codable aracılığıyla; görüntüler — Glide, Coil veya SDWebImage aracılığıyla.

Accept ve Content-Type ile İçerik Anlaşması

İçerik anlaşması, istemcinin Accept başlığı aracılığıyla istenen yanıt biçimini belirttiği ve sunucunun uygun biçimi seçip ilgili Content-Type ile döndürdüğü bir HTTP mekanizmasıdır. Örneğin, istemci Accept: application/json gönderir, sunucu Content-Type: application/json ile yanıt verir. Sunucu istenen biçimi sağlayamazsa, 406 Not Acceptable döndürür. REST API'lerinde bu mekanizma, tek bir uç noktanın verileri JSON, XML veya HTML olarak döndürmesine olanak tanır.

İstek ve Yanıtlarda Content-Type

Content-Type başlığı hem HTTP isteklerinde hem de HTTP yanıtlarında kullanılır. İsteklerde, istek gövdesinin biçimini belirtir, örneğin POST ile JSON gönderirken. Yanıtlarda, döndürülen verilerin biçimini belirtir. Temel fark, isteğin Content-Type'ının istemci tarafından, yanıtın Content-Type'ının ise sunucu tarafından ayarlanmasıdır. Bir istekte Content-Type'ın yanlış ayarlanması, sunucunun gövdeyi ayrıştıramamasına ve 400 Bad Request veya 415 Unsupported Media Type hatası döndürmesine neden olur.

HTTP isteklerinde, Content-Type, istek bir gövde içeriyorsa POST, PUT ve PATCH yöntemleri için zorunludur. GET, HEAD ve DELETE tipik olarak bir gövde kullanmaz, bu nedenle Content-Type belirtilmez veya yok sayılır. enctype="multipart/form-data" özniteliğine sahip bir HTML formu gönderirken, tarayıcı otomatik olarak bileşik isteğin parçalarını ayıran benzersiz bir sınır dizesiyle Content-Type: multipart/form-data ayarlar. Her parça --boundary ile ayrılır ve isteğin sonu --boundary-- ile işaretlenir.

HTTP yanıtlarında, Content-Type sunucu tarafından ayarlanır. Sunucu Content-Type belirtmezse, istemci MIME sniffing'i etkinleştirir veya yanıtı application/octet-stream olarak işler. HTTP HEAD yöntemi, gövdeyi iletmeden Content-Type dahil yanıt başlıklarını almayı sağlar. Bu, kaynağı tamamen yüklemeden önce türünü kontrol etmek için kullanışlıdır. CDN sunucuları, içeriği dönüştürürken Content-Type'ı geçersiz kılabilir — örneğin, görüntüleri WebP'ye dönüştürürken.

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("Tür: ${mediaType?.type}, Alt tür: ${mediaType?.subtype}")
    }
}

Mobil HTTP İstemcilerinde Content-Type

Mobil geliştirmede, Content-Type başlığı HTTP istemcileri tarafından otomatik olarak işlenir. Android'de OkHttp'de Content-Type, RequestBody aracılığıyla ayarlanır: val body = "{}".toRequestBody("application/json".toMediaType()). Retrofit, Content-Type'ı ek açıklamalar aracılığıyla yönetir: JSON için @Body, çok parçalı için @Part. iOS'ta URLSession, HTTPBody için Content-Type'ı ayarlar ve Alamofire bunu encoding parametresi aracılığıyla yapar: JSONEncoding.default veya URLEncoding.default. Ham soketler veya özel protokollerle çalışırken manuel Content-Type ayarlaması gerekir.

Content-Type Hataları

Yanlış Content-Type, web hizmeti geliştirme ve entegrasyonunda en yaygın sorunlardan biridir. En sık görülen hata, sunucunun application/json yerine text/html döndürmesidir. İstemci, JSON'u bir HTML dizesi olarak alır, ayrıştıramaz ve bir istisna fırlatır. Bu, web çerçevesi varsayılan olarak HTML için yapılandırıldığında ve geliştirici API uç noktaları için Content-Type'ı geçersiz kılmayı unuttuğunda oluşur. PHP'de bu, header('Content-Type: application/json') eksik olduğunda, Spring Boot'ta — produces ek açıklaması eksik olduğunda ortaya çıkar.

İkinci en yaygın hata, yanlış veya eksik charset'tir. Sunucu text/html; charset=iso-8859-1 gönderir ve tarayıcı UTF-8 bekliyorsa, Kiril karakterler mojibake olarak görüntülenir. Bu sorun, UTF-8'e geçmemiş eski siteler için tipiktir. JSON için bu hata daha az yaygındır çünkü RFC 8259, ek anlaşma olmadan UTF-8'i öngörür. Çözüm, sunucu yapılandırmasında metin MIME türleri için her zaman açıkça charset=utf-8 belirtmektir.

Üçüncü sorun, Content-Type'ın gerçek içerikle uyuşmamasıdır. Sunucu Content-Type: image/png gönderir ancak yanıt gövdesi bir WebP görüntüsü içeriyorsa, tarayıcı onu kodlayamayabilir. CDN sunucuları bazen biçimi değiştirerek görüntüleri sıkıştırır ancak Content-Type başlığını güncellemez. Content-Type'ın gerçek içerikle uyumluluğunu kontrol etmek, API testi ve mobil uygulamaların entegrasyon testinde zorunlu bir adımdır.

Content-Type Hatalarını Teşhis ve Düzeltme

Hata ayıklama için tarayıcı geliştirici araçlarını (Network sekmesi), yanıt başlıklarını kontrol etmek için -I bayrağıyla curl'u veya Charles Proxy ve Wireshark gibi trafik dinleyicilerini kullanın. Nginx, include mime.types yönergesiyle, Apache — AddType ve AddDefaultCharset ile yapılandırılır. Statik dosyalar için, dosya uzantısının MIME türüyle eşleştiğini her zaman doğrulayın. Tüm programlama dillerinde dinamik yanıtlar için, veri çıktısı almadan önce açıkça Content-Type ayarlayın — bu, sorunların büyük çoğunluğunu önler.