Setiap kali browser kamu berbicara dengan sebuah situs, yang dikirim bukan cuma “tolong kasih halaman ini.” Menempel di permintaan sederhana itu ada sekumpulan informasi tambahan: format apa yang bisa kamu terima, siapa kamu, apakah kamu pernah ke sini sebelumnya, dan selusin detail lain. Sekumpulan informasi itu disusun dari HTTP header, dan begitu kamu paham, banyak perilaku web yang tadinya terasa misterius mendadak jadi masuk akal.
Di panduan ini kita akan membongkar apa itu header, apa beda request header dengan response header, dan segelintir header umum yang akan terus kamu temui. Tidak perlu pengalaman sebelumnya — setiap istilah akan kita jelaskan begitu muncul.
Apa sebenarnya sebuah header itu
Sebuah pesan HTTP — entah itu request yang dikirim browser atau response yang dibalas server — terdiri dari dua bagian: body (isi sesungguhnya, misalnya HTML sebuah halaman atau data yang kamu kirim) dan sekumpulan header yang mendeskripsikan isi tersebut beserta konteks percakapannya.
Sebuah header sederhananya cuma sepasang key dan value yang dipisahkan tanda titik dua. Bayangkan seperti label di kotak paket. Kotaknya menyimpan barang (body), tapi labelnya memberi tahu alamat tujuan, seberapa mudah pecah, dan bagaimana harus diperlakukan. Header adalah label semacam itu untuk lalu lintas web.
Kira-kira beginilah wujud sebuah request kalau ditulis sebagai teks biasa:
GET /articles HTTP/1.1
Host: blog.acy-partner.com
User-Agent: Mozilla/5.0
Accept: text/html
Accept-Language: id-ID
Connection: keep-aliveBaris pertama adalah request-nya sendiri (metode dan path). Semua yang ada di bawahnya, sampai sebelum baris kosong, adalah header — satu per baris, masing-masing berbentuk Key: Value. Server membaca semua ini untuk menentukan cara menjawab.
Header bukan body
Header mendeskripsikan pesan; ia bukan isi dari pesan itu. Saat kamu mengirim formulir, nama dan email kamu masuk ke body. Informasi tentang pengiriman itu — seperti formatnya dan ukurannya — masuk ke header.
Request header vs response header
Kedua sisi percakapan sama-sama memakai header, tapi yang mereka sampaikan berbeda.
Request header berjalan dari klien (browser kamu, aplikasi ponsel, atau sebuah skrip) menuju server. Isinya kebanyakan mendeskripsikan siapa yang meminta dan apa yang sanggup ia tangani. Misalnya, browser kamu memberitahukan bahasa dan format apa yang ia sukai supaya server bisa menyesuaikan balasannya.
Response header berjalan kembali dari server ke klien. Isinya mendeskripsikan apa yang dikirim dan bagaimana memperlakukannya — format datanya, apakah boleh disimpan dalam cache, cookie apa yang perlu disimpan, dan seterusnya.
Beginilah gambaran perjalanan bolak-baliknya:
┌─────────┐ request + request header ┌─────────┐
│ Browser │ ─────────────────────────────► │ Server │
│ (klien) │ ◄───────────────────────────── │ │
└─────────┘ response + response header └─────────┘Beberapa nama header bisa muncul di dua arah, tapi sebagian besar punya tempat alaminya di salah satu sisi. Mari kita lihat header yang benar-benar akan sering kamu temui.
Header umum, dijelaskan satu per satu
Content-Type
Content-Type memberitahu penerima format dari body, supaya ia tahu cara mengartikan deretan byte itu. Sebuah halaman web dibalas sebagai text/html; sebuah API sering membalas dengan application/json; sebuah gambar bisa jadi image/png.
Content-Type: application/jsonHeader ini penting di kedua arah. Saat kamu mengirim data ke server, Content-Type kamu memberitahu cara membaca body-mu. Saat server membalas, Content-Type miliknya memberitahu browser apakah yang dilihat itu halaman untuk ditampilkan, berkas untuk diunduh, atau data untuk diproses.
Content-Type yang salah merusak diam-diam
Kalau server melabeli data JSON sebagai text/plain, browser bisa memperlakukannya sebagai teks mentah alih-alih data terstruktur, dan kode kamu yang menunggu JSON jadi tidak dapat apa-apa yang berguna. Header-nya harus cocok dengan isi sebenarnya.
Content-Length
Content-Length menyatakan ukuran body, dalam satuan byte. Ini membuat penerima tahu persis berapa banyak data yang harus ia harapkan, sehingga ia bisa tahu kapan sebuah pesan sudah lengkap.
Content-Length: 1024Kamu jarang mengaturnya sendiri — biasanya alat menghitungkannya untukmu — tapi bagus untuk bisa mengenalinya saat melihatnya.
Authorization
Authorization adalah cara sebuah request membuktikan dirinya atau bahwa ia memang diizinkan masuk. Pola yang sangat umum adalah bearer token: sebuah string panjang yang diberikan server setelah kamu login, lalu kamu tempelkan di request-request berikutnya.
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...Tanpa header ini, sebuah endpoint terproteksi biasanya akan menolak menjawab. Karena ia membawa kredensial, header ini hanya boleh dikirim lewat koneksi terenkripsi (HTTPS), tidak pernah lewat HTTP biasa.
User-Agent
User-Agent adalah deskripsi-diri yang dikirim klien tentang dirinya sendiri — browser atau program beserta versinya. Server kadang memakainya untuk menyesuaikan response, misalnya menyajikan tata letak yang ramah ponsel.
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)Sifatnya sekadar informasi dan mudah dipalsukan, jadi ia tidak pernah menjadi fitur keamanan — cuma sebuah petunjuk.
Accept
Accept adalah cara klien dengan sopan menyebut format apa yang ingin ia terima kembali. Server berusaha menghormatinya, tapi tidak wajib.
Accept: application/jsonKalau kamu meminta application/json ke sebuah API, server yang berperilaku baik akan memberimu JSON. Anggap Accept sebagai pasangan di sisi request dari Content-Type di response: yang satu bilang “ini yang aku mau,” yang lain bilang “ini yang benar-benar aku kirim.”
Cache-Control
Cache-Control mengatur caching — apakah dan berapa lama sebuah response boleh disimpan lalu dipakai ulang alih-alih diambil lagi. Caching membuat situs lebih cepat dengan menghindari unduhan berulang.
Cache-Control: max-age=3600, publicContoh itu mengatakan response boleh disimpan selama 3600 detik (satu jam) dan boleh disimpan oleh cache bersama. Kebalikannya yang ekstrem, no-store, menyuruh semua pihak untuk tidak pernah menyimpan salinan — berguna untuk data sensitif atau yang selalu berubah.
Set-Cookie
Set-Cookie adalah response header tempat server meminta browser untuk mengingat sepotong kecil data dan mengirimkannya kembali di request berikutnya. Inilah cara sebuah situs membuatmu tetap login saat berpindah halaman.
Set-Cookie: session_id=abc123; HttpOnly; SecureBrowser menyimpan cookie itu dan otomatis menyertakannya (lewat request header Cookie) pada request berikutnya ke situs yang sama. Penanda HttpOnly dan Secure di atas memperkuatnya: HttpOnly menyembunyikannya dari skrip halaman, dan Secure hanya mengirimnya lewat HTTPS.
Location
Location muncul pada response berupa redirect (pengalihan). Saat server membalas dengan kode status di rentang 3xx — misalnya “halaman ini sudah pindah” — header Location memberitahu browser harus pergi ke mana sebagai gantinya.
Location: https://blog.acy-partner.com/new-urlBrowser membacanya lalu diam-diam membuat request baru ke alamat itu, itulah sebabnya kadang kamu melihat URL berubah dengan sendirinya.
Tabel rujukan singkat
Berikut header-header tadi disandingkan, lengkap dengan arah tempat kamu biasanya menemukannya dan kegunaannya.
| Header | Biasanya di | Kegunaannya |
|---|---|---|
Content-Type |
keduanya | Menyatakan format body (HTML, JSON, gambar) |
Content-Length |
keduanya | Ukuran body dalam byte |
Authorization |
request | Membawa kredensial, misalnya bearer token |
User-Agent |
request | Mengidentifikasi klien (browser/aplikasi) |
Accept |
request | Format yang ingin diterima klien |
Cache-Control |
keduanya | Aturan caching untuk response |
Set-Cookie |
response | Meminta browser menyimpan data |
Location |
response | Tujuan redirect yang harus diikuti browser |
Melihat header dengan mata kepala sendiri
Kamu tidak butuh perangkat lunak khusus untuk memeriksa header. Buka developer tools di browser (biasanya tombol F12), masuk ke tab Network, muat ulang halaman, lalu klik salah satu request di daftar. Kamu akan melihat request header dan response header-nya tersusun persis seperti contoh-contoh di atas.
Dari terminal, satu perintah saja sudah menampilkan response header untuk sebuah URL:
curl -I https://blog.acy-partner.comPenanda -I meminta header saja, tanpa body. Ini cara cepat untuk mengecek hal seperti Content-Type dan Cache-Control yang benar-benar dikirim sebuah situs.
Rangkuman
Header adalah metadata-nya web — label kecil berbentuk Key: Value yang menempel di setiap request dan response, mendeskripsikan percakapan tanpa menjadi bagian dari isinya. Begini gambaran besarnya:
- Sebuah pesan HTTP punya body (isinya) dan header (label yang mendeskripsikannya).
- Request header menyebut siapa yang meminta dan apa yang ia sanggup tangani; response header menyebut apa yang dikirim dan bagaimana memperlakukannya.
- Beberapa nama saja sudah menutupi sebagian besar situasi:
Content-TypedanContent-Lengthmendeskripsikan body;Authorization,User-Agent, danAcceptmenumpang di request;Cache-Control,Set-Cookie, danLocationmembentuk response.
Begitu header sudah terasa pas, langkah berikutnya yang alami adalah bagian lain dari sebuah response: kode status — angka tiga digit seperti 200, 404, dan 301 yang dalam sekejap memberitahumu bagaimana hasil sebuah request. Padukan header dengan kode status, dan kamu bisa membaca hampir semua pertukaran HTTP dengan percaya diri.
