Halaman ini diterjemahkan oleh Cloud Translation API.

Dukungan untuk header respons HTTP

Halaman ini berlaku untuk Apigee dan Apigee hybrid.

Topik ini menjelaskan cara Apigee menangani header penyimpanan cache HTTP/1.1 saat Anda menggunakan Kebijakan ResponseCache. Apigee saat ini mendukung subset header caching HTTP/1.1 dan perintah (fitur yang tidak didukung tercantum dalam topik ini) yang diterima dari target backend (asal) server web.

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 membuat perintah s-maxage header berpotensi mengganti setelan habis masa berlaku lainnya dalam kebijakan.

Catatan: Menggunakan header untuk memengaruhi kunci cache dan TTL entri cache Anda dapat menggunakan Apigee menggunakan header respons saat membuat kunci cache respons dan menyetel TTL entri cache. Yang akan dilakukan ini, Anda akan menggunakan elemen flag dari kebijakan ResponseCache:

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

Header	Dukungan
Cache-Control	Didukung pada respons yang ditampilkan dari server origin backend, tetapi tidak untuk permintaan klien. Apigee mendukung subset perintah.
Berakhir	Didukung. Dapat diganti.
Tag Entitas (ETag)	Perilaku spesifik untuk If-Match dan Jika-Tidak Ada-Kecocokan.
Jika-Diubah-Sejak	Pada permintaan GET, header diteruskan ke server asal meskipun entri cache yang valid sudah ada.
Accept-Encoding	Apigee mengirim respons yang dikompresi atau tidak dikompresi tergantung pada {i>header<i}.

Cache-Control

Apigee mendukung header Cache-Control hanya pada respons yang ditampilkan dari server origin backend (spesifikasi HTTP/1.1 mengizinkan header Cache-Control di permintaan klien dan respons server origin). Server asal dapat menyertakan kedua endpoint target ditentukan dalam proxy Apigee API dan yang dibuat menggunakan panggilan API TargetServer.

Batasan dukungan Cache-Control

Apigee mendukung subset dari kemampuan header respons Cache-Control yang ditetapkan dalam spesifikasi HTTP/1.1. Harap perhatikan hal berikut:

Apigee tidak mendukung header Cache-Control yang masuk dengan pesan masuk terhadap permintaan klien.
Apigee hanya mendukung gagasan cache publik. (Menurut situs web HTTP spesifikasi, Cache-Control dapat bersifat publik (bersama) atau pribadi (tunggal tertentu).)
Apigee hanya mendukung subset perintah respons Cache-Control di 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 origin server web. Tabel berikut menjelaskan dukungan Apigee untuk header respons Cache-Control HTTP direktif.

Untuk informasi yang lebih detail tentang perintah yang tercantum di sini, lihat Kontrol-Cache pada spesifikasi HTTP/1.1.

Perintah Cache-Control	Cara Apigee memproses perintah
`cache-extension`	Tidak didukung.
`max-age`	Jika kebijakan ResponseCache Anda menetapkan `<UseResponseCacheHeaders>` ke `true`, respons dapat di-cache selama jumlah detik yang ditentukan oleh direktif ini. Perintah ini diganti oleh perintah `s-maxage` dan menggantikan Header `Expires`. Hal ini juga dapat diganti oleh aturan Elemen `<ExpirySettings>`. Untuk informasi selengkapnya, lihat "Menyetel entri cache masa berlaku" dan `<UseResponseCacheHeaders>` inci Kebijakan Cache Respons. Catatan: Konten yang di-cache dengan kebijakan ResponseCache akan tetap dipertahankan nilai usia maksimum yang ditetapkan oleh asalnya. Hal ini berarti bahwa ketika diambil dari cache, konten mungkin lebih lama dari nilai usia maksimum yang disarankan (lebih lama dari klien sebelumnya).
`must-revalidate`	Tidak didukung. Semua entri cache akan dihapus oleh Apigee segera setelah berakhir.
`no-cache`	Apigee menyimpan respons origin dalam cache, tetapi harus divalidasi ulang dengan server origin sebelum digunakan untuk memenuhi permintaan klien berikutnya. Aturan ini mengizinkan origin mengembalikan respons 304 Not Modified untuk menunjukkan bahwa respons ditampilkan dari cache, sehingga menyimpan pemrosesan yang diperlukan untuk mengembalikan seluruh respons. Jika server origin menampilkan respons lengkap, server tersebut akan menggantikan entri cache yang ada. Apa saja nama kolom yang ditetapkan dengan perintah ini akan diabaikan. Catatan: Header HTTP/1.0, `Pragma: no-cache` adalah diperlakukan setara dengan `Cache-Control: no-cache`.
`no-store`	Tidak didukung.
`no-transform`	Tidak didukung.
`private`	Tidak didukung. Jika perintah ini diterima, respons origin tidak akan di-cache. Apa saja nama kolom diabaikan.
`proxy-revalidate`	Tidak didukung. Semua entri cache akan dihapus oleh Apigee segera setelah berakhir.
`public`	Apigee menyimpan respons origin dalam cache, bahkan ketika perintah lain menunjukkan sebaliknya. Sesuai dengan spesifikasi HTTP/1.1, satu-satunya pengecualian untuk aturan ini adalah jika respons menyertakan Header otorisasi.
`s-maxage`	Jika kebijakan ResponseCache Anda menetapkan `<UseResponseCacheHeaders>` ke `true`, respons dapat di-cache selama jumlah detik yang ditentukan oleh direktif ini. Perintah ini menggantikan perintah `max-age` dan Header `Expires`. Hal ini dapat diganti dengan atribut Elemen `<ExpirySettings>`. Untuk informasi selengkapnya, lihat "Menyetel entri cache masa berlaku" dan `<UseResponseCacheHeaders>` inci Kebijakan Cache Respons. Catatan: Konten yang di-cache dengan kebijakan ResponseCache akan tetap dipertahankan nilai s-maxage yang ditetapkan berdasarkan asalnya. Hal ini berarti bahwa ketika diambil dari cache, konten mungkin lebih lama dari nilai s-maxage yang disarankan (lebih lama dari klien sebelumnya).

Expires

Jika tanda UseResponseCacheHeaders di kebijakan ResponseCache ditetapkan ke true, Apigee dapat menggunakan header Expires untuk menentukan waktu live (TTL) dari entri yang di-cache. Header ini menetapkan tanggal/waktu saat entri cache respons dianggap basi. Header ini memungkinkan server memberikan sinyal saat dapat menampilkan nilai yang di-cache berdasarkan stempel waktu.

Catatan: Perintah header Cache-Control max-age dan s-maxage lebih diprioritaskan dan menggantikan Header Expires. Untuk mengetahui informasi selengkapnya, lihat "Menetapkan akhir masa berlaku entri cache" dan <UseResponseCacheHeaders> inci Kebijakan Cache Respons.

Format tanggal yang dapat diterima untuk header Expires dijelaskan di HTTP/1.1 spesifikasi pendukung. Contoh:

Berakhir: Kam, 01 Desember 1994 16:00:00 GMT

Untuk informasi selengkapnya tentang format tanggal/waktu HTTP, lihat Format Tanggal/Waktu pada spesifikasi HTTP/1.1.

Catatan: Meskipun pasal 14.21 spesifikasi menunjukkan bahwa Nilai Expires lebih dari satu tahun di masa mendatang berarti bahwa entri cache tidak pernah masa berlaku habis, Apigee menafsirkan nilai tersebut untuk berarti bahwa entri harus di-cache sampai tanggal dan waktu yang ditentukan.

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

ETag

Tag entitas (ETag) adalah ID yang terkait dengan resource yang diminta. Menggunakan ETag, sebuah server bisa menentukan apakah sumber daya yang diminta dan sumber daya yang di-cache cocok atau tidak. Sebagai misalnya, server dapat meng-cache ulang respons jika tidak cocok dengan yang telah di-cache saat ini. Ini dapat mengembalikan sumber daya yang di-cache jika ETag-nya cocok.

Saat endpoint target mengirimkan respons kembali ke Apigee dengan ETag, Apigee akan menyimpan ETag dalam cache dengan respons.

Anda dapat membaca lebih lanjut tentang Tag Entity di Parameter Protokol pada spesifikasi HTTP/1.1.

Jika-Cocok

Dengan header permintaan If-Match, entity yang di-cache akan berlaku jika ETag di sesuai dengan ETag yang ada dalam cache. Semua permintaan selain GET yang menentukan If-Match diteruskan ke server asal untuk memastikan bahwa fasilitas penyimpanan dalam cache kesempatan untuk memproses permintaan.

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

Jika Apigee menerima permintaan GET masuk dari klien yang menyertakan If-Match {i>header<i}:

Jika	Selanjutnya
Header `If-Match` menentukan satu atau beberapa ETag	Apigee mengambil entri cache yang belum habis masa berlakunya untuk resource yang ditentukan dan membandingkan semua ETag yang kuat pada entri yang di-cache dengan yang ditentukan dalam Header `If-Match`. Jika ditemukan kecocokan, entri cache akan ditampilkan. Jika tidak, permintaan akan diteruskan ke server asal.
Header `If-Match` menentukan "*"	Permintaan diteruskan ke server origin untuk memastikan bahwa setiap cache origin fasilitas 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 dikembalikan ke klien
ETag berasal dari server origin.	ETag dikembalikan ke klien tanpa perubahan

Jika Tidak Ada Kecocokan

Dengan header If-None-Match, entity yang di-cache akan berlaku jika ETag di dalam header tidak sesuai dengan ETag yang di-cache. Permintaan selain GET yang berisi hal ini header yang diteruskan ke server origin.

Jika Apigee menerima permintaan GET masuk dengan header ini:

Jika	Selanjutnya
Header `If-None-Match` menentukan satu atau beberapa ETag	Apigee mengambil entri cache yang belum habis masa berlakunya untuk URI yang ditentukan dan membandingkan semua ETag yang kuat pada entri yang di-cache dengan yang ditentukan dalam Header `If-None-Match`. Jika kecocokan ditemukan, Apigee akan menampilkan status 304 Not Modified. Jika tidak ditemukan kecocokan yang ditemukan, Apigee meneruskan permintaan ke server origin.
Header `If-None-Match` menentukan "*" dan entri 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 yang lemah	Entri harus divalidasi ulang oleh server asal sebelum Apigee mengembalikannya ke klien
Apigee menerima ETag dari server asal	ETag dikembalikan ke klien tanpa perubahan

Jika telah Diubah Sejak

Jika Apigee menerima header If-Modified-Since dalam permintaan GET, diteruskan ke server origin meskipun ada entri cache yang valid.

Hal ini memastikan bahwa setiap update pada resource yang tidak melewati Apigee akan diperhitungkan. Jika server origin menampilkan entity baru, Apigee akan mengganti cache yang sudah ada entri 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 memiliki tidak berubah.

Accept-Encoding

Saat permintaan masuk menyertakan header Accept-Encoding dengan nilai gzip, deflate, atau compress, server asal merespons dengan data terkompresi. Jika permintaan berikutnya datang tanpa header Accept-Encoding, mereka mengharapkan respons yang tidak dikompresi. Mekanisme {i>cache<i} respons Apigee mampu mengirim baik respons yang dikompresi maupun yang tidak dikompresi bergantung pada {i>header<i} yang masuk tanpa kembali ke server origin.

Anda dapat menambahkan nilai header Accept ke kunci cache agar kunci lebih bermakna bagi setiap item yang disimpan dalam cache. Untuk detail selengkapnya, lihat "Mengonfigurasi kunci cache" inci Kebijakan Cache Respons.