Content-Type ve vývoji webu: co to je, MIME typy a jak to funguje

Co je Content-Type?

Content-Type — je HTTP hlavička ze skupiny representation headers, která informuje příjemce o formátu dat v těle zprávy. Je povinná pro HTTP požadavky a odpovědi obsahující tělo (body) a bez ní klient nemůže správně interpretovat přijaté bajty. Prohlížeč nebo mobilní aplikace na základě Content-Type vybírá parser: pro text/html spouští HTML engine, pro image/png — PNG dekodér, pro application/json — JSON parser.

Hodnota Content-Type je MIME typ — standardizovaný identifikátor formátu dat. Zkratka MIME znamená Multipurpose Internet Mail Extensions, protože tento standard byl původně vytvořen pro e-mailové přílohy. Stal se však základem HTTP a dnes se používá všude — od přenosu webových stránek až po výměnu dat v REST API. Každý MIME typ se skládá ze dvou částí: hlavní kategorie a upřesňujícího podtypu, oddělených lomítkem.

Parametr charset doplňuje Content-Type pro textové formáty. Například Content-Type: text/html; charset=utf-8 znamená, že je přenášen HTML dokument v kódování UTF-8. Podle IETF RFC 7231, oddíl 3.1.1.5, je hlavička Content-Type povinná pro HTTP zprávy obsahující tělo a její absence je interpretována jako application/octet-stream nebo vede k MIME sniffingu.

Historie vzniku MIME typů v HTTP

Protokol HTTP/0.9, vydaný v roce 1991, přenášel pouze HTML stránky, takže typ dat byl implicitní. S příchodem HTTP/1.0 ve specifikaci RFC 1945 si vývojáři uvědomili potřebu přenášet obrázky, styly a skripty. Adaptovali standard MIME z e-mailového protokolu a Content-Type se stal nedílnou součástí HTTP. Od té doby se registr IANA rozšířil na stovky hodnot — od známého text/html až po moderní image/avif a application/manifest+json.

Role Content-Type v bezpečnosti

Content-Type hraje kritickou roli v ochraně proti útokům. Pokud server odešle HTML soubor s MIME typem text/plain, prohlížeč nespustí JavaScript a nevybuduje DOM — to zabraňuje útokům XSS. Hlavička X-Content-Type-Options: nosniff, doporučená OWASP, zcela zakazuje prohlížeči hádat MIME typ na základě obsahu. Podle PortSwigger Research byly útoky pomocí MIME sniffingu obzvláště rozšířené v Internet Explorer 6-9, kde prohlížeč ignoroval Content-Type a určoval typ podle prvních bajtů souboru.

Struktura MIME typu

MIME typ se zadává ve formátu type/subtype, kde type je obecná kategorie dat a subtype je konkrétní formát v rámci ní. Například v hodnotě image/png kategorie image odkazuje na obrázek a podtyp png — na formát Portable Network Graphics. Kategorií je jen několik: text, image, audio, video, application, multipart a message. Zbývající rozmanitost zajišťují podtypy, kterých jsou stovky.

Další parametry se přenášejí pomocí středníku za podtypem. Nejčastějším parametrem je charset pro určení kódování. Content-Type: application/json; charset=utf-8 informuje, že je přenášen JSON dokument v kódování UTF-8. Formálně je charset pro application/json nadbytečný, protože JSON je vždy v UTF-8 podle specifikace RFC 8259, ale explicitní uvedení zlepšuje kompatibilitu se staršími HTTP klienty.

Standardní a nestandardní MIME typy

Standardní MIME typy jsou registrovány v registru IANA a mají prefix hlavní kategorie. Nestandardní (vendor-specific) typy používají prefix x- nebo formát vnd.company.type — například application/vnd.google-earth.kml+xml pro formát KML od Google. Prohlížeče nemusí nestandardní typy rozpoznávat, proto se pro neznámé přílohy používá application/octet-stream — univerzální binární proud, který se prohlížeč nepokouší zobrazit, ale nabízí ke stažení jako soubor.

Parametr charset v praxi

Parametr charset je kritický pro správné zobrazení textu. Bez něj může prohlížeč nesprávně interpretovat znaky, což vede k mojibake (zkresleným znakům). Standardem pro web je UTF-8, ale setkáváme se také s ISO-8859-1 (Latin-1) pro západoevropské jazyky a windows-1251 pro cyrilici na starých webech. Doporučení W3C — vždy uvádějte charset=utf-8 pro text/html a text/plain, a pro application/json charset není vyžadován.

Hlavní typy Content-Type

V praxi weboví vývojáři a mobilní vývojáři pracují s omezenou sadou MIME typů. Znalost těchto typů je nezbytná pro správnou konfiguraci serveru, psaní HTTP klientů a zpracování statických souborů. text/html — hlavní typ pro webové stránky, výchozí pro servery Apache a Nginx pro HTML soubory. application/xhtml+xml se používá méně často a pouze pro XHTML dokumenty.

application/json se stal standardem pro REST API. Servery vracejí JSON data s tímto MIME typem a klienti jej posílají v požadavcích POST a PUT. text/javascript (zastaralý) a application/javascript se používají pro JavaScript soubory. Podle W3Techs Survey, 2025 je JSON nejrychleji rostoucím datovým formátem na webu, který v roce 2018 předstihl XML. Pro SOAP služby se stále používá text/xml nebo application/soap+xml.

Pro obrázky je MIME typ určen formátem souboru: image/jpeg pro JPEG, image/png pro PNG, image/gif pro GIF, image/webp pro moderní formát WebP. image/svg+xml se používá pro vektorovou grafiku a podporuje vložené styly a skripty. video/mp4, audio/mpeg a application/pdf — další často se vyskytující typy. Pro webová písma se používají font/woff2, font/woff a font/ttf.

Content-Type při nahrávání souborů

Při odesílání souborů přes HTML formulář se používá multipart/form-data — složený MIME typ, který rozděluje požadavek na několik částí. Každá část má vlastní hlavičku Content-Type a Content-Disposition, která udává název pole a původní název souboru. Server obdrží soubor s jeho skutečným MIME typem, určeným prohlížečem, a může jej zkontrolovat na straně backendu. application/octet-stream se aplikuje pro soubory neznámého typu — prohlížeč se nepokouší zobrazit obsah, ale nabízí uložení na disk.

Vliv Content-Type na ukládání do mezipaměti

MIME typ ovlivňuje politiku ukládání do mezipaměti CDN a prohlížeče. Obrázky se stabilními URL se obvykle ukládají do mezipaměti na dlouhou dobu (rok a více), zatímco HTML stránky — na minuty nebo sekundy. CDN servery Cloudflare a Akamai používají Content-Type pro výběr kompresního algoritmu: text/* se komprimuje gzip nebo brotli, image/* — ne, protože obrázky jsou již komprimované. Správná konfigurace Content-Type na serveru přímo ovlivňuje výkon načítání stránek a mobilních aplikací.

Jak server a klient používají Content-Type

Server nastavuje hlavičku Content-Type v HTTP odpovědi na základě typu požadovaného souboru nebo dynamicky generovaného obsahu. Populární webové servery Nginx a Apache mají vestavěné tabulky MIME typů, které mapují příponu souboru na odpovídající Content-Type. Například soubor index.html dostává text/html a style.css — text/css. Pro dynamické odpovědi nastavuje vývojář Content-Type v kódu aplikace v PHP, Python, Java nebo Kotlin.

Klient používá Content-Type pro výběr obsluhy. Pokud server vrací text/html, prohlížeč spouští HTML parser a buduje DOM strom. Pokud image/png — spouští PNG dekodér. Pokud Content-Type chybí nebo je nesprávný, klient aplikuje MIME sniffing — pokouší se uhodnout typ podle signatury (magic bytes) na začátku souboru. JPEG začíná bajty FF D8 FF, PNG — 89 50 4E 47 a PDF — 25 50 44 46. Tento proces je potenciálně nebezpečný a je vypnut hlavičkou X-Content-Type-Options: nosniff.

V mobilních aplikacích je Content-Type zpracováván HTTP klienty. OkHttp na Androidu automaticky analyzuje hlavičku Content-Type z odpovědi a poskytuje ji prostřednictvím metody Response.header("Content-Type"). iOS klient URLSession dělá totéž prostřednictvím vlastnosti URLResponse.mimeType. Na obou platformách se Content-Type používá pro výběr parseru: JSON — přes Moshi nebo Gson na Androidu, přes Codable na iOS; obrázky — přes Glide, Coil nebo SDWebImage.

Content Negotiation pomocí Accept a Content-Type

Content negotiation (vyjednávání obsahu) — HTTP mechanismus, ve kterém klient uvádí požadovaný formát odpovědi pomocí hlavičky Accept a server vybírá vhodný formát a vrací jej s odpovídajícím Content-Type. Například klient posílá Accept: application/json, server odpovídá Content-Type: application/json. Pokud server nemůže poskytnout požadovaný formát, vrací 406 Not Acceptable. V REST API tento mechanismus umožňuje jednomu endpointu vracet data v JSON, XML nebo HTML.

Content-Type v požadavcích a odpovědích

Hlavička Content-Type se používá jak v HTTP požadavcích (Request), tak v HTTP odpovědích (Response). V požadavcích určuje formát těla požadavku, například při odesílání JSON přes POST. V odpovědích — formát vracených dat. Zásadní rozdíl je v tom, že Content-Type požadavku nastavuje klient, zatímco Content-Type odpovědi — server. Nesprávné nastavení Content-Type v požadavku vede k tomu, že server nemůže parsovat tělo a vrací chybu 400 Bad Request nebo 415 Unsupported Media Type.

V HTTP požadavcích je Content-Type povinný pro metody POST, PUT a PATCH, pokud požadavek obsahuje tělo (body). GET, HEAD a DELETE obvykle tělo nepoužívají, proto se Content-Type pro ně neuvádí nebo je ignorován. Při odesílání HTML formuláře s atributem enctype="multipart/form-data" prohlížeč automaticky nastaví Content-Type: multipart/form-data s jedinečným hraničním řetězcem (boundary), který odděluje části složeného požadavku. Každá část je oddělena --boundary a konec požadavku je označen --boundary--.

V HTTP odpovědích je Content-Type nastaven serverem. Pokud server neuvede Content-Type, klient buď zapne MIME sniffing, nebo zpracuje odpověď jako application/octet-stream. HTTP metoda HEAD umožňuje získat hlavičky odpovědi, včetně Content-Type, bez přenosu těla. To je užitečné pro kontrolu typu zdroje před jeho plným načtením. CDN servery mohou přepsat Content-Type při transformaci obsahu — například při konverzi obrázků na 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("Typ: ${mediaType?.type}, Podtyp: ${mediaType?.subtype}")
    }
}

Content-Type v mobilních HTTP klientech

V mobilním vývoji je hlavička Content-Type zpracovávána automaticky HTTP klienty. V OkHttp na Androidu se Content-Type nastavuje přes RequestBody: val body = "{}".toRequestBody("application/json".toMediaType()). Retrofit spravuje Content-Type prostřednictvím anotací: @Body pro JSON, @Part pro multipart. Na iOS URLSession nastavuje Content-Type pro HTTPBody a Alamofire to dělá přes parametr encoding: JSONEncoding.default nebo URLEncoding.default. Ruční nastavení Content-Type je vyžadováno při práci s raw sockety nebo vlastními protokoly.

Chyby při práci s Content-Type

Nesprávný Content-Type — jeden z nejčastějších problémů při vývoji a integraci webových služeb. Nejčastější chybou je, když server vrací text/html místo application/json. Klient obdrží JSON jako HTML řetězec, nemůže jej parsovat a vyhodí výjimku. K tomu dochází, když je webový framework výchozí na HTML a vývojář zapomene přepsat Content-Type pro API endpoint. V PHP se to projevuje absencí header('Content-Type: application/json'), v Spring Boot — absencí anotace produces.

Druhou nejčastější chybou je nesprávný nebo chybějící charset. Pokud server pošle text/html; charset=iso-8859-1 a prohlížeč očekává UTF-8, cyrilické znaky se zobrazí zkomoleně. Tento problém je typický pro staré weby, které nepřešly na UTF-8. Pro JSON se taková chyba vyskytuje méně často, protože RFC 8259 předepisuje UTF-8 bez dodatečné dohody. Řešením je vždy explicitně uvádět charset=utf-8 pro textové MIME typy v konfiguraci serveru.

Třetí problém — nesoulad Content-Type se skutečným obsahem. Pokud server pošle Content-Type: image/png, ale tělo odpovědi obsahuje obrázek WebP, prohlížeč jej nemusí dekódovat. CDN servery někdy komprimují obrázky se změnou formátu, ale neaktualizují hlavičku Content-Type. Kontrola shody Content-Type se skutečným obsahem je povinnou fází testování API a integračního testování mobilních aplikací.

Diagnostika a oprava chyb Content-Type

Pro ladění používejte vývojářské nástroje prohlížeče (záložka Network), curl s příznakem -I pro kontrolu hlaviček odpovědi nebo sniffery provozu jako Charles Proxy a Wireshark. Nginx se konfiguruje pomocí direktivy include mime.types, Apache — pomocí AddType a AddDefaultCharset. U statických souborů vždy kontrolujte, zda přípona souboru odpovídá jeho MIME typu. Pro dynamické odpovědi ve všech programovacích jazycích explicitně nastavujte Content-Type před výpisem dat — to zabraňuje drtivé většině problémů.