Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Dukungan untuk header respons HTTP

Anda melihat dokumentasi Apigee Edge.
Buka dokumentasi Apigee X. info

Topik ini menjelaskan cara Edge menangani header caching HTTP/1.1 saat Anda menggunakan kebijakan ResponseCache. Apigee Edge 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 (asal) server.

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.

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

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

Header	Dukungan
Cache-Control	Didukung pada respons yang ditampilkan dari server asal backend, tetapi tidak pada permintaan klien. Edge mendukung subset perintah.
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 ada entri cache yang valid exists.
Terima Encoding	Edge mengirimkan respons terkompresi atau tidak terkompresi, bergantung pada header yang masuk.

Cache-Control

Apigee Edge 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 Edge dan yang dibuat menggunakan panggilan TargetServer API.

Batasan dukungan Cache-Control

Apigee Edge mendukung subset 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 berupa publik (dibagikan) atau pribadi (pengguna tunggal).)
Apigee Edge 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 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 Cache-Control HTTP.

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

Perintah Cache-Control	Cara Apigee Edge memproses perintah
`cache-extension`	Tidak didukung.
`max-age`	Jika kebijakan ResponseCache Anda menetapkan elemen `<UseResponseCacheHeaders>` ke `true`, respons dapat di-cache selama jumlah detik yang ditentukan oleh perintah ini. Perintah ini diganti oleh perintah `s-maxage` dan mengganti `Expires` header. Perintah ini juga dapat diganti oleh elemen `<ExpirySettings>` kebijakan. Untuk mengetahui informasi selengkapnya, lihat "Menetapkan masa berlaku entri cache" dan `<UseResponseCacheHeaders>` dalam kebijakan Response Cache. 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 nilai max-age yang disarankan (lebih lama dari yang diketahui klien).
`must-revalidate`	Tidak didukung. Semua entri cache dihapus oleh Apigee Edge segera setelah masa berlakunya berakhir.
`no-cache`	Edge menyimpan respons asal dalam cache, tetapi harus divalidasi ulang dengan server asal sebelum digunakan untuk memenuhi permintaan klien berikutnya. Aturan ini memungkinkan asal 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, respons tersebut akan menggantikan entri cache yang ada. Nama kolom apa pun yang ditentukan dengan perintah ini akan diabaikan. Catatan: Header HTTP/1.0, `Pragma: no-cache` diperlakukan sebagai setara dengan `Cache-Control: no-cache`.
`no-store`	Tidak didukung.
`no-transform`	Tidak didukung.
`private`	Tidak didukung. Jika perintah ini diterima, respons asal tidak akan di-cache. Nama kolom apa pun akan diabaikan.
`proxy-revalidate`	Tidak didukung. Semua entri cache dihapus oleh Apigee Edge segera setelah masa berlakunya berakhir.
`public`	Edge menyimpan respons asal dalam cache, meskipun perintah lain menunjukkan hal yang berbeda. 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 `<UseResponseCacheHeaders>` ke `true`, respons dapat di-cache selama jumlah detik yang ditentukan oleh perintah ini. Perintah ini mengganti perintah `max-age` dan header `Expires`. Perintah ini dapat diganti oleh elemen `<ExpirySettings>` kebijakan. Untuk mengetahui informasi selengkapnya, lihat "Menetapkan masa berlaku entri cache" dan `<UseResponseCacheHeaders>` dalam kebijakan Response Cache. 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 nilai s-maxage yang disarankan (lebih lama dari yang diketahui klien).

Berakhir

Jika flag 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 usang. Header ini memungkinkan server memberi sinyal kapan nilai yang di-cache dapat ditampilkan berdasarkan stempel waktu.

Catatan: Perintah header Cache-Control max-age dan s-maxage lebih diutamakan dan mengganti header Expires. Untuk mengetahui informasi selengkapnya, lihat "Menetapkan masa berlaku entri cache" dan <UseResponseCacheHeaders> dalam kebijakan Response Cache.

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

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Untuk 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 di masa mendatang berarti entri cache tidak pernah berakhir masa berlakunya, 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, a 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. Server dapat menampilkan resource yang di-cache jika ETag cocok.

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

Anda dapat membaca selengkapnya tentang Tag Entitas di Parameter Protokol dalam spesifikasi HTTP/1.1.

If-Match

Dengan header permintaan If-Match, entitas yang di-cache akan berlaku jika ETag di header cocok dengan ETag yang di-cache. Permintaan selain GET yang menentukan header If-Match diteruskan ke server asal untuk memastikan bahwa fasilitas caching asal memiliki peluang untuk memproses permintaan.

Anda dapat membaca selengkapnya tentang If-Match di Definisi Kolom Header 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	Apigee Edge mengambil entri cache yang belum berakhir masa berlakunya untuk resource yang ditentukan dan membandingkan ETag yang kuat pada entri cache tersebut dengan yang ditentukan dalam `If-Match` header. Jika kecocokan ditemukan, entri cache akan ditampilkan. Jika tidak, permintaan akan diteruskan ke server asal.
Header `If-Match` menentukan "*"	Permintaan diteruskan ke server asal untuk memastikan bahwa fasilitas caching asal memiliki peluang 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 tanpa perubahan ke klien

If-None-Match

Dengan header If-None-Match, entitas yang di-cache akan berlaku jika ETag di header tidak cocok dengan ETag yang di-cache. Permintaan selain GET yang berisi header ini diteruskan ke server asal.

Jika Edge menerima permintaan GET masuk dengan header ini:

Jika	Maka
Header `If-None-Match` menentukan satu atau beberapa ETag	Apigee Edge mengambil entri cache yang belum berakhir masa berlakunya untuk URI yang ditentukan dan membandingkan ETag yang kuat pada entri cache tersebut dengan yang ditentukan dalam `If-None-Match` header. Jika kecocokan ditemukan, Edge akan menampilkan status 304 Not Modified. Jika tidak ada kecocokan yang ditemukan, Edge akan meneruskan permintaan ke server asal.
Header `If-None-Match` menentukan "*" dan entri cache yang belum berakhir masa berlakunya untuk URI yang diminta ada	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 asal sebelum Edge menampilkannya ke klien
Edge menerima ETag dari server asal	ETag ditampilkan tanpa perubahan ke klien

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 update pada resource yang tidak diteruskan melalui Apigee Edge akan diperhitungkan. Jika server asal 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 tidak berubah.

Accept-Encoding

Saat permintaan masuk menyertakan header Accept-Encoding dengan nilai gzip, deflate atau compress, server asal akan merespons dengan data terkompresi. Saat permintaan berikutnya datang tanpa header Accept-Encoding, permintaan tersebut mengharapkan respons yang tidak terkompresi. Mekanisme caching respons Apigee dapat mengirimkan respons terkompresi dan tidak terkompresi, bergantung pada header yang 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" dalam kebijakan Response Cache.