Halaman ini berlaku untuk Apigee dan Apigee Hybrid.
Baca dokumentasi Apigee Edge.
Topik ini menjelaskan cara Apigee menangani header caching HTTP/1.1 saat Anda menggunakan kebijakan ResponseCache. Apigee saat ini mendukung subset header dan perintah caching HTTP/1.1 (fitur yang tidak didukung tercantum dalam topik ini) yang diterima dari server target backend (origin).
Selain itu, dengan header tertentu, Apigee mengambil tindakan berdasarkan perintahnya. Dalam beberapa kasus,
header cache HTTP/1.1 ini menggantikan perilaku apa pun yang ditentukan dalam kebijakan ResponseCache.
Misalnya, jika header Cache-Control
ditampilkan dari server backend, Anda dapat
mengatur perintah s-maxage
header agar berpotensi mengganti setelan habis masa berlaku lainnya
dalam kebijakan.
Header | Support |
---|---|
Cache-Control | Didukung pada respons yang ditampilkan dari server asal backend, tetapi tidak pada permintaan klien. Apigee mendukung subset perintah. |
Berakhir | Didukung. Dapat diganti. |
Tag Entitas (ETag) | Perilaku spesifik untuk If-Match dan If-None-Match. |
Jika-Diubah-Sejak | Pada permintaan GET, header akan diteruskan ke server asal meskipun terdapat entri cache yang valid. |
Menerima Encoding | Apigee mengirim respons yang dikompresi atau tidak dikompresi tergantung pada header yang masuk. |
Cache-Control
Apigee hanya mendukung header Cache-Control
pada respons yang ditampilkan dari server asal backend (spesifikasi HTTP/1.1 memungkinkan header Cache-Control
dalam permintaan klien dan respons server asal). Server asal dapat menyertakan endpoint target yang ditentukan dalam proxy API Apigee dan yang dibuat menggunakan panggilan API TargetServer.
Batasan dukungan Cache-Control
Apigee mendukung subset kemampuan header respons Cache-Control
yang ditentukan dalam spesifikasi HTTP/1.1. Harap perhatikan hal berikut:
- Apigee tidak mendukung header
Cache-Control
yang diterima bersama permintaan klien masuk. - Apigee hanya mendukung konsep cache publik. (Menurut spesifikasi HTTP,
Cache-Control
dapat bersifat publik (bersama) atau pribadi (satu pengguna).) - Apigee hanya mendukung subset perintah respons
Cache-Control
dalam spesifikasi HTTP/1.1. Lihat Dukungan untuk perintah header respons Cache-Control untuk mengetahui detailnya.
Dukungan untuk arahan header respons Cache-Control
Apigee mendukung perintah subset dari spesifikasi HTTP/1.1 pada respons dari server asal. Tabel berikut menjelaskan dukungan Apigee untuk perintah header respons HTTP Cache-Control.
Untuk informasi lebih detail tentang perintah yang tercantum di sini, lihat Cache-Control dalam spesifikasi HTTP/1.1.
Perintah Cache-Control | Cara Apigee memproses perintah |
cache-extension |
Tidak didukung. |
max-age |
Jika kebijakan ResponseCache Anda menetapkan elemen Perintah ini diganti oleh perintah |
must-revalidate |
Tidak didukung. Semua entri cache akan dihapus oleh Apigee segera setelah masa berlakunya habis. |
no-cache |
Apigee menyimpan respons origin ke dalam cache, tetapi harus divalidasi ulang dengan server asal sebelum digunakan untuk memenuhi permintaan klien berikutnya. Aturan ini memungkinkan origin menampilkan respons 304 Not Modified untuk menunjukkan bahwa respons harus ditampilkan dari cache, sehingga menyimpan pemrosesan yang diperlukan untuk menampilkan seluruh respons. Jika server asal menampilkan respons lengkap, server asal akan menggantikan entri cache yang ada. Setiap nama kolom yang ditentukan dengan perintah ini akan diabaikan. |
no-store |
Tidak didukung. |
no-transform |
Tidak didukung. |
private |
Tidak didukung. Jika perintah ini diterima, respons origin tidak akan di-cache. Semua nama kolom akan diabaikan. |
proxy-revalidate |
Tidak didukung. Semua entri cache akan dihapus oleh Apigee segera setelah masa berlakunya habis. |
public |
Apigee meng-cache respons asal, meskipun perintah lain menunjukkan sebaliknya. Sesuai spesifikasi HTTP/1.1, satu-satunya pengecualian untuk aturan ini adalah jika responsnya menyertakan header Otorisasi. |
s-maxage |
Jika kebijakan ResponseCache Anda menetapkan elemen Perintah ini menggantikan perintah |
Expires
Jika tanda UseResponseCacheHeaders
dalam kebijakan ResponseCache ditetapkan ke true
, Apigee dapat menggunakan header Expires
untuk menentukan time to live (TTL) dari entri yang di-cache. Header ini menentukan tanggal/waktu saat entri cache respons dianggap tidak berlaku. Header ini memungkinkan server memberi sinyal kapan saatnya menampilkan nilai yang di-cache
berdasarkan stempel waktu.
Format tanggal yang dapat diterima untuk header Expires
dijelaskan dalam spesifikasi
HTTP/1.1. Contoh:
Berakhir: Kam, 01 Des 1994 16:00:00 GMT
Untuk informasi selengkapnya tentang format tanggal/waktu HTTP, lihat Format Tanggal/Waktu dalam spesifikasi HTTP/1.1.
Untuk informasi selengkapnya tentang header Expires
, lihat
Definisi Kolom Header
dalam spesifikasi HTTP/1.1.
ETag
Tag entity (ETag) adalah ID yang terkait dengan resource yang diminta. Dengan menggunakan ETag, server dapat menentukan apakah resource yang diminta dan resource terkait yang tersimpan dalam cache cocok. Misalnya, server dapat meng-cache ulang respons jika tidak cocok dengan yang saat ini di-cache. API ini dapat menampilkan resource yang di-cache jika ETag-nya cocok.
Saat endpoint target mengirimkan respons kembali ke Apigee dengan ETag, Apigee akan menyimpan ETag ke dalam cache bersama dengan responsnya.
Anda dapat membaca lebih lanjut tentang Tag Entity di Parameter Protokol dalam spesifikasi HTTP/1.1.
Jika Cocok
Dengan header permintaan If-Match
, entitas yang di-cache akan dianggap aktual jika ETag di header cocok dengan ETag yang di-cache. Setiap permintaan selain GET yang menentukan header If-Match
akan diteruskan ke server asal untuk memastikan bahwa fasilitas caching origin memiliki
kesempatan untuk memproses permintaan tersebut.
Anda dapat membaca selengkapnya tentang If-Match
di
Header Field Definitions
dalam spesifikasi HTTP/1.1.
Jika Apigee menerima permintaan GET masuk dari klien yang menyertakan header If-Match
:
Jika | Selanjutnya |
---|---|
Header If-Match menentukan satu atau beberapa ETag |
|
Header If-Match menentukan "*" |
Permintaan diteruskan ke server origin untuk memastikan bahwa fasilitas caching origin memiliki kesempatan untuk memproses permintaan tersebut |
Ditemukan entri cache dengan URI permintaan yang sama, tetapi hanya berisi ETag yang lemah | Entri harus divalidasi ulang oleh server asal sebelum ditampilkan ke klien |
ETag berasal dari server asal. | ETag ditampilkan tanpa perubahan ke klien |
Jika-Tidak Ada-Cocok
Dengan header If-None-Match
, entity yang disimpan dalam cache akan dianggap aktual jika ETag di header tidak cocok dengan ETag yang di-cache. Permintaan selain GET yang berisi header ini diteruskan ke server asal.
Jika Apigee menerima permintaan GET masuk dengan header ini:
Jika | Selanjutnya |
---|---|
Header If-None-Match menentukan satu atau beberapa ETag |
|
Header |
Apigee menampilkan status 304 Not Modified |
Ditemukan entri cache dengan URI permintaan yang sama, tetapi hanya berisi ETag yang lemah | Entri harus divalidasi ulang oleh server asal sebelum Apigee menampilkannya ke klien |
Apigee menerima ETag dari server asal | ETag ditampilkan tanpa perubahan ke klien |
Jika-Diubah-Sejak
Jika Apigee menerima header If-Modified-Since
dalam permintaan GET, header tersebut akan diteruskan ke server asal meskipun terdapat entri cache yang valid.
Hal ini memastikan bahwa setiap update pada resource yang tidak melewati Apigee akan diperhitungkan. Jika server asal menampilkan entity baru, Apigee akan mengganti entri cache yang ada dengan nilai baru. Jika server menampilkan status 304 Not Modified, Apigee akan menampilkan nilai respons jika header Last-Modified
respons yang di-cache menunjukkan bahwa nilai tersebut belum berubah.
Terima Encoding
Saat permintaan masuk menyertakan header Accept-Encoding
dengan nilai
gzip
, deflate
, atau compress
, server asal akan merespons dengan
data terkompresi. Jika permintaan berikutnya datang tanpa header Accept-Encoding
,
permintaan tersebut akan menerima respons yang tidak dikompresi. Mekanisme cache respons Apigee mampu mengirim respons yang dikompresi dan tidak dikompresi, bergantung pada header yang masuk tanpa kembali ke server asal.
Anda dapat menambahkan nilai header Accept ke kunci cache agar kunci tersebut lebih bermakna untuk setiap item yang di-cache. Untuk detail selengkapnya, lihat "Mengonfigurasi kunci cache" di kebijakan Cache Respons.