ETag

Penggunaan

Header ETag memberikan tanda unik pada setiap versi sebuah sumber daya. Ketika sumber daya berubah, nilai ETag ikut berubah. Klien menyimpan ETag dari respons yang di-cache dan mengirimkan kembali ETag tersebut pada header permintaan If-None-Match di permintaan berikutnya. Jika ETag masih cocok, server mengembalikan 304 Not Modified tanpa body, dan klien menggunakan kembali salinan cache-nya. Jika ETag sudah tidak cocok, server mengirimkan respons lengkap yang telah diperbarui.

Validasi berbasis ETag lebih andal dibandingkan validasi berbasis tanggal dengan Last-Modified. Entity tag kuat adalah string buram yang terikat pada isi persis sebuah representasi, sedangkan stempel waktu modifikasi hanya memiliki granularitas satu detik dan rentan terhadap pergeseran jam. Ketika ETag dan Last-Modified sama-sama hadir, ETag diprioritaskan saat revalidasi sebagaimana diwajibkan oleh standar HTTP.

ETag juga memungkinkan kontrol konkurensi pada metode yang tidak aman. Permintaan PUT dengan If-Match memastikan pembaruan hanya diterapkan pada versi yang diharapkan. Jika sumber daya telah berubah sejak klien terakhir mengambil ETag, server mengembalikan 412 Precondition Failed sehingga mencegah masalah lost update.

Nilai ETag dihasilkan oleh server. Strategi yang umum mencakup hashing konten, penghitung versi, serta menggabungkan waktu modifikasi berkas dengan ukurannya. Nilai tersebut diapit tanda kutip ganda dan secara opsional diberi awalan W/ untuk perbandingan lemah.

Catatan

Google menyarankan penggunaan ETag daripada Last-Modified untuk menyatakan preferensi caching karena ETag menghindari masalah pemformatan tanggal. Ketika ETag dan Last-Modified sama-sama hadir, crawler Google menggunakan nilai ETag sebagaimana diwajibkan oleh standar HTTP. Menyetel kedua header tetap disarankan karena aplikasi lain seperti CMS juga mengandalkan header tersebut. Masing-masing crawler dan fetcher Google memanfaatkan caching sesuai kebutuhan produk yang terkait dengannya. Googlebot mendukung caching saat melakukan crawl ulang URL untuk Google Search.

ETag kuat

ETag kuat menjamin kesamaan byte per byte antara dua representasi sebuah sumber daya. Dua sumber daya dengan ETag kuat yang sama dapat dipertukarkan pada tingkat byte. ETag kuat cocok untuk permintaan rentang (range) dan semua metode perbandingan.

ETag: "abc123"

ETag lemah

ETag lemah, yang diberi awalan W/, menandakan kesetaraan semantik alih-alih kesamaan pada tingkat byte. Dua sumber daya dengan ETag lemah yang sama dianggap setara maknanya, tetapi isinya belum tentu identik. ETag lemah lebih mudah dihasilkan karena mentoleransi perbedaan kecil seperti perubahan spasi atau pembaruan stempel waktu di dalam body. ETag lemah tidak valid untuk permintaan byte-range.

ETag: W/"v2.6"

Contoh

Server mengembalikan sebuah ETag bersama respons. Klien menyimpan tanda tersebut untuk revalidasi di kemudian hari.

HTTP/1.1 200 OK
ETag: "33a64df5"
Content-Type: text/html
Cache-Control: max-age=3600

Klien melakukan revalidasi menggunakan If-None-Match. Server membandingkan tanda tersebut dengan versi sumber daya saat ini.

GET /page HTTP/1.1
If-None-Match: "33a64df5"

Sumber daya tidak berubah. Server mengembalikan 304 tanpa body dan klien menggunakan kembali cache-nya.

HTTP/1.1 304 Not Modified
ETag: "33a64df5"
Cache-Control: max-age=3600

Sebuah permintaan PUT yang menggunakan If-Match untuk konkurensi optimistis. Pembaruan hanya dilanjutkan jika sumber daya masih cocok dengan ETag yang dipegang klien.

PUT /api/document/42 HTTP/1.1
If-Match: "33a64df5"
Content-Type: application/json

Sebuah ETag lemah pada sumber daya yang variasi kecil pada body-nya (seperti stempel waktu yang tertanam) masih dapat diterima. Awalan W/ menandakan semantik perbandingan lemah.

ETag: W/"2024-11-22-v3"

Pemecahan masalah

Masalah terkait ETag muncul sebagai revalidasi yang gagal, unduhan penuh yang tidak terduga, atau konflik konkurensi pada infrastruktur terdistribusi.

Ketidakcocokan ETag antar server di belakang load balancer. Server yang berbeda di belakang load balancer menghasilkan ETag yang berbeda untuk sumber daya yang sama ketika algoritma pembangkitannya menyertakan nomor inode, stempel waktu, atau data khusus server. Klien men-cache respons dari server A, tetapi melakukan revalidasi ke server B, yang mengembalikan ETag berbeda dan memaksa unduhan penuh. Pada Apache, ETag bawaan mencakup inode, size, dan mtime. Hapus komponen inode:

FileETag MTime Size

Pada nginx, ETag diturunkan dari waktu last-modified dan panjang konten, sehingga menghasilkan nilai yang konsisten di antara server yang berbagi isi berkas yang sama. Pastikan stempel waktu penerapan berkas sama di semua node.

IIS memancarkan ETag dalam format “filetime:changenumber”, misalnya “04c2528da58dc1:0”. Paruh pertama menyandikan Windows FILETIME terakhir kali berkas dimodifikasi dalam bentuk heksadesimal. Akhiran ChangeNumber melacak status konfigurasi IIS. IIS 7 dan versi setelahnya selalu memancarkan :0: properti metabase yang menggerakkan penghitung tersebut sudah dipensiunkan sejak IIS 6, dan tidak ada pengaturan applicationHost.config atau web.config yang memunculkan nilai bukan nol. Karena itu node di belakang load balancer memancarkan ETag yang cocok untuk berkas yang sama. IIS 6 dan versi sebelumnya menaikkan ChangeNumber saat metabase disunting dan saat layanan dimulai ulang, sehingga node menjadi tidak selaras dan revalidasi antar node mengembalikan 200 alih-alih 304. Setel ulang nilai tersebut pada setiap node IIS 6 dengan cscript adsutil.vbs set w3svc/etag_changenumber 0, atau buang akhirannya sehingga ETag hanya mencerminkan FILETIME. Akhiran bukan nol yang ditemui di lapangan menandakan asal dari IIS 6.

ETag lemah menyebabkan respons penuh yang tidak terduga alih-alih 304. ETag lemah (W/”…”) menandakan kesetaraan semantik tetapi tidak mendukung permintaan byte-range. Permintaan If-None-Match dengan ETag lemah tetap berfungsi untuk revalidasi cache. Jika server mengembalikan respons 200 penuh alih-alih 304, logika perbandingan di sisi server mungkin keliru. Pastikan server membandingkan ETag lemah menggunakan fungsi perbandingan lemah, yang mengabaikan awalan W/ saat pencocokan.

If-None-Match tidak dikirim oleh klien. Browser hanya mengirim If-None-Match ketika respons yang di-cache menyertakan header ETag. Tidak adanya ETag pada respons awal mencegah seluruh revalidasi berikutnya. Periksa respons origin dengan curl -I https://example.re/resource dan pastikan header ETag ada. Server berkas statis seperti nginx dan Apache menghasilkan ETag secara otomatis. Server aplikasi dan framework API sering kali mengharuskan pembangkitan ETag secara eksplisit di dalam kode.

CDN menghapus atau mengubah ETag. Beberapa CDN mengubah nilai ETag selama pemrosesan. Cloudflare mengonversi ETag kuat menjadi ETag lemah ketika menerapkan transformasi seperti kompresi Brotli atau optimasi gambar. AWS CloudFront meneruskan ETag dari origin tanpa perubahan. Periksa ETag di origin (curl -I https://origin.example.re) dan bandingkan dengan edge CDN (curl -I https://cdn.example.re). Ketika CDN mengubah ETag, revalidasi melalui CDN tetap berfungsi karena CDN menyimpan pemetaannya. Revalidasi langsung ke origin dengan ETag yang telah diubah CDN akan gagal.

Apache dan nginx menghasilkan ETag secara berbeda. Apache secara bawaan menggunakan inode-mtime-size, menghasilkan ETag seperti “1a2b3c-4d5e-6f7a8b9c”. Nginx menggunakan mtime-content-length dalam heksadesimal, menghasilkan ETag seperti “5f4dcc3b-d8”. Migrasi antar server membatalkan semua ETag yang telah di-cache sehingga memicu unduhan penuh bagi setiap klien. Rencanakan periode pemanasan cache setelah migrasi server. Untuk respons API, hasilkan ETag dari hash konten (MD5 atau SHA-256) agar menghasilkan nilai yang tidak bergantung pada server.

Catatan

Pembangkitan ETag bawaan Apache menyertakan nomor inode berkas (FileETag INode MTime Size). Nomor inode membocorkan informasi sistem berkas server sehingga memungkinkan fingerprinting dan korelasi antar server. OWASP menandai ETag berbasis inode sebagai risiko pengungkapan informasi. Hapus inode dari perhitungan dengan FileETag MTime Size pada konfigurasi Apache.

Catatan

Untuk bantuan SEO dan caching, hubungi konsultan SEO mantan Google, Search Brothers.