Slovník pojmů

MIME typ

MIME typ určuje, jaký druh obsahu zpráva nebo soubor představuje. Pomáhá vybrat správný parser, vykreslení či způsob stažení, ale není bezpečnostním důkazem obsahu ani oprávnění k jeho otevření.

Stručná definice

Dohoda o formátu obsahu, ne pouhá přípona souboru.

Název MIME vznikl z Multipurpose Internet Mail Extensions, ale dnes se častěji používá obecnější termín media type. Zápis má podobu type/subtype, například text/html, application/json nebo image/png. Může mít také parametr, typicky charset=utf-8, který u textového obsahu upřesňuje znakové kódování.

Ve webové komunikaci server obvykle posílá Content-Type v HTTP odpovědi a klient uvádí Content-Type u request body. Hlavička Accept naopak vyjadřuje, jaké podoby odpovědi klient umí zpracovat. Tyto údaje dávají komunikaci společný jazyk, ale aplikace stále validuje data, velikost a oprávnění samostatně.

Jaký problém řeší

Aby obě strany věděly, jak tělo zprávy nebo soubor interpretovat.

Bez informace o typu by prohlížeč, API klient i server musely formát obsahu odhadovat podle souboru nebo vlastního pravidla.

prohlížeč rozliší HTML dokument, CSS, JavaScript, obrázek, písmo a soubor ke stažení
API zvolí JSON nebo XML parser a může odmítnout tělo v nepodporovaném formátu
upload služba určí pravidla pro dokument, obrázek nebo jiný přípustný soubor
export objednávek sdělí, zda odpověď tvoří CSV, PDF nebo JSON s chybou
HTTP cache a bezpečnostní pravidla pracují se skutečným typem vraceného obsahu

Praktický příklad

JSON API a export objednávek používají rozdílné typy odpovědi.

Administrace požádá API o detail objednávky a očekává JSON. Jiný endpoint nabízí export účetnímu; tam je vhodné označit soubor například text/csv s kódováním UTF-8. Klient nemá odhadovat obsah jen z názvu souboru nebo URL cesty.

Pokud uploadovaný soubor deklaruje image/png, server ještě provede vlastní kontrolu podle pravidel služby. Chybějící nebo podvržená hlavička tak nezmění nepřípustný soubor na bezpečný obrázek.

HTTP

GET /api/orders/ord_8f2c HTTP/1.1
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

Jak funguje

Typ obsahu propojí HTTP zprávu s odpovídajícím zpracováním.

Označení typu je metadata. Správný postup ověřuje hlavičku i skutečná data podle rizika konkrétní operace.

Klient uvede očekávání Například Accept: application/json říká API, že klient očekává JSON. Server nemusí každé přání splnit, ale má odpovědět předvídatelně.
Odesílatel popíše tělo Request s JSONem nese Content-Type: application/json. U formulářového uploadu se běžně používá multipart/form-data s oddělenými částmi.
Server vybere parser Endpoint přijme jen formáty, které jeho kontrakt podporuje. Poté řeší syntaxi, limity velikosti, datové typy a autorizaci.
Odpověď nese vlastní typ API může vrátit application/json, export text/csv a produktový obrázek image/jpeg. Prohlížeč podle typu zvolí vhodné zacházení.
Klient obsah bezpečně zpracuje Typ pomáhá vybrat postup, nesmí však vést k bezmeznému spuštění nebo zobrazení nedůvěryhodného obsahu.

Důležité pojmy

Type, subtype, parametr a vyjednání odpovědi.

Běžné příklady jsou registrované u IANA, ale jejich použití vždy určuje i kontrakt konkrétního endpointu.

Content-Type

Hlavička popisuje formát těla právě přenášené zprávy. V odpovědi například text/html; charset=utf-8, v API application/json.

Accept

Hlavička požadavku vyjadřuje přijatelné typy odpovědi. Není totéž co Content-Type: nepopisuje odesílané body, ale preference klienta.

Text a znakové kódování

text/html, text/css a další textové typy mohou potřebovat charset. UTF-8 je pro moderní web obvyklá volba, ale typ a kódování jsou dvě rozdílné informace.

Media type a přípona

Přípona .png nebo .json je užitečná nápověda pro člověka a systém souborů. Server ji ale nemá považovat za důkaz obsahu, protože ji lze snadno změnit.

Obecná binární data

application/octet-stream označuje neurčená binární data. Neříká, že je soubor bezpečný, ani jak jej bezpečně otevřít nebo komu jej zpřístupnit.

Vztah k podobným pojmům

MIME typ popisuje formát; HTTP přenáší zprávu a API určuje její význam.

Tato hranice brání omylu, že typ obsahu sám zaručuje validní data či bezpečný upload.

HTTP hlavička: Content-Type a Accept jsou HTTP hlavičky. MIME typ je jejich běžná hodnota, nikoli celý mechanismus HTTP komunikace.
JSON a XML: JSON a XML jsou konkrétní datové formáty, které mohou být přeneseny jako application/json a application/xml. Platnost formátu nepopisuje business pravidla.
HTML a prohlížeč: Prohlížeč na základě text/html interpretuje dokument jako webovou stránku. Chybný typ může pokazit vykreslení nebo bezpečnostní očekávání.
API: API vedle formátu určuje endpoint, metodu, schéma, oprávnění a chybové odpovědi. Media type je jen jedna část kontraktu.

Výhody a omezení

Jasnější komunikace bez falešného pocitu bezpečí.

Přínosy

klient může zvolit správný parser nebo způsob zobrazení
server může odmítnout nepodporovaný formát před zbytečným zpracováním
dokumentace API je konkrétnější a exporty jsou pro uživatele předvídatelné
standardizované hodnoty zlepšují interoperabilitu mezi aplikacemi

Omezení a chyby

přípona souboru ani Content-Type poslaný klientem nejsou spolehlivý důkaz skutečného formátu
nesprávná hlavička může nechat prohlížeč obsah zobrazit nebo stáhnout jinak, než aplikace čeká
typ obsahu nevaliduje schéma JSONu, XML ani business pravidla
upload bez limitů, antivirové kontroly podle rizika a serverového ověření formátu zůstává nebezpečný
Content-Type nenahrazuje autentizaci a autorizaci souboru nebo endpointu

Praktické použití

Pro API i soubory používat přesné hodnoty a předvídatelné chyby.

Endpoint pro vytvoření objednávky může přijímat jen application/json a při jiném typu vrátit srozumitelnou chybu. Endpoint pro export naopak může podle explicitně podporovaného Accept vrátit text/csv nebo application/pdf. V obou případech je užitečné dokumentovat typ, kódování, velikostní limity a chování při neplatném těle.

U uploadu nestačí věřit hlavičce prohlížeče. Aplikace omezuje velikost, kontroluje skutečné signatury či obsah vhodným serverovým nástrojem, ukládá soubory mimo veřejný document root a rozhoduje o stažení podle oprávnění. Při zobrazování uživatelem nahraného obsahu je bezpečnější zvolit oddělenou doménu, bezpečné hlavičky nebo vynucené stažení podle konkrétního rizika.

Na co myslet

Formát kontrolovat na hranici systému a posílat ho konzistentně.

Nejvíce problémů vzniká tehdy, když název souboru, HTTP hlavička, skutečná data a dokumentace říkají něco jiného.

u API uvádět podporovaný Content-Type a Accept v kontraktu a testovat nepodporovaný formát
posílat JSON jako application/json a XML jako application/xml, nikoli spoléhat na příponu URL
u textového obsahu konzistentně používat a dokumentovat UTF-8
u uploadu ověřovat více vlastností souboru a nepouštět ho automaticky do aktivního zobrazení
neukládat citlivé exporty do veřejně přístupné cesty jen proto, že mají správný MIME typ
logovat metadata s ohledem na soukromí a nezapisovat bezdůvodně celý obsah requestu

Časté otázky

MIME typ v praxi

Je MIME typ totéž co přípona souboru?

Ne. Přípona je součást názvu souboru, MIME typ popisuje formát obsahu. Příponu i klientem odeslanou hlavičku lze změnit, proto je server nemá brát jako jedinou kontrolu.

Jaký je rozdíl mezi Content-Type a Accept?

Content-Type popisuje tělo právě odesílané zprávy. Accept vyjadřuje, které typy odpovědi klient dokáže nebo chce přijmout.

Je application/octet-stream bezpečný typ?

Ne. Označuje neurčená binární data. Nevypovídá o bezpečnosti, oprávnění ani konkrétním formátu souboru.

Stačí ověřit MIME typ uploadu v prohlížeči?

Nestačí. Kontroly v prohlížeči jsou pohodlí uživatele; server musí podle rizika ověřit velikost, skutečný obsah, uložení a pravidla přístupu.

Jak pracuji s API a výměnou dat

Přenosový formát propojuji s kontraktem, validací a bezpečným zpracováním.

U API a integračních scénářů řeším vedle typu obsahu také kompatibilitu, autentizaci a srozumitelné chybové stavy.

Jak pracuji s API a integracemi Nezávazně probrat projekt