Edge Security Acceleration：Aturan cache default

Kebijakan cache default

Konfigurasi cache hanya berlaku untuk permintaan klien yang dikirim ke komponen cache ESA. Untuk menentukan apakah permintaan klien dikirim ke komponen cache, ESA menjalankan prosedur berikut:

1. Memeriksa apakah permintaan bertipe GET atau HEAD.

2. Memeriksa apakah permintaan memenuhi kondisi yang ditentukan dalam aturan cache. Jika ya, aturan cache—bukan pengaturan cache global—yang diterapkan pada permintaan tersebut. Untuk informasi selengkapnya, lihat Aturan cache untuk respons sukses dan pengalihan.

3. Memeriksa apakah ekstensi file tercantum dalam ekstensi file default yang di-cache. Jika ya, pengaturan cache global diterapkan pada permintaan tersebut.

Aturan cache untuk respons sukses dan pengalihan

Kode status yang berlaku: 200, 203, 206, 300, 301, dan 410.

TTL cache tepi memiliki empat opsi, masing-masing diterapkan berdasarkan logika yang berbeda:

• Honor Origin TTL or Use Default Cache Rule: Jika respons yang dikembalikan dari server origin berisi header Cache-Control, Expires, Last-Modified, dan ETag untuk menetapkan kebijakan cache, ESA menggunakan kebijakan cache server origin. Jika respons yang dikembalikan dari server origin tidak berisi salah satu header Cache-Control, Expires, Last-Modified, dan ETag, ESA menyimpan cache resource berdasarkan kebijakan cache default ESA.

  Detail kebijakan cache

  

  Cache-Control dalam respons

  Header Cache-Control dalam respons origin menentukan salah satu kebijakan berikut:

  1. Jika header Cache-Control memiliki salah satu direktif berikut, resource tidak di-cache:

     • no-cache

     • no-store

     • max-age=0

  2. Jika header Cache-Control berisi direktif max-age atau s-maxage dengan nilai lebih besar dari 0, seperti 3600, TTL yang ditentukan oleh direktif tersebut digunakan. Jika kedua direktif max-age dan s-maxage ada, nilai direktif s-maxage yang berlaku.

  Tidak ada Cache-Control dalam respons

  Jika respons origin tidak berisi header Cache-Control, kebijakan cache default ESA digunakan. Header dalam respons dari server origin memiliki urutan prioritas menurun sebagai berikut: Expires > Last-Modified > ETag.

  1. Jika respons origin berisi header Expires, seperti Expires:Tue, 25 Nov 2031 17:25:43 GMT, ESA menggunakan TTL yang ditetapkan dalam header Expires.

  2. Jika respons origin tidak berisi header Expires tetapi berisi header Last-Modified, TTL dihitung berdasarkan aturan berikut:

     • TTL = (Waktu saat ini - Nilai Last-Modified) × 0,1. Jika nilai hasilnya berkisar antara 10 detik hingga 3.600 detik, nilai aktual digunakan. Jika kurang dari 10 detik, TTL adalah 10 detik. Jika lebih dari 3.600 detik, TTL adalah 3.600 detik.

  3. Jika respons origin hanya berisi header ETag, TTL adalah 10 detik.

  4. Jika respons origin tidak berisi header Cache-Control, Expires, ETag, atau Last-Modified, resource tidak di-cache.

• Honor Origin TTL or Do Not Cache: Jika respons yang dikembalikan dari server origin berisi header Cache-Control untuk menetapkan kebijakan cache, ESA menggunakan kebijakan cache server origin. Jika respons yang dikembalikan dari server origin tidak berisi header Cache-Control, ESA tidak menyimpan cache resource.

  Detail kebijakan cache

  

  Menentukan kebijakan cache server origin

  Untuk menentukan kebijakan cache server origin, periksa apakah respons origin berisi header Cache-Control. Jika header tersebut tidak ada, resource tidak di-cache. Jika header tersebut ada, salah satu kebijakan cache berikut berlaku:

  1. Jika header Cache-Control berisi direktif no-cache, no-store, atau max-age=0, resource tidak di-cache.

  2. Jika header Cache-Control berisi direktif max-age atau s-maxage dengan nilai lebih besar dari 0, seperti 3600, TTL yang ditentukan oleh direktif tersebut digunakan. Jika kedua direktif max-age dan s-maxage ada, nilai direktif s-maxage yang berlaku.

• Do Not Cache: Semua resource yang diambil dari server origin tidak di-cache pada POP ESA.

• Use Custom TTL: ESA mengabaikan header Cache-Control, Expires, Last-Modified, dan ETag dari kebijakan cache dalam respons origin dan menggunakan TTL yang ditetapkan pada ESA.

Aturan cache untuk respons dengan kode status error

• Untuk kode status 204, 305, 404, 405, 414, 424, 429, 500, 501, 502, 503, dan 504, aturan cache adalah sebagai berikut:

  

  1. Jika server origin mengembalikan header respons set-cookie, respons tersebut tidak di-cache.

  2. Jika server origin tidak mengembalikan header respons set-cookie, sistem memeriksa apakah TTL untuk kode status tersebut telah dikonfigurasi di Konsol:

     1. Jika TTL dikonfigurasi, respons di-cache berdasarkan pengaturan di Konsol. Jika terdapat beberapa aturan, aturan dengan nomor ordinal terkecil yang berlaku.

     2. Jika TTL tidak dikonfigurasi, respons di-cache berdasarkan header respons Pragma, Cache-Control, atau Expires dari server origin.

  3. Jika server origin tidak mengembalikan header respons Pragma, Cache-Control, atau Expires, respons di-cache selama 1 detik secara default.

• Untuk kode status 302, 307, dan 403, aturan cache adalah sebagai berikut:

  

  1. Jika server origin mengembalikan header respons set-cookie, respons tersebut tidak di-cache.

  2. Jika server origin tidak mengembalikan header respons set-cookie, sistem memeriksa apakah TTL untuk kode status tersebut telah dikonfigurasi di Konsol:

     1. Jika TTL dikonfigurasi, respons di-cache berdasarkan pengaturan di Konsol. Jika terdapat beberapa aturan, aturan dengan nomor ordinal terkecil yang berlaku.

     2. Jika TTL tidak dikonfigurasi, respons di-cache berdasarkan header respons Pragma, Cache-Control, atau Expires dari server origin.

  3. Jika server origin tidak mengembalikan header respons Pragma, Cache-Control, atau Expires, respons tidak di-cache.

• Untuk kode status error lainnya, seperti 400, aturan cache adalah sebagai berikut:

  1. Jika server origin mengembalikan header respons set-cookie, respons tersebut tidak di-cache.

  2. Jika server origin tidak mengembalikan header respons set-cookie, sistem memeriksa apakah TTL untuk kode status tersebut telah dikonfigurasi di Konsol. Jika terdapat beberapa aturan, aturan dengan nomor ordinal terkecil yang berlaku.

  3. Dalam semua kasus lainnya, respons tidak di-cache.

• Untuk permintaan yang menggunakan range origin fetch, jika POP menerima respons dengan kode status selain 206 dari server origin, POP akan menghapus shard file yang di-cache. Timeout pada origin fetch tidak menyebabkan file cache dihapus.

  Saat menggunakan range origin fetch, server origin membagi file besar menjadi beberapa shard file yang lebih kecil dan mengirimkannya ke POP. Misalnya, sebuah file dibagi menjadi 10 shard dan POP telah menyimpan cache 5 shard tersebut. Ketika POP meminta shard ke-6 dan server origin mengembalikan kode status 5xx, POP akan menghapus semua 5 shard yang telah di-cache.

Informasi respons cache

POP ESA memberikan respons standar dan jelas yang memungkinkan Anda menyesuaikan permintaan HTTP secara dinamis. Header respons terkait cache berisi informasi berikut:

• Ali-Swift-Global-Savetime: Waktu saat resource pertama kali masuk ke POP ESA (ditentukan oleh arsitektur cache website, yang bisa berupa POP L2 atau POP pada tingkat cache lainnya).

  • Nilainya berupa stempel waktu UNIX. Contoh: 1745053111 menunjukkan 16:58:31 pada 19 April 2025.

• Date: Tanggal saat server origin mengembalikan resource ke POP ESA.

  • Tanggal diperbarui ketika POP ESA menginisiasi permintaan origin yang berisi header If-Modified-Since atau If-None-Match untuk memvalidasi ulang resource dan server origin mengembalikan kode status HTTP 304.

  • Waktu dalam format GMT. Contoh: Sat, 19 Apr 2025 08:58:31 GMT.

• X-Site-Cache-Status: Status cache resource yang diminta pada POP ESA. Daftar berikut menjelaskan status resource:

  • HIT: Resource ditemukan dalam cache POP ESA.

  • MISS: Resource tidak ditemukan dalam cache POP ESA. POP mengambil resource dari server origin lalu mengembalikannya ke klien.

  • NONE/UNKNOWN: Resource tidak memenuhi syarat untuk di-cache karena alasan berikut:

    • Fungsi tepi menghasilkan respons tetapi tidak mengirim subpermintaan apa pun. Dalam kasus ini, respons bukan berasal dari cache, dan status cache dicatat sebagai none/unknown.

    • Saat permintaan utama fungsi tepi menginisiasi subpermintaan (fetch), status cache dicatat untuk subpermintaan tersebut, sedangkan status cache permintaan utama dicatat sebagai none/unknown. Hal ini terjadi karena modul fungsi tepi dijalankan sebelum modul cache, sehingga permintaan utama tidak melewati cache.

    • Permintaan klien memicu aturan WAF kustom dan diblokir oleh WAF. Karena WAF dijalankan sebelum modul cache, permintaan tidak melewati cache, dan status cache dicatat sebagai none/unknown.

    • Permintaan klien memicu aturan pengalihan atau aturan HTTPS. POP kemudian mengirim respons pengalihan ke URL lain. Karena aturan ini dijalankan sebelum modul cache, status cache dicatat sebagai none/unknown.

  • EXPIRED: Resource ditemukan dalam cache POP ESA tetapi telah kedaluwarsa. POP mengambil resource dari server origin lalu mengembalikannya ke klien. Kode status yang dikembalikan oleh server origin adalah 200 atau 206.

  • STALE:

    Resource disajikan dari cache POP ESA tetapi telah kedaluwarsa. Hal ini terjadi dalam kasus berikut:

    • Pengaturan cache adalah Honor Origin TTL dan respons origin berisi Cache-Control:stale-while-revalidate=<seconds>. Dalam periode yang ditentukan, ESA menginisiasi permintaan ke server origin untuk memvalidasi ulang resource dan menyajikan cache kedaluwarsa kepada klien.

    • Pengaturan cache adalah Honor Origin TTL dan respons origin berisi Cache-Control:stale-if-error==<seconds>. Dalam periode yang ditentukan, ESA menyajikan cache kedaluwarsa kepada klien ketika ESA tidak dapat terhubung ke server origin untuk mengambil resource yang diperbarui.

    • Fitur Configure response cache expiration diaktifkan. Fitur ini memungkinkan POP ESA menyajikan cache kedaluwarsa kepada klien ketika respons origin mengalami timeout atau server origin tidak dapat dijangkau.

  • BYPASS

    Permintaan ke resource melewati cache ESA. Hal ini terjadi dalam kasus berikut:

    • Pengaturan cache bukan Honor Origin TTL dan ESA menetapkan TTL cache kustom menjadi 0 detik.

    • Pengaturan cache adalah Honor Origin TTL tetapi nilai header Cache-Control yang dikembalikan oleh server origin adalah no-cache, no-store, atau max-age=0.

  • REVALIDATED

    Resource disajikan oleh cache ESA, tetapi telah kedaluwarsa. ESA menginisiasi permintaan origin yang berisi header If-Modified-Since atau lf-None-Match ke server origin untuk memvalidasi ulang resource. Server origin mengembalikan kode status HTTP 304.

  • DYNAMIC

    ESA mendeteksi bahwa resource merupakan konten dinamis dan tidak ada aturan cache yang ditentukan berlaku untuk permintaan tersebut. Dalam kasus ini, ESA mengambil resource dari server origin lalu mengembalikannya ke klien.

• X-Swift-Cachetime: Menentukan TTL resource pada POP dalam satuan detik. Nilai X-Swift-Cachetime tidak sama dengan TTL yang ditetapkan di ESA. Nilai tersebut dihitung menggunakan rumus berikut: X-Swift-Cachetime = Ali-Swift-Global-Savetime + TTL yang ditetapkan di ESA - X-Swift-SaveTime. Skenario berikut mungkin terjadi:

  • Nilai X-Swift-Cachetime sama dengan TTL yang ditetapkan di ESA, misalnya 3600 detik.

  • Nilai X-Swift-Cachetime sedikit lebih kecil daripada TTL yang ditetapkan di ESA. Misalnya, jika TTL yang ditetapkan di ESA adalah 300 detik, nilai X-Swift-Cachetime mungkin 295 detik. Perbedaan ini dapat terjadi karena alasan berikut:

    • Latensi tinggi terjadi saat node L1 mengambil konten dari node L2.

    • Jam pada node L1 dan L2 tidak sinkron.

  • Nilai X-Swift-Cachetime bernilai negatif. Hal ini dapat terjadi jika Anda mengubah pengaturan TTL di ESA setelah resource di-cache. Ini terjadi ketika permintaan klien tiba setelah cache node L1 kedaluwarsa, tetapi cache node L2 masih valid. Misalnya, TTL awalnya ditetapkan 3600 detik di ESA dan kemudian diubah menjadi 300 detik. Jika klien mengirim permintaan 600 detik setelah resource di-cache, responsnya mencakup X-Swift-Cachetime:-300. Untuk mengatasi masalah ini, Anda dapat melakukan refresh cache.

• X-Swift-Cachetime:

  TTL cache resource pada POP ESA. Satuan: detik.

• X-Swift-SaveTime:

  • Waktu saat resource pertama kali masuk ke POP saat ini (POP L1) yang menerima permintaan klien.

  • Waktu dalam format GMT. Contoh: Sat, 19 Apr 2025 08:58:31 GMT.

Kebijakan Do Not Cache

POP ESA tidak menyimpan cache file dan meneruskan semua permintaan file dalam kondisi berikut:

• Edge Cache TTL pada halaman ESA Settings diatur ke Honor Origin TTL or Do Not Cache dan respons origin adalah Cache-Control: no-store.

• Edge Cache TTL pada halaman ESA Settings diatur ke Do Not Cache.

• Edge Cache TTL pada halaman ESA Settings diatur ke Use Custom TTL dan TTL cache diatur ke 0 detik.

Validasi ulang cache

Setelah file yang di-cache pada POP ESA kedaluwarsa, mekanisme validasi ulang cache mulai berlaku saat klien meminta file tersebut untuk pertama kalinya setelah kedaluwarsa. POP ESA mengirim permintaan validasi ke server origin. Jika file tidak berubah, server origin mengembalikan pesan 304 not-modified, dan POP ESA terus menyajikan file yang di-cache kepada klien tanpa perlu mengunduh file tersebut lagi. Hal ini secara efektif meningkatkan kecepatan respons permintaan klien dan mengurangi trafik respons dari server origin.

• Konfigurasi kebijakan khusus: File di-cache selama 0 detik, dan POP ESA mengarahkan setiap permintaan ke server origin untuk validasi.

  • Edge Cache TTL pada halaman ESA Settings diatur ke Honor Origin TTL or Use Default Cache Rule, dan respons origin memenuhi kondisi berikut:

    • Cache-Control: no-cache

    • Cache-Control: max-age=0

• Konfigurasi kebijakan reguler: Server origin merespons kebijakan terkait validasi cache, dan POP ESA mengeksekusi kebijakan aktual tersebut.

  • Edge Cache TTL pada halaman ESA Settings diatur ke Honor Origin TTL or Use Default Cache Rule, dan respons origin memenuhi salah satu kebijakan validasi cache berikut:

    • must-revalidate

    • proxy-revalidate

    • stale-while-revalidate=seconds

    • stale-if-error=seconds

• Kebijakan validasi cache

  Daftar berikut menjelaskan kebijakan validasi cache dan memberikan contoh terkait:

  • must-revalidate

    • Deskripsi: Kebijakan ini menunjukkan bahwa jika resource telah kedaluwarsa, resource harus dikembalikan ke server origin untuk memvalidasi kesegarannya untuk setiap cache (termasuk cache proxy dan cache browser) sebelum cache mengembalikan respons. Bahkan jika pengguna offline atau jaringan tidak tersedia, cache tidak boleh langsung menggunakan resource kedaluwarsa kecuali resource tersebut telah divalidasi tidak berubah.

    • Contoh: Cache-Control: max-age=3600, must-revalidate menunjukkan bahwa resource harus dikembalikan ke server origin untuk memvalidasi kesegarannya setelah resource kedaluwarsa.

  • proxy-revalidate

    • Deskripsi: Mirip dengan kebijakan must-revalidate, kebijakan ini hanya berlaku untuk cache bersama, seperti cache CDN dan server proxy. Kebijakan ini tidak berlaku untuk cache pribadi seperti cache browser. Jika resource telah kedaluwarsa, resource harus dikembalikan ke server origin untuk validasi sebelum cache bersama menyediakan replika cache. Cache pribadi tidak tunduk pada batasan ini.

    • Contoh: Cache-Control: max-age=3600, proxy-revalidate menunjukkan bahwa resource harus dikembalikan ke server origin untuk memvalidasi kesegarannya setelah resource kedaluwarsa.

  • stale-while-revalidate=seconds

    • Deskripsi: Kebijakan ini menunjukkan bahwa cache dapat terus menyediakan resource cache lama selama periode tertentu (dalam detik) setelah resource kedaluwarsa. Secara bersamaan, POP secara asinkron meminta konten terbaru dari server origin di latar belakang. Kebijakan ini berlaku ketika Anda ingin mengurangi waktu tunggu dan dapat menerima konten yang mungkin tidak sepenuhnya terbaru dalam periode singkat.

    • Contoh: Cache-Control: max-age=3600, stale-while-revalidate=60 menunjukkan bahwa resource dianggap segar selama 3.600 detik (1 jam) setelah pertama kali dipublikasikan. Setelah kedaluwarsa, resource tersebut masih dapat disediakan untuk pengguna selama 60 detik berikutnya. Secara bersamaan, POP berusaha mendapatkan pembaruan dari server origin.

  • stale-if-error=seconds

    • Deskripsi: Kebijakan ini menunjukkan bahwa ketika POP gagal mengambil konten terbaru dari server origin karena alasan seperti kerusakan server atau kesalahan jaringan, kebijakan ini memungkinkan POP mengembalikan respons yang menunjukkan bahwa resource telah kedaluwarsa tetapi masih di-cache. Periode waktu (dalam detik) ditentukan, di mana jika terjadi kesalahan, konten cache kedaluwarsa dapat digunakan. Hal ini meningkatkan kemampuan toleransi kesalahan sistem dan memastikan Anda dapat mengakses konten yang di-cache sebelumnya meskipun server origin tidak tersedia, sehingga meningkatkan pengalaman pengguna dan mengurangi dampak gangguan layanan.

    • Contoh: Cache-Control: max-age=86400, stale-if-error=604800 menunjukkan bahwa resource dianggap segar selama 86.400 detik (24 jam) setelah pertama kali dipublikasikan. Jika validasi ulang setelah 86.400 detik gagal, resource yang terakhir berhasil di-cache masih dapat disediakan selama 604.800 detik berikutnya (satu minggu).