Content-Type a webfejlesztésben: mi ez, MIME-típusok és hogyan működik

Mi az a Content-Type?

Content-Type — egy HTTP-fejléc a reprezentációs fejlécek (representation headers) csoportjából, amely tájékoztatja a címzettet az üzenet törzsében lévő adatok formátumáról. Kötelező a törzset (body) tartalmazó HTTP-kérésekhez és -válaszokhoz, és nélküle a kliens nem tudja helyesen értelmezni a kapott bájtokat. A böngésző vagy mobilalkalmazás a Content-Type alapján választja ki az elemzőt: a text/html számára elindítja a HTML-motort, az image/png számára — a PNG-dekódert, az application/json számára — a JSON-elemzőt.

A Content-Type értéke egy MIME-típus — az adatformátum szabványosított azonosítója. A MIME rövidítés a Multipurpose Internet Mail Extensions kifejezést jelenti, mivel ezt a szabványt eredetileg e-mail mellékletekhez hozták létre. Azonban a HTTP alapjává vált, és ma már mindenhol használják — a weboldalak továbbításától a REST API adatcseréjéig. Minden MIME-típus két részből áll: egy fő kategóriából és egy pontosító altípusból, perjellel elválasztva.

A charset paraméter kiegészíti a Content-Type-ot szöveges formátumokhoz. Például a Content-Type: text/html; charset=utf-8 azt jelenti, hogy egy HTML-dokumentum UTF-8 kódolásban kerül továbbításra. Az IETF RFC 7231, 3.1.1.5. szakasza szerint a Content-Type fejléc kötelező a törzset tartalmazó HTTP-üzenetekhez, és hiánya application/octet-stream-ként értelmeződik, vagy MIME sniffinghez vezet.

A MIME-típusok megjelenésének története a HTTP-ben

Az 1991-ben kiadott HTTP/0.9 protokoll csak HTML-oldalakat továbbított, így az adattípus alapértelmezett volt. A HTTP/1.0 megjelenésével az RFC 1945 specifikációban a fejlesztők felismerték a képek, stíluslapok és szkriptek továbbításának szükségességét. Adaptálták a MIME szabványt az e-mail protokollból, és a Content-Type a HTTP elválaszthatatlan részévé vált. Azóta az IANA nyilvántartás több száz értékre bővült — az ismert text/html-től a modern image/avif és application/manifest+json típusokig.

A Content-Type szerepe a biztonságban

Content-Type kritikus szerepet játszik a támadások elleni védelemben. Ha a szerver egy HTML-fájlt a text/plain MIME-típussal küld, a böngésző nem fogja végrehajtani a JavaScriptet és nem építi fel a DOM-ot — ez megakadályozza az XSS-támadásokat. Az OWASP által javasolt X-Content-Type-Options: nosniff fejléc teljesen megtiltja a böngészőnek, hogy a tartalom alapján kitalálja a MIME-típust. A PortSwigger Research szerint a MIME sniffinget használó támadások különösen elterjedtek voltak az Internet Explorer 6-9-ben, ahol a böngésző figyelmen kívül hagyta a Content-Type-ot, és a fájl első bájtjai alapján határozta meg a típust.

A MIME-típus felépítése

A MIME-típus type/subtype formátumban van megadva, ahol a type az adatok általános kategóriája, a subtype pedig a konkrét formátum azon belül. Például az image/png értékben az image kategória egy képre, a png altípus pedig a Portable Network Graphics formátumra utal. Csak néhány kategória létezik: text, image, audio, video, application, multipart és message. A fennmaradó változatosságot az altípusok biztosítják, amelyekből több száz van.

További paraméterek pontosvesszővel kerülnek átadásra az altípus után. A legelterjedtebb paraméter a charset a kódolás megadásához. A Content-Type: application/json; charset=utf-8 jelzi, hogy egy JSON-dokumentum UTF-8 kódolásban kerül továbbításra. Formálisan a charset az application/json számára felesleges, mivel a JSON az RFC 8259 specifikáció szerint mindig UTF-8-ban van, de az explicit megadás javítja a kompatibilitást a régebbi HTTP-kliensekkel.

Szabványos és nem szabványos MIME-típusok

Szabványos MIME-típusok az IANA nyilvántartásban vannak regisztrálva, és a fő kategória előtagjával rendelkeznek. A nem szabványos (vendor-specific) típusok az x- előtagot vagy a vnd.company.type formátumot használják — például application/vnd.google-earth.kml+xml a Google KML formátumához. A böngészők nem biztos, hogy felismerik a nem szabványos típusokat, ezért az ismeretlen mellékletekhez application/octet-stream használatos — egy univerzális bináris adatfolyam, amelyet a böngésző nem próbál meg megjeleníteni, hanem fájlként kínál letöltésre.

A charset paraméter a gyakorlatban

A charset paraméter kritikus a szöveg helyes megjelenítéséhez. Nélküle a böngésző helytelenül értelmezheti a karaktereket, ami mojibake (torz karakterek) megjelenéséhez vezet. A webes szabvány az UTF-8, de előfordul ISO-8859-1 (Latin-1) a nyugat-európai nyelvekhez és windows-1251 a cirill betűkhöz régi webhelyeken. A W3C ajánlása — mindig adja meg a charset=utf-8-at a text/html és text/plain típusokhoz, az application/json esetében a charset nem szükséges.

A Content-Type fő típusai

A gyakorlatban a webfejlesztők és a mobilfejlesztők korlátozott MIME-típus készlettel dolgoznak. Ezen típusok ismerete szükséges a szerver helyes konfigurálásához, HTTP-kliensek írásához és statikus fájlok feldolgozásához. text/html — a weboldalak elsődleges típusa, amelyet az Apache és Nginx szerverek alapértelmezés szerint visszaadnak a HTML-fájlokhoz. Az application/xhtml+xml ritkábban használatos, és csak XHTML-dokumentumokhoz.

application/json a REST API szabványává vált. A szerverek JSON-adatokat ezzel a MIME-típussal adják vissza, a kliensek pedig POST és PUT kérésekben küldik. A text/javascript (elavult) és application/javascript a JavaScript-fájlokhoz használatos. A W3Techs Survey, 2025 szerint a JSON a leggyorsabban növekvő adatformátum a weben, megelőzve az XML-t 2018-ban. A SOAP-szolgáltatásokhoz még mindig text/xml vagy application/soap+xml használatos.

A képek MIME-típusát a fájlformátum határozza meg: image/jpeg a JPEG-hez, image/png a PNG-hez, image/gif a GIF-hez, image/webp a modern WebP formátumhoz. Az image/svg+xml vektorgrafikához használatos, és támogatja a beágyazott stílusokat és szkripteket. A video/mp4, audio/mpeg és application/pdf — más gyakran előforduló típusok. A webfontokhoz font/woff2, font/woff és font/ttf használatos.

Content-Type fájlfeltöltéskor

Fájlok HTML-űrlapon keresztül történő küldésekor multipart/form-data használatos — egy összetett MIME-típus, amely több részre osztja a kérést. Minden résznek saját Content-Type és Content-Disposition fejléce van, amely megadja a mező nevét és a fájl eredeti nevét. A szerver a fájlt a tényleges MIME-típusával kapja meg, amelyet a böngésző határozott meg, és ellenőrizheti azt a backend oldalon. Az application/octet-stream ismeretlen típusú fájlokhoz alkalmazandó — a böngésző nem próbálja megjeleníteni a tartalmat, hanem felajánlja a lemezre mentést.

A Content-Type hatása a gyorsítótárazásra

A MIME-típus befolyásolja a CDN és a böngésző gyorsítótárazási politikáját. A stabil URL-lel rendelkező képek általában hosszú ideig (egy év és tovább) kerülnek gyorsítótárazásra, míg a HTML-oldalak — percekig vagy másodpercekig. CDN-szerverek A Cloudflare és az Akamai a Content-Type-ot használja a tömörítési algoritmus kiválasztásához: a text/* gzip vagy brotli tömörítést kap, az image/* — nem, mivel a képek már tömörítettek. A Content-Type helyes konfigurálása a szerveren közvetlenül befolyásolja az oldalak és mobilalkalmazások betöltési teljesítményét.

Hogyan használja a szerver és a kliens a Content-Type-ot

A szerver beállítja a Content-Type fejlécet a HTTP-válaszban a kért fájl típusa vagy a dinamikusan generált tartalom alapján. A népszerű Nginx és Apache webszerverek beépített MIME-típus táblázatokkal rendelkeznek, amelyek a fájlkiterjesztést a megfelelő Content-Type-hoz rendelik. Például az index.html fájl text/html-t, a style.css pedig text/css-t kap. Dinamikus válaszokhoz a fejlesztő állítja be a Content-Type-ot az alkalmazás kódjában PHP, Python, Java vagy Kotlin nyelven.

A kliens a Content-Type-ot használja a kezelő kiválasztásához. Ha a szerver text/html-t ad vissza, a böngésző elindítja a HTML-elemzőt és felépíti a DOM-fát. Ha image/png — elindítja a PNG-dekódert. Ha a Content-Type hiányzik vagy helytelen, a kliens MIME sniffinget alkalmaz — megpróbálja kitalálni a típust a fájl elején lévő aláírás (magic bytes) alapján. A JPEG az FF D8 FF bájtokkal kezdődik, a PNG — a 89 50 4E 47-tel, a PDF pedig — a 25 50 44 46-tal. Ez a folyamat potenciálisan veszélyes, és az X-Content-Type-Options: nosniff fejléc kikapcsolja.

Mobilalkalmazásokban a Content-Type-ot a HTTP-kliensek dolgozzák fel. OkHttp Androidon automatikusan elemzi a Content-Type fejlécet a válaszból, és a Response.header("Content-Type") metóduson keresztül biztosítja. Az iOS kliens URLSession ugyanezt teszi az URLResponse.mimeType tulajdonságon keresztül. Mindkét platformon a Content-Type-ot használják az elemző kiválasztásához: JSON — Moshi vagy Gson segítségével Androidon, Codable segítségével iOS-en; képek — Glide, Coil vagy SDWebImage segítségével.

Tartalom egyeztetés Accept és Content-Type segítségével

Content negotiation (tartalom egyeztetése) — egy HTTP-mechanizmus, amelyben a kliens az Accept fejlécen keresztül jelzi a kívánt válaszformátumot, a szerver pedig kiválasztja a megfelelő formátumot, és visszaadja a megfelelő Content-Type-tal. Például a kliens elküldi az Accept: application/json-t, a szerver Content-Type: application/json-nal válaszol. Ha a szerver nem tudja biztosítani a kért formátumot, 406 Not Acceptable-t ad vissza. A REST API-ban ez a mechanizmus lehetővé teszi, hogy egyetlen endpoint JSON, XML vagy HTML formátumban adjon vissza adatokat.

Content-Type a kérésekben és válaszokban

A Content-Type fejlécet mind a HTTP-kérésekben (Request), mind a HTTP-válaszokban (Response) használják. Kérésekben a kérés törzsének formátumát adja meg, például JSON POST-on keresztül történő küldésekor. Válaszokban — a visszaadott adatok formátumát. Az alapvető különbség az, hogy a kérés Content-Type-ját a kliens, a válasz Content-Type-ját pedig a szerver állítja be. A Content-Type helytelen beállítása a kérésben azt eredményezi, hogy a szerver nem tudja elemezni a törzset, és 400 Bad Request vagy 415 Unsupported Media Type hibát ad vissza.

HTTP-kérésekben a Content-Type kötelező a POST, PUT és PATCH metódusokhoz, ha a kérés törzset (body) tartalmaz. A GET, HEAD és DELETE általában nem használ törzset, ezért a Content-Type számukra nincs megadva vagy figyelmen kívül van hagyva. HTML-űrlap enctype="multipart/form-data" attribútummal történő küldésekor a böngésző automatikusan beállítja a Content-Type: multipart/form-data-t egy egyedi határoló karakterlánccal (boundary), amely elválasztja az összetett kérés részeit. Minden részt a --boundary választ el, a kérés végét pedig a --boundary-- jelzi.

HTTP-válaszokban a Content-Type-ot a szerver állítja be. Ha a szerver nem ad meg Content-Type-ot, a kliens vagy bekapcsolja a MIME sniffinget, vagy application/octet-stream-ként dolgozza fel a választ. A HEAD HTTP-metódus lehetővé teszi a válasz fejléceinek, köztük a Content-Type-nak a lekérését a törzs továbbítása nélkül. Ez hasznos az erőforrás típusának ellenőrzéséhez a teljes betöltés előtt. CDN-szerverek felülírhatják a Content-Type-ot a tartalom átalakításakor — például képek WebP-be konvertálásakor.

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ípus: ${mediaType?.type}, Altípus: ${mediaType?.subtype}")
    }
}

Content-Type mobil HTTP-kliensekben

Mobilfejlesztésben a Content-Type fejlécet automatikusan feldolgozzák a HTTP-kliensek. Az OkHttp-ban Androidon a Content-Type a RequestBody-n keresztül állítható be: val body = "{}".toRequestBody("application/json".toMediaType()). A Retrofit a Content-Type-ot annotációkon keresztül kezeli: @Body a JSON-hoz, @Part a multiparthoz. iOS-en az URLSession beállítja a Content-Type-ot a HTTPBody számára, az Alamofire pedig ezt az encoding paraméteren keresztül teszi: JSONEncoding.default vagy URLEncoding.default. A Content-Type manuális beállítása nyers socketekkel vagy egyedi protokollokkal való munka során szükséges.

Hibák a Content-Type használatakor

Helytelen Content-Type — az egyik leggyakoribb probléma a webszolgáltatások fejlesztése és integrációja során. A leggyakoribb hiba, amikor a szerver text/html-t ad vissza application/json helyett. A kliens JSON-t kap HTML karakterláncként, nem tudja elemezni, és kivételt dob. Ez akkor történik, amikor a webes keretrendszer alapértelmezés szerint HTML-re van konfigurálva, és a fejlesztő elfelejti felülírni a Content-Type-ot az API-végponthoz. PHP-ben ez a header('Content-Type: application/json') hiányában, Spring Boot-ban pedig a produces annotáció hiányában nyilvánul meg.

A második leggyakoribb hiba a helytelen vagy hiányzó charset. Ha a szerver text/html; charset=iso-8859-1-et küld, és a böngésző UTF-8-at vár, a cirill betűk torzultan jelennek meg. Ez a probléma jellemző a régi webhelyekre, amelyek nem tértek át UTF-8-ra. JSON esetében ez a hiba ritkábban fordul elő, mivel az RFC 8259 további egyeztetés nélkül írja elő az UTF-8-at. Megoldás — mindig explicit módon adja meg a charset=utf-8-at a szöveges MIME-típusokhoz a szerver konfigurációjában.

A harmadik probléma — a Content-Type és a tényleges tartalom közötti eltérés. Ha a szerver Content-Type: image/png-t küld, de a válasz törzse WebP-képet tartalmaz, a böngésző előfordulhat, hogy nem tudja dekódolni. A CDN-szerverek néha tömörítik a képeket a formátum megváltoztatásával, de nem frissítik a Content-Type fejlécet. A Content-Type és a tényleges tartalom összhangjának ellenőrzése az API-tesztelés és a mobilalkalmazások integrációs tesztelésének kötelező szakasza.

Content-Type hibák diagnosztizálása és javítása

Hibakereséshez használja a böngésző fejlesztői eszközeit (Network lap), a curl-t az -I jelzővel a válaszfejlécek ellenőrzéséhez, vagy olyan forgalomfigyelőket, mint a Charles Proxy és a Wireshark. Nginx az include mime.types direktíván keresztül konfigurálható, az Apache — az AddType és AddDefaultCharset segítségével. Statikus fájlok esetén mindig ellenőrizze, hogy a fájlkiterjesztés megfelel-e a MIME-típusának. Dinamikus válaszok esetén minden programozási nyelvben explicit módon állítsa be a Content-Type-ot az adatok kiírása előtt — ez megakadályozza a problémák túlnyomó többségét.