Anda sedang melihat dokumentasi Apigee Edge.
Buka dokumentasi
Apigee X. info
Topik ini menjelaskan cara Edge menangani header cache HTTP/1.1 saat Anda menggunakan kebijakan ResponseCache. Apigee Edge saat ini mendukung sebagian header dan perintah cache HTTP/1.1 (fitur yang tidak didukung tercantum dalam topik ini) yang diterima dari server target backend (asal).
Selain itu, dengan header tertentu, Edge akan mengambil tindakan berdasarkan perintahnya. Dalam beberapa kasus, header cache HTTP/1.1 ini akan mengganti perilaku apa pun yang ditentukan dalam kebijakan ResponseCache.
Misalnya, jika header Cache-Control
ditampilkan dari server backend, Anda dapat
membuat perintah s-maxage
header berpotensi mengganti setelan masa berlaku lainnya
dalam kebijakan.
Header | Dukungan |
---|---|
Cache-Control | Didukung pada respons yang ditampilkan dari server origin backend, tetapi tidak untuk permintaan klien. Edge mendukung subset perintah. |
Berakhir | Didukung. Dapat diganti. |
Tag Entitas (ETag) | Perilaku spesifik untuk If-Match dan If-None-Match. |
If-Modified-Since | Pada permintaan GET, header diteruskan ke server asal meskipun entri cache yang valid ada. |
Accept-Encoding | Edge mengirim respons yang dikompresi atau tidak dikompresi, bergantung pada header yang masuk. |
Cache-Control
Apigee Edge hanya mendukung header Cache-Control
pada respons yang ditampilkan dari
server origin backend (spesifikasi HTTP/1.1 mengizinkan header Cache-Control
dalam
permintaan klien dan respons server origin). Server origin dapat menyertakan endpoint target yang ditentukan di proxy API Apigee Edge dan yang dibuat menggunakan panggilan API TargetServer.
Batasan dukungan Cache-Control
Apigee Edge mendukung sebagian kemampuan header respons Cache-Control
yang ditentukan dalam spesifikasi HTTP/1.1. Harap perhatikan hal berikut:
- Apigee Edge tidak mendukung header
Cache-Control
yang tiba dengan permintaan klien masuk. - Apigee Edge hanya mendukung konsep cache publik. (Menurut spesifikasi HTTP,
Cache-Control
dapat bersifat publik (dibagikan) atau pribadi (satu pengguna).) - Apigee Edge hanya mendukung sebagian perintah respons
Cache-Control
dalam spesifikasi HTTP/1.1. Lihat Dukungan untuk perintah header respons Cache-Control untuk mengetahui detailnya.
Dukungan untuk perintah header respons Cache-Control
Apigee mendukung perintah subset dari spesifikasi HTTP/1.1 pada respons dari server asal. Tabel berikut menjelaskan dukungan Apigee Edge untuk perintah header respons HTTP Cache-Control.
Untuk informasi yang lebih mendetail tentang perintah yang tercantum di sini, lihat Cache-Control dalam spesifikasi HTTP/1.1.
Direktif Cache-Control | Cara Apigee Edge 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 dihapus oleh Apigee Edge segera setelah masa berlakunya berakhir. |
no-cache |
Edge meng-cache respons origin, tetapi harus divalidasi ulang dengan server origin 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 menghemat pemrosesan yang diperlukan untuk menampilkan seluruh respons. Jika server asal menampilkan respons lengkap, server akan mengganti 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 dihapus oleh Apigee Edge segera setelah masa berlakunya berakhir. |
public |
Edge meng-cache respons origin, meskipun jika perintah lain menunjukkan sebaliknya. Sesuai dengan spesifikasi HTTP/1.1, satu-satunya pengecualian untuk aturan ini adalah jika respons menyertakan header Authorization. |
s-maxage |
Jika kebijakan ResponseCache Anda menetapkan elemen Perintah ini menggantikan perintah |
Berlaku sampai
Jika tanda UseResponseCacheHeaders
dalam kebijakan ResponseCache ditetapkan ke
true
, Edge dapat menggunakan header Expires
untuk menentukan time to live
(TTL) entri yang di-cache. Header ini menentukan tanggal/waktu setelah entri cache respons dianggap tidak berlaku lagi. Header ini memungkinkan server memberikan sinyal kapan boleh menampilkan nilai yang di-cache
berdasarkan stempel waktu.
Format tanggal yang dapat diterima untuk header Expires
dijelaskan dalam spesifikasi HTTP/1.1. Contoh:
Berakhir: Kamis, 01 Desember 1994 pukul 16.00.00 GMT
Untuk mengetahui informasi mendetail 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 yang di-cache terkait cocok. Misalnya, server dapat meng-cache ulang respons jika tidak cocok dengan yang saat ini di-cache. Metode ini dapat menampilkan resource yang di-cache jika ETag-nya cocok.
Saat endpoint target mengirim respons kembali ke Edge dengan ETag, Edge akan meng-cache ETag beserta respons.
Anda dapat membaca selengkapnya tentang Tag Entitas di Parameter Protokol dalam spesifikasi HTTP/1.1.
If-Match
Dengan header permintaan If-Match
, entity yang di-cache adalah yang terbaru jika ETag dalam header cocok dengan ETag yang di-cache. Setiap permintaan selain GET yang menentukan header If-Match
akan diteruskan ke server origin untuk memastikan bahwa setiap fasilitas penyimpanan dalam cache origin memiliki
peluang untuk memproses permintaan.
Anda dapat membaca selengkapnya tentang If-Match
di
Header Field Definitions
dalam spesifikasi HTTP/1.1.
Jika Edge menerima permintaan GET masuk dari klien yang menyertakan header If-Match
:
Jika | Maka |
---|---|
Header If-Match menentukan satu atau beberapa ETag |
|
Header If-Match menentukan "*" |
Permintaan diteruskan ke server origin untuk memastikan bahwa fasilitas cache origin memiliki kesempatan untuk memproses permintaan |
Entri cache dengan URI permintaan yang sama ditemukan, tetapi hanya berisi ETag yang lemah | Entri harus divalidasi ulang oleh server asal sebelum ditampilkan ke klien |
ETag berasal dari server asal. | ETag ditampilkan ke klien tanpa perubahan |
If-None-Match
Dengan header If-None-Match
, entity yang di-cache adalah yang terbaru jika ETag dalam header tidak cocok dengan ETag yang di-cache. Permintaan selain GET yang berisi header ini akan diteruskan ke server origin.
Jika Edge menerima permintaan GET masuk dengan header ini:
Jika | Maka |
---|---|
Header If-None-Match menentukan satu atau beberapa ETag |
|
Header |
Edge menampilkan status 304 Not Modified |
Entri cache dengan URI permintaan yang sama ditemukan, tetapi hanya berisi ETag yang lemah | Entri harus divalidasi ulang oleh server origin sebelum Edge menampilkannya ke klien |
Edge menerima ETag dari server origin | ETag ditampilkan ke klien tanpa perubahan |
If-Modified-Since
Jika Apigee Edge menerima header If-Modified-Since
dalam permintaan GET, header tersebut akan diteruskan ke server asal meskipun ada entri cache yang valid.
Hal ini memastikan bahwa setiap pembaruan pada resource yang tidak melewati Apigee Edge
diperhitungkan. Jika server origin menampilkan entitas baru, Edge akan mengganti entri cache
yang ada dengan nilai baru. Jika server menampilkan status 304 Not Modified, Edge akan menampilkan
nilai respons jika header Last-Modified
respons yang di-cache menunjukkan bahwa respons tersebut
belum berubah.
Terima Encoding
Jika permintaan masuk menyertakan header Accept-Encoding
dengan nilai
gzip
, deflate
, atau compress
, server asal akan merespons dengan
data yang dikompresi. Jika permintaan berikutnya datang tanpa header Accept-Encoding
,
permintaan tersebut mengharapkan respons yang tidak dikompresi. Mekanisme penyimpanan respons dalam cache Apigee dapat mengirim
respons yang dikompresi dan tidak dikompresi, bergantung pada header yang masuk tanpa kembali
ke server origin.
Anda dapat menambahkan nilai header Accept ke kunci cache agar kunci lebih bermakna untuk setiap item yang di-cache. Untuk mengetahui detail selengkapnya, lihat "Mengonfigurasi kunci cache" di Kebijakan Cache Respons.