Halaman ini diterjemahkan oleh Cloud Translation API.

Dukungan untuk header respons HTTP

Halaman ini berlaku untuk Apigee dan Apigee Hybrid.

Lihat 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 direktif 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 arahan header tersebut. 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 membuat direktif s-maxage header berpotensi menggantikan setelan masa berlaku lainnya dalam kebijakan.

Catatan: Menggunakan header untuk memengaruhi kunci cache dan TTL entri cache Anda dapat membuat Apigee menggunakan header respons saat membuat kunci cache respons dan menetapkan TTL entri cache. Untuk melakukannya, Anda menggunakan elemen tanda kebijakan ResponseCache berikut:

<UseResponseCacheHeaders> -- Jika disetel ke true, Apigee akan mempertimbangkan header respons HTTP yang digunakan saat menyetel "time to live" (TTL) respons dalam cache. Untuk mengetahui detailnya, lihat "Menetapkan masa berlaku entri cache" dan <UseResponseCacheHeaders> di kebijakan Cache Respons.
<UseAcceptHeader> -- Jika disetel ke true, Apigee akan menggunakan header Accept respons untuk menambah kunci cache. Untuk mengetahui informasi selengkapnya, lihat <UseAcceptHeader> di kebijakan Response Cache.

Header	Dukungan
Cache-Control	Didukung pada respons yang ditampilkan dari server asal backend, tetapi tidak pada permintaan klien. Apigee mendukung subset direktif.
Berakhir	Didukung. Dapat diganti.
Tag Entitas (ETag)	Perilaku khusus 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	Apigee mengirimkan respons yang dikompresi atau tidak dikompresi, bergantung pada header yang masuk.

Cache-Control

Apigee hanya mendukung header Cache-Control pada respons yang ditampilkan dari server asal backend (spesifikasi HTTP/1.1 mengizinkan header Cache-Control dalam permintaan klien dan respons server asal). Server asal dapat mencakup 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 tiba dengan permintaan klien masuk.
Apigee hanya mendukung konsep cache publik. (Menurut spesifikasi HTTP, Cache-Control dapat bersifat publik (dibagikan) atau pribadi (pengguna tunggal).)
Apigee hanya mendukung sebagian kecil perintah respons Cache-Control dalam spesifikasi HTTP/1.1. Lihat Dukungan untuk perintah header respons Cache-Control untuk mengetahui detailnya.

Dukungan untuk direktif header respons Cache-Control

Apigee mendukung subset direktif dari spesifikasi HTTP/1.1 pada respons dari server asal. Tabel berikut menjelaskan dukungan Apigee untuk direktif header respons HTTP Cache-Control.

Untuk informasi yang lebih mendetail tentang direktif yang tercantum di sini, lihat Cache-Control dalam spesifikasi HTTP/1.1.

Petunjuk Cache-Control	Cara Apigee memproses arahan
`cache-extension`	Tidak didukung.
`max-age`	Jika kebijakan ResponseCache Anda menyetel elemen `<UseResponseCacheHeaders>` ke `true`, respons dapat di-cache selama beberapa detik yang ditentukan oleh direktif ini. Petunjuk ini digantikan oleh petunjuk `s-maxage` dan menggantikan header `Expires`. Kebijakan ini juga dapat diganti oleh elemen `<ExpirySettings>` kebijakan. Untuk mengetahui informasi selengkapnya, lihat "Menetapkan masa berlaku entri cache" dan `<UseResponseCacheHeaders>` di kebijakan Cache Respons. Catatan: Konten yang di-cache dengan kebijakan ResponseCache akan mempertahankan nilai max-age yang ditetapkan oleh asalnya. Artinya, saat diambil dari cache, konten mungkin lebih lama dari yang ditunjukkan oleh nilai max-age-nya (lebih lama dari yang diketahui klien).
`must-revalidate`	Tidak didukung. Semua entri cache dihapus oleh Apigee segera setelah masa berlakunya berakhir.
`no-cache`	Apigee menyimpan respons asal dalam cache, tetapi respons tersebut harus divalidasi ulang dengan server asal sebelum digunakan untuk memenuhi permintaan klien berikutnya. Aturan ini memungkinkan origin untuk menampilkan respons 304 Not Modified guna menunjukkan bahwa respons harus ditampilkan dari cache, sehingga menghemat pemrosesan yang diperlukan untuk menampilkan seluruh respons. Jika server asal menampilkan respons penuh, respons tersebut akan menggantikan entri cache yang ada. Nama kolom yang ditentukan dengan direktif ini akan diabaikan. Catatan: Header HTTP/1.0, `Pragma: no-cache`, dianggap setara dengan `Cache-Control: no-cache`.
`no-store`	Tidak didukung.
`no-transform`	Tidak didukung.
`private`	Tidak didukung. Jika perintah ini diterima, respons asal tidak di-cache. Nama kolom apa pun akan diabaikan.
`proxy-revalidate`	Tidak didukung. Semua entri cache dihapus oleh Apigee segera setelah masa berlakunya berakhir.
`public`	Apigee menyimpan respons origin dalam cache, meskipun ada petunjuk lain yang 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 menyetel elemen `<UseResponseCacheHeaders>` ke `true`, respons dapat di-cache selama beberapa detik yang ditentukan oleh direktif ini. Perintah ini menggantikan perintah `max-age` dan header `Expires`. Atribut ini dapat diganti oleh elemen `<ExpirySettings>` kebijakan. Untuk mengetahui informasi selengkapnya, lihat "Menetapkan masa berlaku entri cache" dan `<UseResponseCacheHeaders>` di kebijakan Cache Respons. Catatan: Konten yang di-cache dengan kebijakan ResponseCache akan mempertahankan nilai s-maxage yang ditetapkan oleh asalnya. Artinya, saat diambil dari cache, konten mungkin lebih lama dari yang ditunjukkan oleh nilai s-maxage-nya (lebih lama dari yang diketahui klien).

Expires

Jika tanda UseResponseCacheHeaders dalam kebijakan ResponseCache disetel ke true, Apigee 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. Header ini memungkinkan server memberi sinyal kapan nilai yang di-cache dapat ditampilkan berdasarkan stempel waktu.

Catatan: Arahan header Cache-Control max-age dan s-maxage lebih diutamakan dan menggantikan header Expires. Untuk mengetahui informasi selengkapnya, lihat "Menetapkan masa berlaku entri cache" dan <UseResponseCacheHeaders> di kebijakan Cache Respons.

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 mengetahui informasi mendetail tentang format tanggal/waktu HTTP, lihat Format Tanggal/Waktu dalam spesifikasi HTTP/1.1.

Catatan: Meskipun bagian 14.21 spesifikasi menunjukkan bahwa nilai Expires lebih dari satu tahun ke depan berarti entri cache tidak pernah berakhir, Apigee menafsirkan nilai tersebut berarti entri harus di-cache hingga tanggal dan waktu yang ditentukan.

Untuk mengetahui informasi selengkapnya tentang header Expires, lihat Definisi Kolom Header dalam spesifikasi HTTP/1.1.

ETag

Tag entitas (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 melakukan kembali caching respons jika tidak cocok dengan yang saat ini di-cache. Respons dapat menampilkan resource yang di-cache jika ETag cocok.

Saat endpoint target mengirimkan respons kembali ke Apigee dengan ETag, Apigee akan meng-cache ETag beserta responsnya.

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 akan tetap terbaru jika ETag di header cocok dengan ETag yang di-cache. Semua permintaan selain GET yang menentukan header If-Match diteruskan ke server origin untuk memastikan bahwa fasilitas caching origin memiliki peluang untuk memproses permintaan.

Anda dapat membaca selengkapnya tentang If-Match di Definisi Kolom Header dalam spesifikasi HTTP/1.1.

Jika Apigee menerima permintaan GET masuk dari klien yang menyertakan header If-Match:

Jika	Dulu
Header `If-Match` menentukan satu atau beberapa ETag	Apigee mengambil entri cache yang belum habis masa berlakunya untuk resource yang ditentukan dan membandingkan ETag kuat pada entri yang di-cache tersebut dengan ETag yang ditentukan di header `If-Match`. Jika kecocokan ditemukan, entri cache akan ditampilkan. Jika tidak, permintaan akan diteruskan ke server origin.
Header `If-Match` menentukan "*"	Permintaan diteruskan ke server origin untuk memastikan bahwa fasilitas caching origin memiliki kesempatan untuk memproses permintaan
Entri cache dengan URI permintaan yang sama ditemukan, tetapi hanya berisi ETag lemah	Entri harus divalidasi ulang oleh server asal sebelum ditampilkan ke klien
ETag berasal dari server asal.	ETag ditampilkan tanpa perubahan ke klien

If-None-Match

Dengan header If-None-Match, entity yang di-cache akan menjadi yang terbaru jika ETag di header tidak cocok dengan ETag yang di-cache. Permintaan selain GET yang berisi header ini diteruskan ke server origin.

Jika Apigee menerima permintaan GET masuk dengan header ini:

Jika	Dulu
Header `If-None-Match` menentukan satu atau beberapa ETag	Apigee mengambil entri cache yang belum habis masa berlakunya untuk URI yang ditentukan dan membandingkan ETag kuat pada entri yang di-cache tersebut dengan ETag yang ditentukan dalam header `If-None-Match`. Jika kecocokan ditemukan, Apigee akan menampilkan status 304 Not Modified. Jika tidak ada kecocokan yang ditemukan, Apigee akan meneruskan permintaan ke server origin.
Header `If-None-Match` menentukan "*" dan entri yang di-cache yang belum habis masa berlakunya untuk URI yang diminta ada	Apigee menampilkan status 304 Not Modified
Entri cache dengan URI permintaan yang sama ditemukan, tetapi hanya berisi ETag 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

If-Modified-Since

Jika Apigee 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 update pada resource yang tidak melewati Apigee akan diperhitungkan. Jika server asal menampilkan entitas 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 respons tersebut tidak berubah.

Accept-Encoding

Saat permintaan masuk menyertakan header Accept-Encoding dengan nilai gzip, deflate, atau compress, server asal merespons dengan data yang dikompresi. Saat permintaan berikutnya datang tanpa header Accept-Encoding, mereka mengharapkan respons yang tidak dikompresi. Mekanisme penyimpanan dalam cache respons Apigee mampu mengirim respons terkompresi dan tidak terkompresi, bergantung pada header masuk tanpa kembali ke server asal.

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.