Accept-Encoding

Penggunaan

Header permintaan HTTP Accept-Encoding merupakan bagian dari proses negosiasi konten dan menetapkan metode encoding mana saja yang didukung oleh klien. Server akan memilih salah satu metode yang tersedia, lalu memberi tahu klien mengenai pilihan tersebut dengan menyertakan header Content-Encoding pada respons HTTP.

Catatan

Dalam beberapa kasus, bahkan ketika klien dan server mendukung metode encoding yang sama, tidak ada pengolahan terhadap sumber daya asli sebelum pengiriman. Hal ini terjadi pada situasi ketika nilai identity dari sumber daya juga dapat diterima. Salah satu contoh umum adalah ketika data sudah terkompresi, sehingga menerapkan algoritme kompresi berikutnya tidak akan memperkecil ukurannya lebih jauh. Hal ini terjadi pada berkas gambar yang sudah terkompresi, seperti JPEG. Situasi lainnya adalah ketika server mengalami beban berat dan tidak dapat menyisihkan sumber daya yang dibutuhkan untuk mengolah data sebelum transmisi.

Beberapa encoding ditetapkan menggunakan header HTTP Accept-Encoding yang terpisah, atau sebagai alternatif, dengan menggunakan daftar yang dipisahkan koma. Faktor q juga disertakan untuk menunjukkan preferensi atau prioritas.

Dampak SEO

Crawler dan fetcher milik Google mendukung content encoding gzip, deflate, dan Brotli (br). Setiap user agent Google mengumumkan encoding yang didukungnya pada header Accept-Encoding di setiap permintaan, biasanya sebagai Accept-Encoding: gzip, deflate, br. Menyajikan respons terkompresi kepada Googlebot mengurangi bandwidth dan waktu perayapan. Bingbot mengirimkan Accept-Encoding: gzip, deflate.

gzip

Direktif gzip menunjukkan bahwa klien mendukung kompresi GNU zip. Ini adalah encoding dengan dukungan terluas di web.

deflate

Direktif deflate menunjukkan bahwa klien mendukung kompresi zlib. Meskipun namanya demikian, mekanisme ini menggunakan pembungkus zlib di sekitar data terkompresi DEFLATE mentah.

br

Direktif br menunjukkan bahwa klien mendukung kompresi Brotli. Untuk konten berbasis teks, Brotli umumnya mencapai rasio kompresi yang lebih baik daripada gzip.

zstd

Direktif zstd menunjukkan bahwa klien mendukung kompresi Zstandard. Zstandard menawarkan rasio kompresi tinggi dengan kecepatan dekompresi yang cepat.

identity

Direktif identity menunjukkan bahwa tidak ada encoding yang diterapkan. Nilai ini selalu dianggap dapat diterima kecuali dikecualikan secara eksplisit dengan identity;q=0.

* (wildcard)

Wildcard * mencocokkan encoding apa pun yang belum tercantum pada header. Jika tidak ada header Accept-Encoding, server memperlakukan permintaan tersebut seolah-olah * yang ditetapkan.

;q= (nilai kualitas)

Parameter ;q= memberikan bobot antara 0 dan 1 untuk setiap encoding, dengan 1 sebagai prioritas tertinggi dan 0 berarti “tidak dapat diterima”. Jika dihilangkan, nilai kualitas bawaannya adalah 1. Server menggunakan bobot-bobot ini untuk memilih encoding yang dikehendaki.

Contoh

Pada contoh ini, klien meminta server menggunakan salah satu dari beberapa metode encoding. Pada variasi pertama, setiap opsi diberi prioritas yang sama. Pada variasi kedua, direktif nilai q digunakan untuk memberikan bobot pada prioritas encoding. Server merespons dengan daftar encoding yang diterapkan, diurutkan sesuai cara pemrosesannya.

Permintaan (variasi #1)

GET / HTTP/1.1
Host: example.com
Accept-Encoding: gzip
Accept-Encoding: deflate
Accept-Encoding: br
Accept-Encoding: identity
Accept-Encoding: *

Permintaan (variasi #2)

GET / HTTP/1.1
Host: example.com
Accept-Encoding: gzip, deflate, br;q=1.0, identity;q=0.5, *;q=0.25

Respons

HTTP/1.1 200 OK
Content-Encoding: gzip, br

Pemecahan masalah

Kompresi tidak diterapkan meskipun ada Accept-Encoding. Sebagian reverse proxy melepas Accept-Encoding dari permintaan sebelum meneruskannya. Pada nginx, proxy_set_header Accept-Encoding $http_accept_encoding mempertahankan nilai aslinya. Verifikasi dengan curl -H “Accept-Encoding: gzip” -I.

Encoding yang terpilih tidak sesuai harapan. Nilai kualitas (faktor q) mengatur urutan preferensi. Permintaan dengan Accept-Encoding: gzip;q=0.5, br;q=1.0 lebih mengutamakan Brotli. Menghilangkan nilai q berarti memberikan bobot yang sama, sehingga server bebas memilih.

Preflight CORS kehilangan Accept-Encoding. Header Accept-Encoding termasuk dalam daftar aman (safelist) untuk CORS dan tidak memicu preflight. Jika kompresi berhenti bekerja pada permintaan lintas origin, periksa apakah server menerapkan kompresi tanpa memandang header Origin.

CDN menyajikan respons tanpa kompresi. Sebagian CDN hanya melakukan kompresi ketika origin mengirimkan respons tanpa kompresi dengan Content-Type yang sesuai. Pastikan origin merespons dengan Vary: Accept-Encoding agar CDN menyimpan varian terkompresi dan tidak terkompresi secara terpisah.

Encoding identity ditolak. Mengirimkan Accept-Encoding: identity;q=0 memberi tahu server bahwa klien tidak dapat menerima respons tanpa kompresi. Jika tidak ada encoding yang didukung dan tersedia, server mengembalikan 406 Not Acceptable. Hindari menetapkan identity ke q=0 kecuali semua encoding yang tercantum dijamin tersedia.