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, оскільки цей стандарт спочатку створювався для email-вкладень. Однак він став основою 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-стандарт із протоколу email, і 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 цей механізм дозволяє одному ендпоінту віддавати дані в 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-ендпоінту. В 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 перед виведенням даних — це запобігає переважній більшості проблем.