Content-Type у веб развоју: шта је то, MIME типови и како функционише

Шта је Content-Type?

Content-Type — је HTTP заглавље из групе заглавља репрезентације (representation headers) које обавештава примаоца о формату података у телу поруке. Обавезно је за HTTP захтеве и одговоре који садрже тело (body), а без њега клијент не може исправно да тумачи примљене бајтове. Прегледач или мобилна апликација на основу 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 значи да се преноси HTML документ у UTF-8 кодирању. Према IETF RFC 7231, одељак 3.1.1.5, заглавље Content-Type је обавезно за HTTP поруке које садрже тело, а његово одсуство се тумачи као application/octet-stream или доводи до MIME sniffing-а.

Историја појаве MIME типова у HTTP-у

Протокол HTTP/0.9, објављен 1991. године, преносио је само HTML странице, па је тип података био подразумеван. Са појавом HTTP/1.0 у спецификацији RFC 1945, програмери су схватили потребу за преношењем слика, стилских таблица и скрипти. Адаптирали су MIME стандард из протокола е-поште, и Content-Type је постао саставни део HTTP-а. Од тада, IANA регистар се проширио на стотине вредности — од познатог text/html до савремених image/avif и application/manifest+json.

Улога Content-Type у безбедности

Content-Type игра критичну улогу у заштити од напада. Ако сервер шаље HTML датотеку са MIME типом text/plain, прегледач неће извршавати 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 обавештава да се преноси JSON документ у UTF-8 кодирању. Формално, charset за application/json је сувишан, јер је JSON увек у UTF-8 према спецификацији RFC 8259, али експлицитно навођење побољшава компатибилност са старијим HTTP клијентима.

Стандардни и нестандардни MIME типови

Стандардни MIME типови се региструју у IANA регистру и имају префикс основне категорије. Нестандардни (vendor-specific) користе префикс x- или формат vnd.company.type — на пример, application/vnd.google-earth.kml+xml за KML формат од Google-а. Прегледачи можда неће препознати нестандардне типове, па се за непознате прилоге користи application/octet-stream — универзални бинарни ток који прегледач не покушава да прикаже, већ нуди преузимање као датотеку.

Параметар charset у пракси

Параметар charset је критичан за исправно приказивање текста. Без њега прегледач може погрешно да протумачи знакове, што доводи до mojibake (погрешног приказа знакова). За веб стандард је UTF-8, али се срећу ISO-8859-1 (Latin-1) за западноевропске језике и windows-1251 за ћирилицу на старим сајтовима. Препорука W3C — увек наводити charset=utf-8 за text/html и text/plain, а за application/json charset није потребан.

Основни типови Content-Type

У пракси, веб програмери и мобилни програмери раде са ограниченим скупом MIME типова. Познавање ових типова је неопходно за исправну конфигурацију сервера, писање HTTP клијената и обраду статичких датотека. text/html — основни тип за веб странице, који подразумевано враћају Apache и Nginx сервери за HTML датотеке. application/xhtml+xml се користи ређе и само за XHTML документе.

application/json је постао стандард за REST API. Сервери враћају JSON податке са овим MIME типом, а клијенти га шаљу у POST и PUT захтевима. text/javascript (застарео) и application/javascript се користе за JavaScript датотеке. Према W3Techs Survey, 2025, JSON је најбрже растући формат података на вебу, престигавши XML 2018. године. За SOAP услуге још увек се користи text/xml или application/soap+xml.

За слике, MIME тип је одређен форматом датотеке: image/jpeg за JPEG, image/png за PNG, image/gif за GIF, image/webp за модерни 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

Сервер поставља заглавље Content-Type у HTTP одговору на основу типа захтеване датотеке или динамички генерисаног садржаја. Популарни веб сервери Nginx и Apache имају уграђене табеле MIME типова које повезују екстензију датотеке са одговарајућим Content-Type. На пример, датотека index.html добија text/html, а style.css — text/css. За динамичке одговоре, програмер поставља Content-Type у коду апликације у PHP, Python, Java или Kotlin-у.

Клијент користи Content-Type за избор руковаоца. Ако сервер враћа text/html, прегледач покреће HTML парсер и гради DOM стабло. Ако image/png — покреће PNG декодер. Ако Content-Type недостаје или је нетачан, клијент примењује MIME sniffing — покушава да погоди тип на основу потписа (magic bytes) на почетку датотеке. JPEG почиње бајтовима FF D8 FF, PNG — са 89 50 4E 47, а PDF — са 25 50 44 46. Овај процес је потенцијално опасан и искључује се заглављем X-Content-Type-Options: nosniff.

У мобилним апликацијама, Content-Type обрађују HTTP клијенти. OkHttp на Android-у аутоматски анализира заглавље Content-Type из одговора и обезбеђује га кроз метод Response.header("Content-Type"). iOS клијент URLSession ради исто кроз својство URLResponse.mimeType. На обе платформе, Content-Type се користи за избор парсера: JSON — преко Moshi или Gson на Android-у, преко Codable на iOS-у; слике — преко Glide, Coil или SDWebImage.

Content Negotiation кроз Accept и Content-Type

Content negotiation (преговарање садржаја) — HTTP механизам у ком клијент наводи жељени формат одговора кроз заглавље Accept, а сервер бира одговарајући формат и враћа га са одговарајућим Content-Type. На пример, клијент шаље Accept: application/json, сервер одговара са Content-Type: application/json. Ако сервер не може да обезбеди тражени формат, враћа 406 Not Acceptable. У REST API-ју овај механизам омогућава једном endpoint-у да враћа податке у JSON, XML или HTML формату.

Content-Type у захтевима и одговорима

Заглавље Content-Type се користи како у HTTP захтевима (Request), тако и у HTTP одговорима (Response). У захтевима он одређује формат тела захтева, на пример при слању JSON-а путем POST. У одговорима — формат враћених података. Суштинска разлика је у томе што Content-Type захтева поставља клијент, а Content-Type одговора — сервер. Нетачно постављање Content-Type у захтеву доводи до тога да сервер не може да парсира тело, враћајући грешку 400 Bad Request или 415 Unsupported Media Type.

У HTTP захтевима, Content-Type је обавезан за методе POST, PUT и PATCH ако захтев садржи тело (body). GET, HEAD и DELETE обично не користе тело, па се Content-Type за њих не наводи или се игнорише. Приликом слања HTML формулара са атрибутом enctype="multipart/form-data", прегледач аутоматски поставља Content-Type: multipart/form-data са јединственим граничним низом (boundary) који раздваја делове сложеног захтева. Сваки део је одвојен са --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}")
    }
}

Content-Type у мобилним HTTP клијентима

У мобилном развоју, заглавље Content-Type се аутоматски обрађује од стране HTTP клијената. У OkHttp на Android-у, Content-Type се поставља кроз RequestBody: val body = "{}".toRequestBody("application/json".toMediaType()). Retrofit управља Content-Type кроз анотације: @Body за JSON, @Part за multipart. На iOS-у, URLSession поставља Content-Type за HTTPBody, а Alamofire то ради кроз параметар encoding: JSONEncoding.default или URLEncoding.default. Ручно постављање Content-Type је потребно при раду са сировим сокетима или прилагођеним протоколима.

Грешке при раду са Content-Type

Нетачан Content-Type — један од најчешћих проблема при развоју и интеграцији веб услуга. Најчешћа грешка је када сервер враћа text/html уместо application/json. Клијент прима JSON као HTML низ, не може да га парсира и баца изузетак. Ово се дешава када је веб фрејмворк подразумевано конфигурисан на HTML, а програмер заборави да препише Content-Type за API endpoint. У PHP-у се ово манифестује одсуством header('Content-Type: application/json'), у Spring Boot-у — одсуством анотације produces.

Друга грешка по учесталости — нетачан или недостајући charset. Ако сервер шаље text/html; charset=iso-8859-1, а прегледач очекује UTF-8, ћирилични знакови се приказују погрешно. Овај проблем је карактеристичан за старе сајтове који нису прешли на UTF-8. За JSON се ова грешка ређе јавља, јер RFC 8259 прописује UTF-8 без додатног усаглашавања. Решење — увек експлицитно наводити charset=utf-8 за текстуалне MIME типове у конфигурацији сервера.

Трећи проблем — неусаглашеност Content-Type са стварним садржајем. Ако сервер шаље Content-Type: image/png, а тело одговора садржи WebP слику, прегледач је можда неће декодирати. CDN сервери понекад компримују слике уз промену формата, али не ажурирају заглавље Content-Type. Провера усаглашености Content-Type са стварним садржајем — обавезна фаза тестирања API-ја и интеграционог тестирања мобилних апликација.

Дијагностика и исправљање грешака Content-Type

За отклањање грешака користите алатке за програмере у прегледачу (картица Network), curl са флагом -I за проверу заглавља одговора или снифере саобраћаја као што су Charles Proxy и Wireshark. Nginx се конфигурише кроз директиву include mime.types, Apache — кроз AddType и AddDefaultCharset. За статичке датотеке увек проверавајте да екстензија датотеке одговара њеном MIME типу. За динамичке одговоре у свим програмским језицима експлицитно постављајте Content-Type пре исписивања података — ово спречава огромну већину проблема.