Content-Encoding

Penggunaan

Header Content-Encoding mencantumkan encoding yang diterapkan pada data representasi, sesuai urutan penerapannya. Klien membalik rantai encoding tersebut untuk merekonstruksi konten aslinya. Kompresi adalah kasus penggunaan yang paling umum, yang memperkecil ukuran transfer dengan mengorbankan waktu CPU di sisi server maupun klien.

Header permintaan Accept-Encoding mengumumkan encoding mana saja yang didukung klien. Server memilih salah satu encoding dari daftar tersebut dan menyatakan pilihannya pada header respons Content-Encoding. Ketika tidak ada encoding yang dapat diterima, server mengirimkan respons tanpa kompresi.

Ketika Content-Encoding hadir, header metadata seperti Content-Length merujuk pada bentuk terenkode, bukan pada sumber daya aslinya. Format media yang sudah terkompresi seperti JPEG, PNG, dan ZIP telah mengandung kompresi internal sehingga nyaris tidak memperoleh manfaat dari satu tahap encoding tambahan. Menerapkan content encoding pada format-format ini memboroskan CPU dan terkadang justru memperbesar ukuran transfer.

Header Content-Encoding menjelaskan encoding representasi, yang merupakan properti end-to-end dari sumber daya. Hal ini berbeda dengan Transfer-Encoding, yang merupakan properti hop-by-hop yang diterapkan dan dilepas di setiap perantara jaringan.

Catatan

Gzip tetap menjadi encoding yang paling luas penerapannya. Brotli menawarkan rasio kompresi terbaik untuk konten teks statis. Zstandard memberikan keseimbangan antara kompresi yang cepat dan rasio yang kuat dengan dukungan browser yang luas.

Catatan

Tipe media asli dari sumber daya dijelaskan oleh header Content-Type. Content-Encoding mencerminkan status kompresi dari representasi saat ini, bukan format konten yang mendasarinya.

gzip

Algoritme Lempel-Ziv coding (LZ77) dengan CRC 32-bit. Diperkenalkan pada 1996, gzip tetap menjadi encoding dengan dukungan terluas di web. Server juga mengenali x-gzip sebagai alias.

compress

Algoritme Lempel-Ziv-Welch (LZW), yang awalnya berasal dari program compress di UNIX. Persoalan paten menyebabkan kemunduran algoritme ini dan tidak ada browser modern yang mendukung compress.

deflate

Struktur zlib yang membungkus algoritme deflate. Didukung di semua browser, tetapi sebagian besar telah digantikan oleh gzip dan algoritme yang lebih baru.

br

Algoritme Brotli. Brotli mencapai rasio kompresi yang lebih tinggi daripada gzip, terutama pada konten web berbasis teks, dengan memakai kamus statis bawaan berisi istilah-istilah web yang umum. Brotli memerlukan HTTPS. Didukung oleh semua browser utama.

zstd

Algoritme Zstandard. Zstandard melakukan kompresi pada kecepatan yang sebanding dengan gzip sembari mencapai rasio kompresi yang mendekati Brotli. Algoritme ini mendukung level kompresi yang dapat dikonfigurasi dari 1 (tercepat) hingga 22 (rasio tertinggi), sehingga server dapat menukar waktu CPU dengan payload yang lebih kecil. Kecepatan dekompresi tetap konsisten cepat terlepas dari level kompresi yang digunakan.

Zstandard juga mendukung kompresi berbasis kamus, yaitu kamus pra-berbagi yang dilatih pada konten representatif untuk menekan ukuran payload lebih jauh lagi. Header Use-As-Dictionary dan mekanisme Compression Dictionary Transport dibangun di atas kemampuan ini.

Didukung oleh browser berbasis Chromium, Firefox, dan Safari versi terbaru.

dcb

Brotli yang dikompresi dengan kamus. Didefinisikan sebagai bagian dari spesifikasi Compression Dictionary Transport. Klien dan server menegosiasikan kamus bersama melalui header Use-As-Dictionary dan Available-Dictionary. Server mengompresi respons menggunakan Brotli dengan kamus bersama tersebut dan menandai encoding-nya sebagai dcb.

dcz

Zstandard yang dikompresi dengan kamus. Menggunakan mekanisme transport kamus yang sama dengan dcb, tetapi dengan algoritme Zstandard alih-alih Brotli. Server mengompresi dengan kamus yang telah dinegosiasikan dan menandai encoding-nya sebagai dcz.

Contoh

Sebuah respons yang dikompresi dengan gzip. Ini adalah encoding paling umum di web dan memiliki dukungan browser yang universal.

Content-Encoding: gzip

Sebuah respons yang dikompresi dengan Brotli. Brotli umumnya menghasilkan payload yang lebih kecil daripada gzip untuk sumber daya HTML, CSS, dan JavaScript.

Content-Encoding: br

Sebuah respons yang dikompresi dengan Zstandard. Server yang memilih Zstandard memperoleh manfaat berupa kompresi cepat dengan rasio yang sebanding dengan Brotli.

Content-Encoding: zstd

Beberapa encoding yang diterapkan secara berurutan. Sumber daya pertama-tama dienkode dengan deflate, lalu dengan gzip. Klien mendekode dalam urutan terbalik: gzip dahulu, kemudian deflate.

Content-Encoding: deflate, gzip

Sebuah respons yang memakai Zstandard dengan kompresi berbasis kamus. Klien sebelumnya menerima sebuah kamus melalui header Use-As-Dictionary dan mengumumkan kamus tersebut pada header permintaan Available-Dictionary. Server mengompresi respons terhadap kamus bersama itu.

Content-Encoding: dcz

Pemecahan masalah

Kegagalan yang berkaitan dengan kompresi muncul sebagai galat dekode di browser, unduhan yang rusak, atau respons yang tiba tanpa kompresi.

Kompresi ganda menghasilkan respons yang rusak. Sebuah reverse proxy atau CDN mengompresi ulang respons dari origin yang sudah terkompresi, sehingga menghasilkan payload tidak valid yang tidak dapat didekode klien. Periksa header Content-Encoding untuk nilai bertumpuk seperti gzip, gzip. Pada nginx, nonaktifkan kompresi proxy ketika origin sudah melakukan kompresi:

proxy_set_header Accept-Encoding "";

Pada Cloudflare, nonaktifkan “Brotli” di pengaturan Speed ketika origin mengirimkan respons yang sudah terkompresi.

Browser menampilkan ERR_CONTENT_DECODING_FAILED. Galat ini muncul ketika header Content-Encoding mendeklarasikan encoding yang tidak sesuai dengan isi body sebenarnya. Penyebab umum: origin mengirimkan body tanpa kompresi disertai Content-Encoding: gzip, atau middleware melepas encoding tetapi membiarkan header-nya tetap ada. Jalankan curl -v -H “Accept-Encoding: gzip” https://example.re dan periksa apakah body mentahnya sesuai dengan encoding yang dideklarasikan. Salurkan melalui gunzip untuk memverifikasi: curl -s —compressed https://example.re | head.

Ketidakcocokan Content-Length setelah kompresi. Nilai Content-Length harus mencerminkan ukuran body setelah dikompresi, bukan ukuran aslinya. Ketidakcocokan menyebabkan browser memotong atau menolak respons. Saat menggunakan nginx gzip on, nginx menghitung ulang Content-Length secara otomatis. Middleware yang menetapkan Content-Length sebelum kompresi berjalan akan menimbulkan masalah ini. Pindahkan penetapan Content-Length ke setelah kompresi, atau hapus header tersebut dan biarkan server memakai Transfer-Encoding chunked.

Kompresi tidak diterapkan meskipun server sudah dikonfigurasi. Server memeriksa header permintaan Accept-Encoding sebelum melakukan kompresi. Accept-Encoding yang hilang atau kosong berarti tidak ada kompresi. Sebagian proxy melepas Accept-Encoding dari permintaan yang diteruskan. Pada nginx, pastikan gzip on telah diatur dan tipe MIME-nya cocok:

gzip on;
gzip_types text/plain application/json
           text/css application/javascript;

Pada Apache, aktifkan mod_deflate dan pastikan filternya diterapkan:

AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE application/json

Menyajikan berkas yang sudah terkompresi untuk performa yang lebih baik. Melakukan kompresi pada setiap permintaan memboroskan CPU. Sajikan berkas statis yang sudah terkompresi dari disk sebagai gantinya. Pada nginx, aktifkan gzip_static on untuk menyajikan berkas .gz berdampingan dengan berkas aslinya. Pada Apache, aktifkan MultiViews atau gunakan mod_rewrite untuk memetakan permintaan ke varian .gz atau .br. Pastikan berkas yang sudah terkompresi tetap sinkron dengan berkas aslinya selama proses deployment.