ETag: apa itu, mekanisme caching dan konfigurasi header

Apa itu ETag?

ETag (Entity Tag) — adalah header respons HTTP yang berisi pengidentifikasi unik dari versi tertentu sumber daya. Server menghitung ETag berdasarkan konten file, metadata, atau nomor revisi dan mengirimkannya ke klien dalam respons terhadap permintaan GET. Klien menyimpan pengidentifikasi ini dan pada permintaan berikutnya ke sumber daya yang sama mengirimkannya di header If-None-Match. Jika sumber daya tidak berubah, server merespons dengan 304 Not Modified, dan klien menggunakan salinan cache-nya.

Format ETag ditentukan dalam RFC 7232 sebagai string dalam tanda kutip: "33a64df551425fcc55e4d42a148795d9f25f89d4". Nilainya dapat berupa hash SHA-1 dari konten file, nomor versi inkremental, kombinasi inode-nomor-waktu untuk file statis, atau token arbitrer yang dihasilkan server. Satu-satunya persyaratan adalah nilainya harus berubah pada setiap perubahan sumber daya dan tidak berubah jika sumber daya tetap sama.

ETag termasuk dalam mekanisme permintaan bersyarat (conditional requests) — salah satu optimasi dasar protokol HTTP. Berbeda dengan permintaan tanpa syarat di mana server selalu mengembalikan respons lengkap, permintaan bersyarat memungkinkan klien memeriksa keaktualan cache tanpa mengunduh ulang data. Menurut data HTTP Archive (2025), sekitar 40% dari semua respons HTTP adalah 304 Not Modified berkat konfigurasi ETag dan Last-Modified yang benar.

Di mana ETag diterapkan

ETag digunakan di REST API untuk mengoptimalkan pemuatan koleksi data — jika daftar objek tidak berubah, klien menerima 304 tanpa mengirimkan seluruh JSON. Dalam file statis (CSS, JS, gambar) ETag memungkinkan CDN dan browser memeriksa keaktualan cache secara efisien. Dalam aplikasi mobile, ETag sangat penting untuk sinkronisasi latar belakang: aplikasi memeriksa apakah data di server telah berubah dan mengunduh pembaruan hanya jika diperlukan. Ini menghemat bandwidth dan baterai perangkat.

Bagaimana cara kerja ETag?

Siklus kerja lengkap ETag terdiri dari empat langkah. Server menghasilkan ETag pada permintaan pertama dan mengembalikannya di header respons. Klien menyimpan ETag bersama dengan sumber daya yang di-cache. Pada permintaan berulang, klien mengirimkan header If-None-Match dengan nilai ETag yang disimpan. Server membandingkan nilai yang diterima dengan ETag sumber daya saat ini: jika cocok, mengembalikan 304 Not Modified dengan tubuh kosong, jika tidak cocok — 200 OK dengan sumber daya baru dan ETag baru.

// Permintaan klien dengan If-None-Match
GET /api/users HTTP/1.1
Host: example.com
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

// Respons server — sumber daya tidak berubah
HTTP/1.1 304 Not Modified
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Dalam aplikasi mobile, siklus ini dapat diimplementasikan melalui klien HTTP dengan dukungan cache. OkHttp, misalnya, secara otomatis mengelola ETag melalui CacheInterceptor: menyimpan ETag respons dan pada permintaan berulang menambahkan If-None-Match. Setelah menerima 304, OkHttp mengembalikan data yang di-cache. OkHttp mendukung ETag tanpa konfigurasi tambahan — cukup aktifkan cache melalui OkHttpClient.Builder.cache().

Menghasilkan ETag di server

Server dapat menghitung ETag dengan berbagai cara: melalui hash MD5 atau SHA konten, melalui nomor revisi dari database (misalnya, updated_at dari MySQL), melalui kombinasi inode + mtime + size untuk file statis (Nginx menghasilkan ETag persis dengan cara ini). Untuk API dinamis, yang paling andal adalah hash konten: jika respons JSON mengubah setidaknya satu bidang, ETag akan berubah. Namun, menghitung hash pada setiap permintaan membebani CPU — untuk sistem dengan beban tinggi, lebih baik menggunakan nomor versi inkremental.

ETag kuat dan lemah

RFC 7232 mendefinisikan dua jenis ETag: kuat (strong) dan lemah (weak). ETag kuat berarti dua representasi sumber daya identik byte demi byte — tidak ada satu bit pun yang berbeda. ETag lemah (prefiks W/) hanya menjamin kesetaraan semantik: konten mungkin berbeda pada tingkat serialisasi (spasi, urutan bidang JSON), tetapi data dianggap sama untuk klien. ETag lemah ditandai dengan prefiks W/, misalnya W/"1a2b3c".

Pemilihan jenis ETag tergantung pada persyaratan akurasi perbandingan. Untuk file statis (CSS, JS, gambar) ETag kuat lebih disukai — jika file berubah, klien harus menerima versi baru. Untuk API dinamis, di mana JSON yang sama dapat diserialisasi dengan urutan bidang atau format yang berbeda, ETag lemah memberikan lebih banyak fleksibilitas: server menghasilkan ETag berdasarkan data bisnis, bukan representasi string.

Keterbatasan ETag lemah: mereka tidak dapat digunakan dengan permintaan rentang (Range requests). Jika klien meminta sebagian file, server harus mengembalikan ETag kuat untuk menjamin bahwa fragmen tersebut sesuai dengan sumber daya lengkap. ETag lemah tidak memberikan jaminan seperti itu. Dalam skenario lain, ETag lemah aman dan direkomendasikan untuk API.

ETag vs Last-Modified

ETag dan Last-Modified adalah dua header HTTP untuk permintaan bersyarat yang sering digunakan bersama. Last-Modified menunjukkan tanggal perubahan terakhir sumber daya dan bekerja dengan header If-Modified-Since. ETag menyediakan pengidentifikasi unik versi dan bekerja dengan If-None-Match. Masing-masing memiliki kelebihan dan keterbatasan, dan kombinasinya memberikan efisiensi caching maksimal.

Last-Modified lebih sederhana untuk diimplementasikan — server secara otomatis mendapatkan tanggal dari sistem file atau memperbarui bidang updated_at di database. Namun, tanggal memiliki akurasi hingga detik, yang tidak memadai untuk sumber daya yang berubah beberapa kali per detik. Selain itu, Last-Modified tidak membedakan berbagai keadaan: jika file ditimpa dengan versi yang sama, tanggal berubah, tetapi konten tidak — klien memuat ulang data yang identik.

ETag lebih akurat: hanya berubah pada perubahan konten yang sebenarnya. Jika server memulihkan versi sebelumnya dari cadangan, ETag akan berubah. Jika file ditimpa dengan data yang sama — ETag tetap sama, dan klien tidak akan memuat ulang. Penggunaan bersama direkomendasikan oleh spesifikasi HTTP: server mengembalikan kedua header, klien mengirimkan If-None-Match dan If-Modified-Since secara bersamaan. Jika setidaknya satu header menunjukkan perubahan — server mengembalikan sumber daya baru.

Prioritas header

Menurut spesifikasi, ETag memiliki prioritas di atas Last-Modified. Jika server menerima If-None-Match, ia harus memeriksa hanya ETag, mengabaikan If-Modified-Since. Ini mencegah race condition: jika sumber daya berubah antara pengiriman Last-Modified oleh klien dan pemeriksaan di server, ETag akan menjadi indikator yang lebih segar. Dalam praktiknya, server biasanya memeriksa kedua header, tetapi jika hasilnya tidak cocok, ETag yang menang.

Implementasi ETag di server

Konfigurasi ETag tergantung pada jenis server. Nginx menghasilkan ETag untuk file statis secara otomatis berdasarkan inode, mtime, dan ukuran. Apache menggunakan mekanisme FileETag. Untuk aplikasi dinamis di Node.js, PHP, Python, Ruby, ETag harus dihasilkan secara terprogram — melalui hash respons, nomor versi data, atau kombinasi parameter permintaan.

func etagMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter,
        r *http.Request) {
        // Menghasilkan ETag berdasarkan data
        etag := generateETag(r.URL.Path)
        w.Header().Set("ETag", etag)

        // Memeriksa If-None-Match
        if r.Header.Get("If-None-Match") == etag {
            w.WriteHeader(http.StatusNotModified)
            return
        }
        next.ServeHTTP(w, r)
    })
}

Middleware Go mencegat permintaan, menghasilkan ETag untuk URL yang diminta (misalnya, menghitung hash data dari cache atau database) dan mengatur header respons. Jika klien mengirimkan If-None-Match dan cocok dengan ETag saat ini, server segera mengembalikan 304 Not Modified, tanpa memanggil handler utama. Di lingkungan produksi, sebaiknya tambahkan caching ETag yang telah dihitung berdasarkan URL dan parameter untuk mengurangi beban server.

Masalah dan jebakan

Dalam konfigurasi multi-server (round-robin atau anycast) ETag harus sama di semua node untuk sumber daya yang sama. Jika ETag dihasilkan berdasarkan inode file, dan situs berjalan di beberapa server, nilainya akan berbeda. Solusinya — menggunakan hash konten atau penyimpanan versi terpusat (Redis, etcd). Masalah kedua — kompresi gzip: Nginx mengubah ETag saat kompresi diaktifkan, yang dapat menyebabkan 304 berlebihan. Diperlukan konfigurasi gzip_vary on untuk sinkronisasi ETag dengan konten terkompresi.