Ringkasan penyimpanan dalam cache

Respons yang dapat di-cache adalah respons HTTP yang dapat disimpan dan diambil dengan cepat oleh Cloud CDN, sehingga memungkinkan waktu pemuatan yang lebih cepat. Tidak semua respons HTTP dapat disimpan dalam cache.

Mode cache

Dengan mode cache, Anda dapat mengontrol faktor yang menentukan apakah Cloud CDN meng-cache konten Anda.

Cloud CDN menawarkan tiga mode cache, yang menentukan cara meng-cache respons, apakah Cloud CDN mematuhi perintah cache yang dikirim oleh origin, dan cara TTL cache diterapkan.

Mode cache yang tersedia ditampilkan dalam tabel berikut:

Mode cache Perilaku
CACHE_ALL_STATIC Otomatis menyimpan respons yang berhasil dalam cache dengan konten statis yang tidak tidak dapat di-cache. Respons origin yang menetapkan perintah caching yang valid juga di-cache.

Perilaku ini adalah default untuk backend yang mengaktifkan Cloud CDN yang dibuat menggunakan Google Cloud CLI atau REST API.
USE_ORIGIN_HEADERS Memerlukan respons origin yang berhasil untuk menetapkan perintah cache yang valid dan header cache yang valid. Respons yang berhasil tanpa perintah ini akan diteruskan dari origin.
FORCE_CACHE_ALL Menyimpan respons yang berhasil ke dalam cache tanpa syarat, yang akan menggantikan perintah cache apa pun yang ditetapkan oleh origin. Mode ini tidak sesuai jika backend menayangkan konten pribadi per pengguna (dapat diidentifikasi pengguna), seperti respons HTML atau API dinamis.

Respons error dapat di-cache meskipun tidak ada perintah cache yang valid.

Sebelum Anda menetapkan mode cache ke FORCE_CACHE_ALL, pertimbangkan perilaku berikut:

  • Untuk URL atau cookie yang ditandatangani, FORCE_CACHE_ALL akan mengganti usia maksimum yang ditentukan melalui setelan Usia maksimum entri cache di konsol Google Cloud atau opsi gcloud --signed-url-cache-max-age.

  • FORCE_CACHE_ALL mengubah time to live (TTL) konten yang di-cache sebelumnya. Perubahan ini dapat menyebabkan beberapa entri yang sebelumnya dianggap masih baru (karena memiliki TTL yang lebih lama dari header origin) dianggap sudah tidak berlaku, dan dapat menyebabkan beberapa entri yang sebelumnya dianggap sudah tidak berlaku dianggap masih baru.

  • FORCE_CACHE_ALL mengganti perintah cache (Cache-Control dan Expires), tetapi tidak mengganti header respons origin lainnya. Secara khusus, header Vary dapat menyembunyikan penyimpanan dalam cache meskipun mode cache-nya adalah FORCE_CACHE_ALL. Untuk mengetahui informasi selengkapnya, lihat Header Vary.

Untuk petunjuk penyiapan, lihat Menetapkan mode cache.

Konten statis

Konten statis adalah konten yang selalu sama, meskipun diakses oleh pengguna yang berbeda. CSS yang Anda gunakan untuk menata gaya situs, JavaScript untuk menyediakan konten interaktif, video, dan gambar biasanya tidak berubah untuk setiap pengguna untuk URL tertentu (kunci cache), sehingga mendapatkan manfaat dari di-cache di seluruh jaringan edge global Cloud CDN.

Jika Anda menetapkan mode cache ke CACHE_ALL_STATIC, dan respons tidak memiliki perintah caching eksplisit di header Cache-Control atau Expires, Cloud CDN akan secara otomatis menyimpan respons tersebut dalam cache untuk hal berikut:

  • Aset Web, termasuk CSS (text/css), JavaScript (application/javascript), dan semua font web, termasuk WOFF2 (font/woff2)
  • Gambar, termasuk JPEG (image/jpg) dan PNG (image/png)
  • Video, termasuk H.264, H.265, dan MP4 (video/mp4)
  • File audio, termasuk MP3 (audio/mpeg) dan MP4 (audio/mp4)
  • Dokumen berformat, termasuk PDF (application/pdf)

Tabel berikut memberikan ringkasan.

Kategori Jenis MIME
Aset web text/css text/ecmascript text/javascript application/javascript
Font Content-Type apa pun yang cocok dengan font/*
Gambar Content-Type apa pun yang cocok dengan image/*
Video Content-Type apa pun yang cocok dengan video/*
Audio Content-Type apa pun yang cocok dengan audio/*
Jenis dokumen berformat application/pdf dan application/postscript

Cloud CDN memeriksa header respons HTTP Content-Type, yang mencerminkan jenis MIME konten yang ditayangkan.

Perhatikan hal berikut:

  • Software server web origin Anda harus menetapkan Content-Type untuk setiap respons. Banyak server web yang otomatis menetapkan header Content-Type, termasuk NGINX, Varnish, dan Apache.

  • Cloud Storage menetapkan header Content-Type secara otomatis saat Anda menggunakan konsol Google Cloud atau Google Cloud CLI untuk mengupload konten.

  • Cloud Storage selalu menyediakan header Cache-Control ke Cloud CDN. Jika tidak ada nilai yang dipilih secara eksplisit, nilai default akan dikirim. Akibatnya, semua respons Cloud Storage yang berhasil akan di-cache sesuai dengan nilai default Cloud Storage, kecuali jika Anda secara eksplisit menyesuaikan metadata kontrol cache untuk objek di Cloud Storage atau menggunakan mode FORCE_CACHE_ALL untuk mengganti nilai yang dikirim oleh Cloud Storage.

  • Jika ingin menyimpan jenis konten text/html dan application/json dalam cache, Anda harus menetapkan header Cache-Control eksplisit dalam respons, berhati-hatilah agar tidak menyimpan data satu pengguna secara tidak sengaja dan menayangkannya kepada semua pengguna.

Jika respons dapat di-cache berdasarkan jenis MIME-nya, tetapi memiliki header respons Cache-Control private atau no-store, atau header Set-Cookie, respons tersebut tidak akan di-cache. Untuk mempelajari lebih lanjut, lihat aturan cacheability.

Jenis konten lainnya, seperti HTML (text/html) dan JSON (application/json), tidak di-cache secara default untuk respons yang berhasil. Jenis respons ini biasanya bersifat dinamis (per pengguna). Contohnya mencakup keranjang belanja, halaman produk dengan personalisasi pengguna, dan respons API yang diautentikasi. Namun, Caching negatif, jika diaktifkan, masih dapat menyebabkannya di-cache untuk kode status tertentu.

Cloud CDN tidak menggunakan ekstensi file di jalur URL untuk menentukan apakah respons dapat disimpan dalam cache karena banyak respons valid yang dapat disimpan dalam cache tidak ditampilkan di URL.

Konten yang dapat di-cache

Cloud CDN menyimpan respons dalam cache yang memenuhi semua persyaratan di bagian ini. Beberapa persyaratan ini ditentukan oleh RFC 7234, dan persyaratan lainnya khusus untuk Cloud CDN.

Cloud CDN dapat mengubah kumpulan kondisi yang tepat secara berkala saat meng-cache konten. Jika Anda ingin secara eksplisit mencegah Cloud CDN meng-cache konten Anda, ikuti panduan dalam RFC 7234 untuk menentukan cara menentukan respons yang dijamin tidak dapat di-cache. Lihat juga bagian konten yang tidak dapat di-cache berdasarkan header origin.

Cloud CDN menyimpan respons dalam cache jika semua hal berikut terpenuhi.

Atribut Persyaratan
Dilayani oleh Layanan backend, bucket backend, atau backend eksternal yang mengaktifkan Cloud CDN
Sebagai respons terhadap Permintaan GET
Kode status

200, 203, 204, 206, 300, 301, 302, 307, 308, 404, 405, 410, 421, 451, atau 501.
Keaktualan

Respons memiliki header Cache-Control dengan perintah max-age atau s-maxage, atau header Expires dengan stempel waktu di masa mendatang.

Untuk respons yang dapat di-cache tanpa usia (misalnya, dengan no-cache), perintah public harus diberikan secara eksplisit.

Dengan mode cache CACHE_ALL_STATIC, jika tidak ada perintah keaktualan, respons yang berhasil dengan jenis konten statis masih memenuhi syarat untuk di-cache.

Dengan mode cache FORCE_CACHE_ALL, setiap respons yang berhasil memenuhi syarat untuk di-cache. Hal ini dapat menyebabkan penyimpanan konten pribadi per pengguna ke dalam cache. Anda hanya boleh menetapkan FORCE_CACHE_ALL di backend yang tidak menayangkan konten pribadi atau dinamis, seperti bucket Cloud Storage.

Jika caching negatif diaktifkan dan kode status cocok dengan kode yang TTL-nya ditentukan oleh caching negatif, respons tersebut memenuhi syarat untuk di-cache, bahkan tanpa perintah keaktualan eksplisit.
Konten

Untuk origin HTTP/1, respons harus berisi header Content-Length, Content-Range, atau Transfer-Encoding: chunked yang valid.

Untuk origin yang menggunakan versi protokol HTTP yang lebih canggih (HTTP/2 dan yang lebih baru), respons tidak perlu memiliki header tersebut.
Ukuran Kurang dari atau sama dengan ukuran maksimum.

Untuk respons dengan ukuran antara 10 MiB dan 100 GiB, lihat batasan cacheability tambahan yang dijelaskan dalam permintaan rentang byte.

Untuk bucket backend Cloud Storage, ikuti saran tambahan berikut:

Secara default, saat objek bersifat publik dan tidak menentukan metadata Cache-Control, Cloud Storage akan menetapkan header Cache-Control: public, max-age=3600 ke objek. Anda dapat menetapkan nilai yang berbeda menggunakan metadata Cache-Control.

Untuk contoh yang menunjukkan cara mengonfigurasi Load Balancer Aplikasi eksternal dengan bucket backend, lihat Menyiapkan Cloud CDN dengan bucket backend.

Ukuran maksimum

Cloud CDN menerapkan ukuran maksimum untuk setiap respons. Setiap respons dengan isi yang lebih besar dari ukuran maksimum tidak di-cache, tetapi masih dikirim ke klien.

Ukuran maksimum bervariasi, bergantung pada apakah server origin mendukung permintaan rentang byte.

Server asal mendukung permintaan rentang byte Server origin tidak mendukung permintaan rentang byte
100 GiB (107.374.182.400 byte) 10 MiB (10.485.760 byte)

Hampir semua server web modern (termasuk NGINX, Apache, dan Varnish) mendukung permintaan rentang byte.

Konten yang tidak dapat di-cache berdasarkan header origin

Ada pemeriksaan yang memblokir penyimpanan dalam cache respons. Cloud CDN dapat mengubah kumpulan kondisi yang tepat secara berkala untuk meng-cache konten, jadi jika Anda ingin secara eksplisit mencegah Cloud CDN meng-cache konten, ikuti panduan dalam standar (RFC 7234) untuk menentukan cara menentukan respons yang dijamin tidak dapat di-cache.

Cloud CDN tidak menyimpan respons dalam cache jika tidak memenuhi persyaratan untuk Konten yang dapat di-cache, atau jika salah satu hal berikut benar.

Atribut Persyaratan
Dilayani oleh Layanan backend atau backend eksternal yang tidak mengaktifkan Cloud CDN
Cookie Memiliki header Set-Cookie
Header Vary Memiliki nilai selain Accept, Accept-Encoding, Access-Control-Request-Headers, Access-Control-Request-Method, Origin, Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site, X-Goog-Allowed-Resources, X-Origin, atau salah satu header yang dikonfigurasi untuk menjadi bagian dari setelan kunci cache.
Perintah respons Respons memiliki header Cache-Control dengan perintah no-store atau private (kecuali jika menggunakan mode cache FORCE_CACHE_ALL, dalam hal ini header Cache-Control akan diabaikan)
Permintaan perintah Permintaan memiliki perintah Cache-Control: no-store
Minta otorisasi Permintaan memiliki header Authorization, kecuali jika diganti oleh Cache-Control respons.
Ukuran Lebih besar dari ukuran maksimum

Jika Cache-Control: no-store atau private ada, tetapi konten masih di-cache, hal ini disebabkan oleh salah satu hal berikut:

  • Penandatanganan URL dikonfigurasi.
  • Mode cache Cloud CDN disetel untuk memaksa penyimpanan cache semua respons.

Mencegah penyimpanan ke dalam cache

Untuk mencegah informasi pribadi di-cache di cache Cloud CDN, lakukan hal berikut:

  1. Pastikan mode cache Cloud CDN tidak disetel ke mode FORCE_CACHE_ALL, yang meng-cache semua respons yang berhasil tanpa syarat.
  2. Sertakan header Cache-Control: private dalam respons yang tidak boleh disimpan di cache Cloud CDN, atau header Cache-Control: no-store dalam respons yang tidak boleh disimpan di cache apa pun, bahkan cache browser web.
  3. Jangan tanda tangani URL yang memberikan akses ke informasi pribadi. Jika diakses menggunakan URL yang ditandatangani, konten tersebut berpotensi memenuhi syarat untuk di-cache, terlepas dari perintah Cache-Control apa pun dalam respons.
  4. Untuk permintaan origin (pengisian cache) yang menyertakan header permintaan Authorization, Cloud CDN hanya meng-cache respons yang menyertakan perintah kontrol cache public, must-revalidate, atau s-maxage saat mode cache ditetapkan ke USE_ORIGIN_HEADERS atau CACHE_ALL_STATIC. Tindakan ini mencegah konten per pengguna dan konten yang memerlukan autentikasi secara tidak sengaja di-cache. Mode cache FORCE_CACHE_ALL tidak memiliki batasan ini.

Header respons kustom

Dengan header respons kustom, Anda dapat menentukan header yang ditambahkan Load Balancer Aplikasi klasik ke respons yang di-proxy. Header respons kustom memungkinkan Anda mencerminkan status cache ke klien, data geografis klien, dan header respons statis Anda sendiri.

Untuk mengetahui petunjuknya, lihat Mengonfigurasi header respons kustom.

Kunci cache

Setiap entri cache di cache Cloud CDN diidentifikasi oleh kunci cache. Saat permintaan masuk ke cache, cache akan mengonversi URI permintaan menjadi kunci cache, lalu membandingkannya dengan kunci entri yang di-cache. Jika menemukan kecocokan, cache akan menampilkan objek yang terkait dengan kunci tersebut.

Untuk layanan backend, Cloud CDN secara default menggunakan URI permintaan lengkap sebagai kunci cache. Misalnya, https://example.com/images/cat.jpg adalah URI lengkap untuk permintaan tertentu untuk objek cat.jpg. String ini digunakan sebagai kunci cache default. Hanya permintaan dengan string yang sama persis ini yang cocok. Permintaan untuk http://example.com/images/cat.jpg atau https://example.com/images/cat.jpg?user=user1 tidak cocok.

Untuk bucket backend, defaultnya adalah kunci cache terdiri dari URI tanpa protokol atau host. Secara default, hanya parameter kueri yang diketahui oleh Cloud Storage yang disertakan sebagai bagian dari kunci cache (misalnya, "generation").

Dengan demikian, untuk bucket backend tertentu, URI berikut akan di-resolve ke objek yang di-cache yang sama:

  • http://example.com/images/cat.jpg
  • https://example.com/images/cat.jpg
  • https://example.com/images/cat.jpg?user=user1
  • http://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2
  • https://media.example.com/images/cat.jpg
  • https://www.example.com/images/cat.jpg

Anda dapat mengubah bagian URI yang digunakan dalam kunci cache. Meskipun nama file dan jalur harus selalu menjadi bagian dari kunci, Anda dapat menyertakan atau menghapus kombinasi protokol, host, atau string kueri saat menyesuaikan kunci cache. Menggunakan kunci cache menjelaskan cara menyesuaikan kunci cache.

Bagian URI Penyesuaian Contoh URL yang memiliki kunci cache yang sama
Protokol Hapus protokol dari kunci cache.
  • https://example.com/images/cat.jpg
  • http://example.com/images/cat.jpg
Host Hapus host dari kunci cache.
  • https://example.com/images/cat.jpg
  • https://example2.com/images/cat.jpg
String kueri

Hapus string kueri dari kunci cache.

Menghapus atau menyertakan bagian string kueri secara selektif.
  • https://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2

Selain menyertakan atau menghilangkan seluruh string kueri, Anda dapat menggunakan bagian string kueri menggunakan daftar sertakan dan daftar kecualikan.

Daftar menyertakan string kueri

Anda dapat mengontrol secara selektif parameter string kueri yang digabungkan Cloud CDN ke dalam kunci cache. Misalnya, jika Anda membuat daftar penyertaan user, https://example.com/images/cat.jpg?user=user1&color=blue akan membuat kunci cache https://example.com/images/cat.jpg?user=user1 yang juga cocok dengan https://example.com/images/cat.jpg?user=user1&color=red.

Untuk menggunakan opsi ini, Anda harus menyertakan string kueri, menentukan daftar yang disertakan yang tidak kosong, dan tidak menentukan daftar yang dikecualikan.

Daftar menyertakan string kueri untuk kunci cache Cloud Storage

Menyertakan parameter kueri URL dalam kunci cache untuk bucket Cloud Storage membantu mendukung cache busting. Cache busting memungkinkan pengguna mengambil versi baru file yang telah diupload, meskipun versi sebelumnya masih di-cache secara valid berdasarkan setelan TTL.

Anda dapat menggunakan daftar yang disertakan dengan parameter string kueri di kunci cache yang digunakan untuk menayangkan respons dari bucket backend. Meskipun Cloud Storage tidak menayangkan konten atau rute yang berbeda berdasarkan parameter kueri, Anda dapat memilih untuk menyertakan parameter yang memungkinkan Anda melakukan cache-bust konten statis yang disimpan di bucket Cloud Storage.

Misalnya, Anda dapat menambahkan parameter kueri ?version=VERSION atau ?hash=HASH yang didasarkan pada konten pokok. Hal ini membatasi kebutuhan untuk secara proaktif membatalkan validasi konten dan selaras dengan alur kerja pengembangan web modern, dengan framework dan URL web menggunakan hash konten untuk menghindari penayangan objek yang sudah tidak berlaku di seluruh deployment.

Karena menyertakan parameter kueri dalam kunci cache hanya bersifat keikutsertaan, Cloud CDN tidak mendukung pengecualian parameter kueri dari kunci cache ke bucket backend.

Daftar pengecualian string kueri

Anda dapat mengontrol secara selektif parameter string kueri yang diabaikan Cloud CDN menggunakan daftar pengecualian. Misalnya, jika Anda membuat daftar pengecualian user, semua parameter string kueri kecuali user akan digunakan dalam kunci cache.

Dengan daftar pengecualian yang dikonfigurasi dan input https://example.com/images/cat.jpg?user=user1&color=blue, Cloud CDN akan membuat kunci cache https://example.com/images/cat.jpg?color=blue yang juga cocok dengan https://example.com/images/cat.jpg?user=user2&color=blue, tetapi tidak cocok dengan https://example.com/images/cat.jpg?user=user1&color=red.

Untuk menggunakan opsi ini, Anda harus menyertakan string kueri, menentukan daftar pengecualian yang tidak kosong, dan tidak menentukan daftar penyertaan.

Urutan parameter kueri

Kunci cache yang dihasilkan tidak bergantung pada urutan parameter kueri.

Misalnya, parameter kueri berikut menghasilkan kunci cache yang sama:

  • info=123&variant=13e&geography=US
  • geography=US&variant=13e&info=123

Setelan kunci cache header HTTP dan cookie HTTP

Anda dapat meningkatkan rasio hit cache dan offload origin dengan setelan konfigurasi kunci cache berikut.

  • Untuk bucket dan layanan backend: Gunakan header HTTP sebagai bagian dari kunci cache dengan menyertakan header bernama dalam konfigurasi kunci cache.
  • Khusus untuk layanan backend: Gunakan cookie HTTP bernama sebagai kunci cache, seperti untuk pengujian A/B (multi-variasi), canarying, dan skenario serupa.

Permintaan cache yang menyertakan header HTTP atau cookie HTTP tambahan dalam permintaan akan di-cache pada permintaan ketiga di lokasi cache untuk kunci cache tersebut. Hal ini mengurangi dampak nilai header atau cookie dengan kardinalitas tinggi terhadap tingkat penghapusan cache Anda. Dalam kondisi normal dan kondisi traffic pengguna, hal ini tidak akan terlihat dan membantu memastikan bahwa konten populer tetap di-cache.

Menyertakan header permintaan

Untuk meng-cache variasi respons tambahan, Anda dapat menyertakan header permintaan tambahan dalam kunci cache.

Beberapa header tidak diizinkan dalam kunci cache karena biasanya memiliki kardinalitas yang sangat tinggi. Pada umumnya, nilai header ini unik per pengguna (Cookie,Authorization) atau memiliki ribuan kemungkinan nilai (Referer, User-Agent, Accept). Misalnya, header User-Agent dapat memiliki lebih dari 5.000 nilai unik mengingat banyaknya browser, perangkat pengguna, dan sistem operasi. Jenis header ini akan memiliki dampak negatif yang parah pada rasio hit cache.

Hanya nama kolom header HTTP yang valid yang diterima sesuai RFC 7230. Nama kolom header tidak peka huruf besar/kecil, dan duplikat akan ditolak.

Secara opsional, Anda dapat mengonfigurasi server origin untuk menyertakan header permintaan kunci cache yang dikonfigurasi dalam respons Vary. Hal ini tidak diperlukan untuk Cloud CDN, tetapi dapat membantu cache downstream. Untuk mengetahui informasi selengkapnya, lihat Header yang bervariasi.

Cloud CDN tidak mengizinkan header berikut disertakan dalam daftar header:

  • Accept
  • Accept-Encoding
  • Authority, karena hal ini dikontrol oleh konfigurasi (cdnPolicy.includeHost)
  • Authorization, biasanya per pengguna seperti pada token Bearer OAuth
  • CDN-Loop
  • Connection
  • Content-MD5
  • Content-Type
  • Cookie
  • Date
  • Forwarded, sering kali per klien atau per proxy
  • From
  • Host, karena hal ini dikontrol oleh konfigurasi (cdnPolicy.includeHost)
  • If-Match, If-Modified-Since, atau If-None-Match
  • Origin
  • Proxy-Authorization
  • Range
  • Referer (atau Referrer)
  • User-Agent
  • Want-Digest
  • X-CSRFToken dan X-CSRF-Token seperti yang digunakan oleh Django dan Ruby on Rails
  • X-Forwarded-For, sering kali per klien atau per proxy
  • X-User-IP
  • Setiap header yang diawali dengan hal berikut:
    • Access-Control-, seperti Access-Control-Request-Headers dan Access-Control-Request-Method
    • Sec-Fetch-
    • Sec-GFE-
    • Sec-Google-
    • X-Amz-
    • X-GFE-
    • X-Goog-
    • X-Google-

Header yang sama dengan nilai yang berbeda

Misalkan pengguna mengirim beberapa header dengan nama yang sama dengan nilai header yang berbeda—misalnya:

My-Header: Value1
My-Header: Value2

Dalam hal ini, Cloud CDN mengubah permintaan dengan mengasumsikan bahwa header harus mengikuti konvensi standar yang memungkinkan beberapa header memiliki beberapa nilai. Cloud CDN menggabungkannya ke dalam daftar yang dipisahkan koma untuk dikirim ke backend, sehingga seolah-olah klien mengirim hal berikut:

My-Header: Value1, Value2

Menyertakan cookie bernama

Cookie HTTP adalah penyambungan name=value, dan permintaan dapat menyertakan beberapa cookie HTTP, baik yang dipisahkan dengan titik koma di baris yang sama, atau sebagai header permintaan Cookie terpisah dengan satu cookie per header.

Anda dapat memberikan daftar hingga lima nama cookie.

Agen pengguna (seperti browser web) sering kali membatasi jumlah cookie yang disimpan per domain hingga 4 KB; pastikan untuk tidak mengirim terlalu banyak (atau terlalu besar) cookie, karena agen pengguna mungkin tidak mengirim semua cookie dalam permintaan. Hal ini dapat memengaruhi apakah pengguna menerima respons tertentu yang di-cache.

Jika Anda menayangkan konten statis dari nama host yang berbeda dengan tempat Anda mengeluarkan cookie, pastikan atribut Domain cookie (dan atribut Path) memungkinkan cookie dikirim bersama dengan permintaan untuk konten statis.

Jika permintaan menyertakan beberapa instance nama cookie yang sama, hanya instance pertama yang akan dihormati.

Perintah kontrol cache

Perintah kontrol cache HTTP memengaruhi perilaku Cloud CDN, seperti yang diuraikan dalam tabel berikut.

T/A menunjukkan bahwa perintah tidak berlaku untuk permintaan atau respons.

Perintah Permintaan Respons
no-store Jika ada dalam permintaan, Cloud CDN akan mematuhinya dan tidak menyimpan respons dalam cache.

Respons dengan no-store tidak di-cache.

Hal ini dapat diganti per backend dengan mode cache FORCE_CACHE_ALL.

no-cache Perintah permintaan no-cache diabaikan untuk mencegah klien berpotensi memulai atau memaksa validasi ulang ke origin.

Respons dengan no-cache di-cache, tetapi harus divalidasi ulang dengan origin sebelum ditayangkan.

Hal ini dapat diganti per backend dengan mode cache FORCE_CACHE_ALL.

public T/A

Perintah ini tidak diperlukan untuk cacheability, tetapi merupakan praktik terbaik untuk menyertakannya untuk konten yang harus di-cache oleh proxy.

private T/A

Respons dengan perintah private tidak di-cache oleh Cloud CDN, meskipun respons tersebut dianggap dapat di-cache. Klien (seperti browser) mungkin masih menyimpan hasil dalam cache.

Hal ini dapat diganti per backend dengan mode cache FORCE_CACHE_ALL. Gunakan no-store untuk mencegah semua penyimpanan ke cache respons.

max-age=SECONDS Perintah permintaan max-age akan diabaikan. Respons yang di-cache akan ditampilkan seolah-olah header ini tidak disertakan dalam permintaan. Respons dengan perintah max-age di-cache hingga SECONDS yang ditentukan.
s-maxage=SECONDS T/A

Respons dengan perintah s-maxage di-cache hingga SECONDS yang ditentukan.

Jika max-age dan s-maxage ada, s‑maxage akan digunakan oleh Cloud CDN.

Respons dengan perintah ini tidak ditayangkan jika sudah tidak berlaku.

s-max-age (dua tanda hubung) tidak valid untuk tujuan penyimpanan dalam cache.

min-fresh=SECONDS Perintah permintaan min-fresh akan diabaikan. Respons yang di-cache akan ditampilkan seolah-olah header ini tidak disertakan dalam permintaan. T/A
max-stale=SECONDS

Perintah permintaan max-stale menentukan keusangan maksimum (dalam detik) yang bersedia diterima klien.

Cloud CDN mematuhi hal ini, dan menampilkan respons cache yang sudah tidak berlaku hanya jika keusangan respons kurang dari arahan max-stale. Jika tidak, permintaan akan divalidasi ulang sebelum ditayangkan.

 T/A
stale-while-revalidate=SECONDS T/A

Respons dengan stale-while-revalidate ditayangkan ke klien hingga SECONDS saat validasi ulang dilakukan secara asinkron.

Perilaku ini dapat diaktifkan untuk semua respons dengan menetapkan cdnPolicy.serveWhileStale di backend.

stale-if-error=SECONDS Perintah permintaan stale-if-error akan diabaikan. Respons yang di-cache ditampilkan seolah-olah header ini tidak disertakan dalam permintaan.

Header respons ini tidak berpengaruh.

must-revalidate T/A

Respons dengan must-revalidate divalidasi ulang dengan server asal setelah masa berlakunya berakhir.

Respons dengan perintah ini tidak ditayangkan jika sudah tidak berlaku.

proxy-revalidate

Respons dengan proxy-revalidate divalidasi ulang dengan server origin setelah masa berlakunya berakhir.

Respons dengan perintah ini tidak ditayangkan jika sudah tidak berlaku.

immutable T/A Tidak ada efek. Nilai ini diteruskan ke klien dalam respons.
no-transform T/A Tidak ada transformasi yang diterapkan oleh Cloud CDN.
only-if-cached Perintah permintaan only-if-cached akan diabaikan. Respons yang di-cache ditampilkan seolah-olah header ini tidak disertakan dalam permintaan. T/A

Jika memungkinkan, Cloud CDN berupaya untuk mematuhi RFC (HTTP RFC 7234), tetapi lebih memilih mengoptimalkan offload cache dan meminimalkan dampak yang dapat ditimbulkan klien terhadap hit rate dan beban origin secara keseluruhan.

Untuk respons yang menggunakan header Expires HTTP/1.1:

  • Nilai header Expires harus berupa tanggal HTTP yang valid seperti yang ditentukan dalam RFC 7231.
  • Nilai tanggal di masa lalu, tanggal yang tidak valid, atau nilai 0 menunjukkan bahwa konten telah habis masa berlakunya dan memerlukan validasi ulang.
  • Jika header Cache-Control ada dalam respons, Cloud CDN akan mengabaikan header Expires.

Kehadiran header Expires mendatang yang valid dalam respons memungkinkan respons di-cache, dan tidak memerlukan perintah cache lain untuk ditentukan.

Header Pragma HTTP/1.0, jika ada dalam respons, akan diabaikan dan diteruskan apa adanya ke klien. Permintaan klien dengan header ini diteruskan ke origin dan tidak memengaruhi cara respons ditayangkan oleh Cloud CDN.

Header Vary

Header Vary menunjukkan bahwa respons bervariasi bergantung pada header permintaan klien. Selain URI permintaan, Cloud CDN mematuhi header Vary yang disertakan server origin dalam respons. Misalnya, jika respons menentukan Vary: Accept, Cloud CDN akan menggunakan satu entri cache untuk permintaan yang menentukan Accept: image/webp,image/*,*/*;q=0.8 dan entri cache lainnya untuk permintaan yang menentukan Accept: */*.

Tabel di bagian Konten yang tidak dapat di-cache mencantumkan header Vary yang memungkinkan konten di-cache. Nilai header Vary lainnya mencegah konten di-cache.

Mode cache FORCE_CACHE_ALL tidak mengganti perilaku ini. Header Vary penting untuk menghindari keracunan cache di antara beberapa kemungkinan respons server origin. FORCE_CACHE_ALL akan berbahaya jika menyebabkan respons tersebut disimpan dalam cache.

Header Vary terkadang digunakan saat menayangkan konten yang dikompresi. Cloud CDN tidak mengompresi atau mendekompresi respons itu sendiri (kecuali jika kompresi dinamis diaktifkan), tetapi dapat menayangkan respons yang telah dikompresi oleh server origin. Jika server origin Anda memilih untuk menayangkan konten yang dikompresi atau konten yang tidak dikompresi berdasarkan nilai header permintaan Accept-Encoding, pastikan respons menentukan Vary: Accept-Encoding.

Saat menggunakan header HTTP dalam kunci cache, Cloud CDN meng-cache beberapa salinan respons berdasarkan nilai header permintaan yang ditentukan, mirip dengan dukungan Vary, tetapi tanpa memerlukan server asal untuk menentukan header respons Vary secara eksplisit. Jika origin menentukan header kunci cache dalam respons Vary, Cloud CDN akan memperlakukan respons dengan benar, sama seperti jika header tidak disebutkan dalam respons Vary.

Waktu habis masa berlaku dan permintaan validasi

Waktu habis masa berlaku entri cache menentukan berapa lama entri cache tetap valid. Nilai yang diberikan oleh nilai s-maxage (atau max-age atau expires) memungkinkan validasi ulang otomatis konten yang sudah tidak berlaku dan di-cache oleh pengguna.

Saat menerima permintaan, Cloud CDN akan mencari entri cache yang sesuai dan memeriksa usianya. Jika entri cache ada dan cukup baru, respons dapat ditayangkan dari cache. Jika waktu habis masa berlakunya telah berlalu, Cloud CDN akan mencoba memvalidasi ulang entri cache dengan menghubungi salah satu backend Anda. Hal ini dilakukan sebelum menayangkan respons, kecuali jika Anda mengaktifkan serve-while-stale, yang berarti validasi ulang dilakukan secara asinkron.

Untuk beberapa mode cache, Anda dapat menetapkan nilai TTL. Untuk mengetahui informasi selengkapnya, lihat Menggunakan setelan dan penggantian TTL.

Mode cache memengaruhi cara keaktualan ditentukan.

Mode cache Perilaku validasi
CACHE_ALL_STATIC Header origin (header Cache-Control: s-maxage, Cache-Control: max-age, atau Expires) akan dikonsultasikan untuk menentukan keaktualan. Untuk konten statis, jika header origin tidak ada, default_ttl yang dikonfigurasi akan menentukan keaktualan. Setelah konten statis lebih lama dari default_ttl, Cloud CDN akan memvalidasinya kembali.
USE_ORIGIN_HEADERS Setiap entri cache di cache Cloud CDN memiliki waktu habis masa berlaku yang ditentukan oleh header Cache-Control: s-maxage, Cache-Control: max-age, atau Expires sesuai dengan RFC 7234.
FORCE_CACHE_ALL Sebagai ganti header origin, default_ttl yang dikonfigurasi menentukan keaktualan. Setelah konten lebih lama dari default_ttl, Cloud CDN akan memvalidasinya kembali.

Jika ada lebih dari satu, Cache-Control: s-maxage lebih diutamakan daripada Cache-Control: max-age, dan Cache-Control: max-age lebih diutamakan daripada Expires.

Secara default, jika nilai waktu habis masa berlaku melebihi 30 hari (2.592.000 detik), Cloud CDN akan memperlakukan nilai habis masa berlaku seolah-olah 2.592.000 detik. Klien downstream masih melihat nilai max-age dan s-maxage yang akurat, meskipun melebihi 30 hari.

Pengusiran

Tidak ada jaminan bahwa entri cache akan tetap berada di cache hingga masa berlakunya berakhir karena entri yang tidak populer dapat dihapus sebelum masa berlakunya berakhir kapan saja untuk memberi ruang bagi konten baru. Sebagai batas atas, entri cache yang tidak diakses selama 30 hari akan otomatis dihapus.

Untuk informasi selengkapnya, lihat Penghapusan dan masa berlaku.

Menggunakan permintaan bersyarat untuk validasi

Cloud CDN dapat mencoba menggunakan informasi dalam header respons yang di-cache untuk memvalidasi entri cache dengan backend. Hal ini terjadi jika kedua hal berikut terpenuhi:

  • Respons yang sebelumnya di-cache memiliki header Last-Modified atau ETag.
  • Permintaan klien adalah permintaan GET yang tidak berisi header If-Modified-Since atau If-None-Match.

Cloud CDN melakukan validasi ini dengan sedikit perbedaan, bergantung pada apakah respons di-cache menggunakan permintaan rentang byte:

  • Jika respons di-cache menggunakan permintaan rentang byte, Cloud CDN akan memulai permintaan validasi terpisah yang menyertakan header If-Modified-Since dan If-None-Match.
  • Jika tidak, Cloud CDN akan menambahkan header If-Modified-Since dan If-None-Match ke permintaan klien dan meneruskan permintaan yang diubah ke backend.

Jika salinan yang di-cache masih yang terbaru, backend dapat memvalidasi entri cache yang ada dengan mengirimkan respons 304 Not Modified. Dalam hal ini, backend hanya mengirim header respons, bukan isi respons. Cloud CDN menyisipkan header respons baru ke dalam cache, memperbarui waktu habis masa berlaku, dan menayangkan header respons baru serta isi respons yang di-cache ke klien.

Jika respons yang di-cache sebelumnya tidak memiliki header Last-Modified atau ETag, Cloud CDN akan mengabaikan entri cache yang sudah tidak berlaku dan meneruskan permintaan klien ke backend yang tidak diubah.

Dukungan untuk permintaan rentang byte

Respons yang memenuhi kriteria berikut menunjukkan bahwa server origin mendukung permintaan rentang byte:

  • Kode status: 200 OK atau 206 Partial Content
  • Header: Accept-Ranges: bytes
  • Header: Content-Length, dan untuk respons 206 Partial Content, nilai Content-Range yang menunjukkan panjang lengkap objek asal. Misalnya, Content-length: 0-100/999 dapat di-cache, sedangkan Content-length: 0-100/* tidak.
  • Header: Last-Modified dan ETag dengan validator yang kuat.

Cloud Storage mendukung permintaan rentang byte untuk sebagian besar objek. Namun, Cloud Storage tidak mendukung permintaan rentang byte untuk objek dengan metadata Content-Encoding: gzip kecuali jika permintaan klien menyertakan header Accept- Encoding: gzip. Jika Anda memiliki objek Cloud Storage yang lebih besar dari 10 MB, pastikan objek tersebut tidak memiliki metadata Content-Encoding: gzip. Untuk informasi tentang cara mengedit metadata objek, lihat Melihat dan mengedit metadata objek.

Software server web populer juga mendukung permintaan rentang byte. Lihat dokumentasi untuk server web Anda guna mengetahui detail tentang cara mengaktifkan dukungan. Untuk informasi selengkapnya tentang permintaan rentang byte, lihat spesifikasi HTTP.

Jika server asal mendukung permintaan rentang byte, cache Cloud CDN menolak untuk menyimpan respons yang dapat di-cache saat pertama kali diminta jika salah satu dari hal berikut berlaku:

  • Isi respons tidak lengkap karena klien hanya meminta sebagian konten.
  • Isi respons lebih besar dari 1 MB (1.048.576 byte).

Jika hal ini terjadi dan respons akan memenuhi persyaratan cacheability normal, cache akan mencatat bahwa server asal mendukung permintaan rentang byte untuk kunci cache tersebut dan meneruskan respons server asal ke klien.

Jika cache tidak ditemukan, cache akan memeriksa apakah server origin diketahui mendukung permintaan rentang byte. Jika permintaan rentang byte diketahui didukung untuk kunci cache, cache tidak akan meneruskan permintaan klien ke Load Balancer Aplikasi eksternal. Sebagai gantinya, cache memulai permintaan pengisian cache rentang byte sendiri untuk bagian konten yang tidak ada.

Server asal menampilkan respons 206 Partial Content saat Cloud CDN memulai permintaan pengisian cache rentang byte-nya sendiri. Agar respons 206 Partial Content dipertimbangkan saat meng-cache, respons tersebut harus menyertakan header Content-Range dengan perintah complete-length yang tidak menyertakan tanda bintang, misalnya,0-100/999. Cloud CDN kemudian menyimpan respons 206 Partial Content yang ditampilkan dalam cache dan menggunakannya untuk merespons permintaan klien berikutnya untuk konten tersebut.

Cache menyimpan respons 206 Partial Content hanya jika diterima sebagai respons terhadap permintaan rentang byte yang dimulai cache. Karena cache tidak memulai permintaan rentang byte kecuali jika sebelumnya telah mencatat bahwa server origin mendukung permintaan rentang byte untuk kunci cache tersebut, cache tertentu tidak menyimpan konten yang lebih besar dari 1 MB hingga konten tersebut diakses untuk kedua kalinya.

Karena sifatnya yang terdistribusi, Cloud CDN terkadang mungkin mengambil bagian akhir dari origin lebih dari sekali per lokasi. Hal ini hanya memengaruhi beberapa permintaan pertama per kunci cache.

Permintaan diciutkan (penggabungan)

Penggabungan permintaan (juga disebut penggabungan) secara aktif menggabungkan beberapa permintaan pengisian cache yang didorong pengguna untuk kunci cache yang sama menjadi satu permintaan origin per node edge. Hal ini dapat secara aktif mengurangi beban pada origin, dan berlaku untuk permintaan item (respons yang diambil secara langsung) dan permintaan chunk, dengan Cloud CDN menggunakan permintaan Range untuk mengambil objek yang lebih besar secara lebih efisien.

Penciutan permintaan diaktifkan secara default.

Permintaan yang diciutkan berperilaku dengan cara berikut:

  • Permintaan yang diciutkan mencatat permintaan yang ditampilkan klien dan permintaan pengisian cache (diciutkan).
  • Pemimpin sesi yang diciutkan digunakan untuk membuat permintaan pengisian asal.
  • Atribut permintaan yang bukan bagian dari kunci cache, seperti header User-Agent atau Accept-Encoding, hanya mencerminkan pemimpin sesi yang diciutkan.
  • Permintaan yang tidak memiliki kunci cache yang sama tidak dapat diciutkan.

Diagram berikut menunjukkan cara penggabungan permintaan:

Cloud CDN dengan penggabungan permintaan diaktifkan.
Cloud CDN dengan penggabungan permintaan diaktifkan (klik untuk memperbesar).

Sebagai perbandingan, dengan penggabungan permintaan dinonaktifkan atau untuk permintaan yang tidak dapat digabungkan, jumlah permintaan asal dan respons dapat sama dengan jumlah klien yang mencoba mengambil objek yang tidak di-cache.

Cloud CDN tanpa penggabungan permintaan yang diaktifkan.
Cloud CDN tanpa penggabungan permintaan diaktifkan (klik untuk memperbesar).

Untuk semua jenis permintaan, pengecilan diaktifkan secara default. Untuk jenis permintaan item, Anda dapat menonaktifkan pengecilan. Sebaiknya nonaktifkan penyingkatan untuk permintaan item dalam skenario yang sangat sensitif terhadap latensi, seperti penayangan iklan, dengan beban asal bukan merupakan pertimbangan.

Tabel berikut meringkas perilaku default dan kemampuan konfigurasi untuk berbagai jenis permintaan.

Jenis permintaan Perilaku default Dapat Dikonfigurasi Manfaat menciutkan
Permintaan bagian Aktif Tidak Dapat secara signifikan mengurangi bandwidth origin
Permintaan item Aktif Ya Dapat mengurangi volume permintaan origin

Untuk menonaktifkan penggabungan permintaan item menggunakan Google Cloud CLI untuk bucket backend yang mereferensikan bucket Cloud Storage:

gcloud

Gunakan perintah gcloud compute backend-services atau backend-buckets:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --no-request-coalescing

Untuk mengaktifkan penyingkatan permintaan item di bucket backend menggunakan Google Cloud CLI:

gcloud

Gunakan perintah gcloud compute backend-buckets:

gcloud compute backend-buckets update BACKEND_BUCKET_NAME \
    --request-coalescing

Untuk mengaktifkan penyingkatan permintaan item menggunakan Google Cloud CLI untuk layanan backend, termasuk grup VM dan backend eksternal:

gcloud

Gunakan perintah gcloud compute backend-services:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --request-coalescing

Permintaan yang dimulai oleh Cloud CDN

Jika server origin Anda mendukung permintaan rentang byte, Cloud CDN dapat mengirim beberapa permintaan ke server origin sebagai reaksi terhadap satu permintaan klien. Cloud CDN dapat memulai dua jenis permintaan: permintaan validasi dan permintaan rentang byte.

Jika respons yang menunjukkan bahwa server origin Anda mendukung permintaan rentang byte untuk kunci cache tertentu telah berakhir masa berlakunya, Cloud CDN akan memulai permintaan validasi untuk mengonfirmasi bahwa konten belum berubah dan bahwa server origin Anda masih mendukung permintaan rentang untuk konten. Jika server origin Anda merespons dengan respons 304 Not Modified, Cloud CDN akan melanjutkan untuk menayangkan konten menggunakan rentang byte. Jika tidak, Cloud CDN akan meneruskan respons server origin Anda ke klien. Anda mengontrol waktu habis masa berlaku menggunakan header respons Cache-Control dan Expires.

Jika cache tidak ditemukan, Cloud CDN akan memulai permintaan pengisian cache untuk serangkaian rentang byte yang tumpang-tindih dengan permintaan klien. Jika beberapa rentang konten yang diminta oleh klien ada dalam cache, Cloud CDN akan menayangkan apa pun yang dapat dilayani dari cache dan mengirim permintaan rentang byte hanya untuk rentang yang tidak ada ke server origin Anda.

Setiap permintaan rentang byte yang dimulai oleh Cloud CDN menentukan rentang yang dimulai pada offset yang merupakan kelipatan 2.097.136 byte. Dengan kemungkinan pengecualian rentang akhir, setiap rentang juga berukuran 2.097.136 byte. Jika konten bukan kelipatan ukuran tersebut, rentang akhirnya akan lebih kecil. Ukuran dan offset yang digunakan dalam permintaan rentang byte dapat berubah di masa mendatang.

Sebagai contoh, pertimbangkan permintaan klien untuk byte 1.000.000 hingga 3.999.999 konten yang tidak ada dalam cache. Dalam contoh ini, Cloud CDN dapat memulai dua permintaan GET, satu untuk 2.097.136 byte konten pertama dan satu lagi untuk 2.097.136 byte kedua. Hal ini menghasilkan pengisian cache sebesar 4.194.272 byte meskipun klien hanya meminta 3.000.000 byte.

Jika Anda menggunakan bucket Cloud Storage sebagai origin, setiap permintaan GET akan ditagih sebagai operasi Class B terpisah. Anda dikenai biaya untuk semua permintaan GET yang diproses oleh Cloud Storage, termasuk permintaan apa pun yang dimulai oleh Cloud CDN. Jika respons ditayangkan sepenuhnya dari cache Cloud CDN, tidak ada permintaan GET yang dikirim ke Cloud Storage, dan Anda tidak akan dikenai biaya untuk operasi Cloud Storage apa pun.

Saat memulai permintaan validasi atau permintaan rentang byte, Cloud CDN tidak menyertakan header khusus klien seperti Cookie atau User-Agent.

Di kolom httpRequest.userAgent Cloud Logging, Cloud-CDN-Google berarti Cloud CDN memulai permintaan.

Melewati cache

Pengabaian cache memungkinkan permintaan yang berisi header permintaan tertentu mengabaikan cache, meskipun konten sebelumnya di-cache.

Bagian ini memberikan informasi tentang cara mengabaikan cache dengan header HTTP, seperti Pragma dan Authorization. Fitur ini berguna saat Anda ingin memastikan bahwa pengguna atau pelanggan selalu memiliki konten terbaru yang diambil langsung dari server asal. Anda mungkin ingin melakukannya untuk pengujian, menyiapkan direktori staging, atau skrip.

Jika header yang ditentukan cocok, cache akan dilewati untuk semua setelan mode cache, bahkan FORCE_CACHE_ALL. Pengabaian cache menyebabkan sejumlah besar cache tidak ditemukan jika header yang ditentukan umum untuk banyak permintaan.

Sebelum memulai

  • Pastikan Cloud CDN diaktifkan; untuk petunjuknya, lihat Menggunakan Cloud CDN.

  • Jika perlu, update ke Google Cloud CLI versi terbaru:

    gcloud components update

Mengonfigurasi bypass cache

Anda dapat menentukan hingga lima nama header HTTP. Nilai tidak peka huruf besar/kecil. Nama header harus berupa token kolom header HTTP yang valid. Nama header tidak boleh muncul lebih dari sekali dalam daftar header yang ditambahkan. Untuk mengetahui aturan tentang nama header yang valid, lihat Cara kerja header kustom.

Konsol

  1. Di konsol Google Cloud, buka halaman Load Balancing.

    Buka halaman Load balancing

  2. Klik nama Load Balancer Aplikasi eksternal Anda.
  3. Klik Edit .
  4. Di Backend configuration, pilih backend, lalu klik Edit .
  5. Pastikan Enable Cloud CDN dipilih.
  6. Di bagian bawah jendela, klik Konfigurasi lanjutan.
  7. Di bagian Abaikan cache di header permintaan, klik Tambahkan header.
  8. Ketik nama header, seperti Pragma atau Authorization.
  9. Klik Perbarui.
  10. Klik Update lagi.

gcloud

Untuk bucket backend, gunakan perintah gcloud compute backend-buckets create atau gcloud compute backend-buckets update dengan flag --bypass-cache-on-request-headers.

Untuk layanan backend, gunakan perintah gcloud compute backend-services create atau gcloud compute backend-services update dengan flag --bypass-cache-on-request-headers.

gcloud compute backend-buckets (create | update) BACKEND_BUCKET_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER

gcloud compute backend-services (create | update) BACKEND_SERVICE_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER

Contoh:

gcloud compute backend-services update my-backend-service
    --bypass-cache-on-request-headers=Pragma
    --bypass-cache-on-request-headers=Authorization

api

Untuk bucket backend, gunakan panggilan API Method: backendBuckets.insert, Method: backendBuckets.update, atau Method: backendBuckets.patch.

Untuk layanan backend, gunakan panggilan API Method: backendServices.insert, Method: backendServices.update, atau Method: backendServices.patch.

Contoh:

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets

Tambahkan cuplikan berikut ke isi permintaan JSON:

"cdnPolicy": {
  "bypassCacheOnRequestHeaders": [
    {
      "headerName": string
    }
  ]
}

Menonaktifkan pengabaian cache

gcloud

Untuk bucket backend, gunakan perintah gcloud compute backend-buckets create atau gcloud compute backend-buckets update dengan flag --no-bypass-cache-on-request-headers.

Untuk layanan backend, gunakan perintah gcloud compute backend-services create atau gcloud compute backend-services update dengan flag --no-bypass-cache-on-request-headers.

gcloud compute backend-services (create | update) (BACKEND_SERVICE_NAME | BACKEND_BUCKET_NAME)
    --no-bypass-cache-on-request-headers

api

Untuk bucket backend, gunakan panggilan API Method: backendBuckets.insert atau Method: backendBuckets.update.

Untuk layanan backend, gunakan panggilan API Method: backendServices.insert atau Method: backendServices.update.

Gunakan salah satu panggilan API berikut:

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE

Tambahkan cuplikan berikut ke isi permintaan JSON:

"cdnPolicy": {
  "fields": "bypassCacheOnRequestHeaders"
}

Langkah selanjutnya