Content-Type

Penggunaan

Header Content-Type memberi tahu klien (atau server, untuk badan permintaan) tipe media dari konten yang disertakan. Tipe media menentukan bagaimana penerima mengurai dan merender badan pesan. Tanpa header ini, klien beralih ke MIME sniffing, yang menimbulkan risiko keamanan dan perilaku yang tidak konsisten.

Catatan

Accept mendeklarasikan apa yang ingin diterima klien. Content-Type mendeklarasikan apa yang sedang dikirim. Accept muncul pada permintaan. Content-Type muncul baik pada permintaan (ketika badan pesan ada) maupun pada respons. Permintaan GET umumnya tidak memiliki badan pesan dan tidak memerlukan Content-Type. Permintaan POST dan PUT yang memiliki badan pesan membutuhkan header ini.

Sebuah tipe media terdiri atas tipe tingkat atas dan subtipe yang dipisahkan oleh garis miring, secara opsional diikuti oleh parameter. Header permintaan Accept bekerja berdampingan dengan Content-Type selama negosiasi konten, sehingga klien dapat menyatakan tipe media yang dipilihnya sebelum server menentukan salah satunya.

Server dan perantara terkadang menerapkan Content-Encoding (seperti gzip atau br) sebelum transmisi. Header Content-Type selalu menggambarkan tipe media asli sebelum pengodean, bukan format hasil pengodean.

Header MIME-Version berakar pada asal-usul tipe MIME di dunia surel dan muncul pada sebagian pesan HTTP, meskipun HTTP tidak mewajibkan header tersebut untuk pemrosesan tipe media.

media-type

Nilai tipe media mengikuti format type/subtype yang terdaftar di IANA. Tipe yang umum mencakup text/html, application/json, image/png, dan application/octet-stream. Registri lengkapnya dikelola oleh IANA.

charset

Parameter charset menentukan pengodean karakter untuk tipe media berbasis teks. UTF-8 adalah pengodean yang dominan di web.

Content-Type: text/html; charset=UTF-8

boundary

Parameter boundary wajib ada untuk tipe media multipart/*. String boundary memisahkan setiap bagian dari badan multipart. Nilai boundary tidak boleh muncul di dalam salah satu bagian badan pesan.

Content-Type: multipart/form-data; boundary=----FormBoundary

Contoh

Sebuah server mengembalikan halaman HTML dengan pengodean UTF-8. Browser menggunakan tipe media untuk merender konten sebagai halaman web dan charset untuk mendekode teks dengan benar.

Content-Type: text/html; charset=UTF-8

Sebuah API mengembalikan respons JSON. Tipe media application/json menginstruksikan klien untuk mengurai badan pesan sebagai JSON.

Content-Type: application/json

Sebuah respons error API menggunakan tipe media application/problem+json untuk menandakan payload detail masalah yang terstruktur.

Content-Type: application/problem+json

Sebuah CDN mengonversi halaman HTML menjadi Markdown secara langsung ketika klien mengirim Accept: text/markdown. Respons membawa text/markdown sebagai tipe kontennya, menandakan bahwa badan pesan adalah Markdown dan bukan HTML.

Content-Type: text/markdown; charset=utf-8

Agen AI dan Content-Type

Penyedia CDN seperti Cloudflare mengembalikan Content-Type: text/markdown bersama header x-markdown-tokens yang memperkirakan jumlah token dari dokumen hasil konversi. Agen menggunakan tipe konten untuk memilih parser yang tepat dan estimasi token untuk mengelola anggaran jendela konteks.

Sebuah unggahan berkas menggunakan multipart/form-data dengan string boundary yang memisahkan kolom formulir dan data berkas di dalam badan permintaan.

Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

Sebuah server mengirimkan unduhan berkas biner. Tipe application/octet-stream menandakan data biner mentah, sering dipasangkan dengan header Content-Disposition yang disetel ke attachment.

Content-Type: application/octet-stream

Sebuah respons multipart/byteranges mengirimkan beberapa rentang byte dari satu sumber daya. Setiap bagian memiliki header Content-Type dan Content-Range-nya sendiri.

Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

Pemecahan masalah

Kegagalan rendering dan error penguraian sering kali berakar pada header Content-Type yang hilang atau keliru.

Parameter charset yang hilang menyebabkan teks kacau. Browser kembali ke pengodean bawaan (sering kali ISO-8859-1) ketika tidak ada charset yang dideklarasikan. Karakter non-ASCII tampil sebagai mojibake. Tambahkan parameter charset secara eksplisit: Content-Type: text/html; charset=UTF-8. Pada nginx:

charset utf-8;

Pada Apache:

AddDefaultCharset UTF-8

Browser menerapkan MIME sniffing meskipun Content-Type sudah benar. Browser terkadang mengabaikan tipe yang dideklarasikan dan mengendus konten badan pesan untuk menentukan tipenya. Perilaku ini menciptakan celah serangan XSS ketika konten unggahan pengguna disajikan sebagai HTML. Tambahkan header X-Content-Type-Options yang disetel ke nosniff untuk memblokir MIME sniffing:

X-Content-Type-Options: nosniff

API mengembalikan text/html alih-alih application/json. Klien yang mengurai JSON dari sebuah API menerima halaman error HTML atau respons bawaan framework. Hal ini terjadi ketika penangan error atau reverse proxy mencegat respons dan mengganti badan pesan tanpa memperbarui Content-Type. Periksa seluruh rantai respons: server asal, framework aplikasi, reverse proxy, dan CDN. Pada Express.js, memanggil res.json() menyetel header yang benar secara otomatis. Pada Django, kembalikan JsonResponse alih-alih HttpResponse.

Ketidakcocokan boundary multipart merusak unggahan berkas. String boundary yang dideklarasikan pada header Content-Type harus cocok dengan pembatas yang digunakan di badan permintaan. Ketidakcocokan menyebabkan server gagal mengurai badan multipart. Periksa permintaan mentah di tab Network DevTools pada bagian Headers dan Payload. Hindari menyetel boundary secara manual ketika menggunakan fetch() atau XMLHttpRequest dengan objek FormData. Browser menghasilkan boundary yang benar secara otomatis ketika header Content-Type dihilangkan dari permintaan.

Content-Type bawaan framework menimpa setelan eksplisit. Sebagian framework menyetel Content-Type setelah kode aplikasi berjalan. Middleware pada Express.js, Django, atau Spring Boot dapat mengatur ulang header tersebut. Periksa urutan eksekusi middleware. Pada Express.js, pastikan res.type() atau res.set(‘Content-Type’, …) dipanggil setelah semua middleware yang memodifikasi header.

Mendiagnosis masalah Content-Type dengan DevTools. Buka tab Network DevTools browser, pilih permintaan tersebut, dan periksa bagian Response Headers untuk melihat nilai Content-Type. Bandingkan tipe yang dideklarasikan dengan konten badan pesan sebenarnya yang ditampilkan pada tab Response atau Preview. Gunakan curl -I https://example.re/api/data untuk memeriksa header dari baris perintah tanpa gangguan browser.