Perilaku permintaan dan respons untuk asal kustom - Amazon CloudFront
Cara CloudFront memproses dan meneruskan permintaan ke asal kustom AndaBagaimana CloudFront memproses tanggapan dari asal kustom Anda

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Perilaku permintaan dan respons untuk asal kustom

Untuk memahami cara CloudFront memproses permintaan dan tanggapan saat Anda menggunakan asal kustom, lihat bagian berikut:

Cara CloudFront memproses dan meneruskan permintaan ke asal kustom Anda

Pelajari cara CloudFront memproses permintaan penampil dan meneruskan permintaan ke asal kustom Anda.

Autentikasi

Jika Anda meneruskan Authorization header ke asal Anda, Anda kemudian dapat mengonfigurasi server asal Anda untuk meminta otentikasi klien untuk jenis permintaan berikut:

  • DELETE

  • GET

  • HEAD

  • PATCH

  • PUT

  • POST

Untuk OPTIONS permintaan, otentikasi klien hanya dapat dikonfigurasi jika Anda menggunakan CloudFront pengaturan berikut:

  • CloudFront dikonfigurasi untuk meneruskan Authorization header ke asal Anda

  • CloudFront dikonfigurasi untuk tidak menyimpan respons terhadap OPTIONS permintaan

Untuk informasi selengkapnya, lihat CloudFront Konfigurasikan untuk meneruskan Authorization header.

Anda dapat menggunakan HTTP atau HTTPS meneruskan permintaan ke server asal Anda. Untuk informasi selengkapnya, lihat Gunakan HTTPS dengan CloudFront.

Durasi cache dan minimum TTL

Untuk mengontrol berapa lama objek Anda berada dalam CloudFront cache sebelum CloudFront meneruskan permintaan lain ke asal Anda, Anda dapat:

  • Konfigurasi asal Anda untuk menambahkan Cache-Control atau Expires pada setiap objek.

  • Tentukan nilai untuk Minimum TTL dalam perilaku CloudFront cache.

  • Gunakan nilai default selama 24 jam.

Untuk informasi selengkapnya, lihat Kelola berapa lama konten tetap dalam cache (kedaluwarsa).

Alamat IP Klien

Jika penampil mengirim permintaan ke CloudFront dan tidak menyertakan header X-Forwarded-For permintaan, CloudFront mendapatkan alamat IP penampil dari TCP koneksi, menambahkan X-Forwarded-For header yang menyertakan alamat IP, dan meneruskan permintaan ke asal. Misalnya, jika CloudFront mendapat alamat IP 192.0.2.2 dari TCP koneksi, itu meneruskan header berikut ke asal:

X-Forwarded-For: 192.0.2.2

Jika penampil mengirim permintaan ke CloudFront dan menyertakan header X-Forwarded-For permintaan, CloudFront mendapatkan alamat IP penampil dari TCP koneksi, menambahkannya ke akhir X-Forwarded-For header, dan meneruskan permintaan ke asal. Misalnya, jika permintaan penampil menyertakan X-Forwarded-For: 192.0.2.4,192.0.2.3 dan CloudFront mendapatkan alamat IP 192.0.2.2 dari TCP koneksi, itu meneruskan header berikut ke asal:

X-Forwarded-For: 192.0.2.4,192.0.2.3,192.0.2.2

Beberapa aplikasi, seperti load balancer (termasuk Elastic Load Balancing), firewall aplikasi web, reverse proxy, sistem pencegahan intrusi, API dan Gateway, menambahkan alamat IP server edge yang meneruskan permintaan CloudFront ke ujung header. X-Forwarded-For Misalnya, jika CloudFront termasuk X-Forwarded-For: 192.0.2.2 dalam permintaan yang diteruskan ke ELB dan jika alamat IP server CloudFront tepi adalah 192.0.2.199, permintaan yang diterima EC2 instance Anda berisi header berikut:

X-Forwarded-For: 192.0.2.2,192.0.2.199

catatan

X-Forwarded-ForHeader berisi IPv4 alamat (seperti 192.0.2.44) dan IPv6 alamat (seperti 2001:0 db 8:85 a3: :8a2e: 0370:7334).

Perhatikan juga bahwa X-Forwarded-For header dapat dimodifikasi oleh setiap node di jalur ke server saat ini (CloudFront). Untuk informasi lebih lanjut, lihat bagian 8.1 di RFC7239. Anda juga dapat memodifikasi header menggunakan fungsi komputasi CloudFront tepi.

Otentikasi sisi klien SSL

CloudFront tidak mendukung otentikasi klien dengan sertifikat sisi klienSSL. Jika asal meminta sertifikat sisi klien, hapus CloudFront permintaan.

Kompresi

Untuk informasi selengkapnya, lihat Sajikan file terkompresi.

Permintaan bersyarat

Ketika CloudFront menerima permintaan untuk objek yang telah kedaluwarsa dari cache tepi, itu meneruskan permintaan ke asal baik untuk mendapatkan versi terbaru dari objek atau untuk mendapatkan konfirmasi dari asal bahwa cache CloudFront tepi sudah memiliki versi terbaru. Biasanya, ketika asal terakhir mengirim objek ke CloudFront, itu termasuk ETag nilai, LastModified nilai, atau kedua nilai dalam respons. Dalam permintaan baru yang CloudFront diteruskan ke asal, CloudFront tambahkan satu atau kedua hal berikut:

  • Header If-Match atau If-None-Match yang memuat ETag untuk versi objek yang kedaluwarsa.

  • Header If-Modified-Since yang memuat LastModified untuk versi objek yang kedaluwarsa.

Asal menggunakan informasi ini untuk menentukan apakah objek telah diperbarui dan, oleh karena itu, apakah akan mengembalikan seluruh objek ke CloudFront atau hanya mengembalikan kode status HTTP 304 (tidak dimodifikasi).

catatan

If-Modified-Sincedan permintaan If-None-Match bersyarat tidak didukung ketika CloudFront dikonfigurasi untuk meneruskan cookie (semua atau subset).

Untuk informasi selengkapnya, lihat Konten cache berdasarkan cookie.

Cookie

Anda dapat mengonfigurasi CloudFront untuk meneruskan cookie ke asal Anda. Untuk informasi selengkapnya, lihat Konten cache berdasarkan cookie.

Berbagi sumber daya lintas asal () CORS

Jika Anda CloudFront ingin menghormati setelan berbagi sumber daya lintas asal, konfigurasikan CloudFront untuk meneruskan Origin header ke asal Anda. Untuk informasi selengkapnya, lihat Konten cache berdasarkan header permintaan.

Enkripsi

Anda dapat meminta pemirsa HTTPS untuk mengirim permintaan ke CloudFront dan meminta CloudFront untuk meneruskan permintaan ke asal kustom Anda dengan menggunakan protokol yang digunakan oleh penampil. Untuk informasi lebih lanjut, lihat pengaturan distribusi berikut:

CloudFront meneruskan HTTPS permintaan ke server asal menggunakan protokolSSLv3, TLSv1 .0, TLSv1 .1, dan TLSv1 .2. Untuk asal kustom, Anda dapat memilih SSL protokol yang CloudFront ingin Anda gunakan saat berkomunikasi dengan asal Anda:

  • Jika Anda menggunakan CloudFront konsol, pilih protokol menggunakan kotak centang Origin SSL Protocols. Untuk informasi selengkapnya, lihat Buat distribusi.

  • Jika Anda menggunakan CloudFront API, tentukan protokol dengan menggunakan elemen. OriginSslProtocols Untuk informasi selengkapnya, lihat OriginSslProtocolsdan DistributionConfigdi CloudFront APIReferensi Amazon.

Jika asalnya adalah ember Amazon S3, CloudFront selalu gunakan TLSv1 .2.

penting

Versi lain dari SSL dan TLS tidak didukung.

Untuk informasi selengkapnya tentang menggunakan HTTPS with CloudFront, lihatGunakan HTTPS dengan CloudFront. Untuk daftar sandi yang CloudFront mendukung HTTPS komunikasi antara pemirsa dan CloudFront, dan antara CloudFront dan asal Anda, lihat. Protokol dan cipher yang didukung antara pemirsa dan CloudFront

GETpermintaan yang menyertakan badan

Jika GET permintaan penampil menyertakan isi, CloudFront mengembalikan kode HTTP status 403 (Terlarang) ke penampil.

HTTPmetode

Jika Anda mengonfigurasi CloudFront untuk memproses semua HTTP metode yang didukungnya, CloudFront terima permintaan berikut dari pemirsa dan teruskan ke asal kustom Anda:

  • DELETE

  • GET

  • HEAD

  • OPTIONS

  • PATCH

  • POST

  • PUT

CloudFront selalu menyimpan respons GET dan HEAD permintaan. Anda juga dapat CloudFront mengonfigurasi respons cache terhadap OPTIONS permintaan. CloudFront tidak menyimpan respons terhadap permintaan yang menggunakan metode lain.

Untuk informasi tentang konfigurasi apakah asal kustom Anda memproses metode ini, lihat dokumentasi untuk asal Anda.

penting

Jika Anda mengonfigurasi CloudFront untuk menerima dan meneruskan ke asal Anda semua HTTP metode yang CloudFront mendukung, konfigurasikan server asal Anda untuk menangani semua metode. Misalnya, jika Anda mengonfigurasi CloudFront untuk menerima dan meneruskan metode ini karena ingin digunakanPOST, Anda harus mengonfigurasi server asal Anda untuk menangani DELETE permintaan dengan tepat sehingga pemirsa tidak dapat menghapus sumber daya yang tidak Anda inginkan. Untuk informasi selengkapnya, lihat dokumentasi untuk HTTP server Anda.

HTTPmeminta header dan CloudFront perilaku (kustom dan asal Amazon S3)

Tabel berikut mencantumkan header HTTP permintaan yang dapat Anda teruskan ke asal kustom dan Amazon S3 (dengan pengecualian yang dicatat). Untuk setiap header, tabel mencakup informasi tentang hal berikut:

  • CloudFront perilaku jika Anda tidak mengonfigurasi CloudFront untuk meneruskan header ke asal Anda, yang CloudFront menyebabkan cache objek Anda berdasarkan nilai header.

  • Apakah Anda dapat CloudFront mengonfigurasi objek cache berdasarkan nilai header untuk header itu.

    Anda dapat CloudFront mengonfigurasi objek cache berdasarkan nilai di User-Agent header Date dan, tetapi kami tidak merekomendasikannya. Header ini memiliki banyak nilai yang mungkin, dan caching berdasarkan nilainya akan menyebabkan CloudFront untuk meneruskan lebih banyak permintaan secara signifikan ke asal Anda.

Untuk informasi lebih lanjut tentang caching berdasarkan nilai header, lihat Konten cache berdasarkan header permintaan.

Header Perilaku jika Anda tidak mengonfigurasi CloudFront ke cache berdasarkan nilai header Caching berdasarkan nilai header didukung

Header yang ditetapkan lainnya

Pengaturan cache lama — CloudFront meneruskan header ke asal Anda.

Ya

Accept

CloudFront menghapus header.

Ya

Accept-Charset

CloudFront menghapus header.

Ya

Accept-Encoding

Jika nilainya berisi gzip ataubr, CloudFront teruskan Accept-Encoding header yang dinormalisasi ke asal Anda.

Untuk informasi selengkapnya, silakan lihat Dukungan kompresi dan Sajikan file terkompresi.

Ya

Accept-Language

CloudFront menghapus header.

Ya

Authorization

  • GETdan HEAD permintaan - CloudFront menghapus bidang Authorization header sebelum meneruskan permintaan ke asal Anda.

  • OPTIONSpermintaan — CloudFront menghapus bidang Authorization header sebelum meneruskan permintaan ke asal Anda jika Anda mengonfigurasi respons cache CloudFront terhadap permintaan. OPTIONS

    CloudFront meneruskan bidang Authorization header ke asal Anda jika Anda tidak mengonfigurasi respons cache CloudFront terhadap OPTIONS permintaan.

  • DELETE,PATCH,POST, dan PUT permintaan — CloudFront tidak menghapus bidang header sebelum meneruskan permintaan ke asal Anda.

Ya

Cache-Control

CloudFront meneruskan header ke asal Anda.

Tidak

CloudFront-Forwarded-Proto

CloudFront tidak menambahkan header sebelum meneruskan permintaan ke asal Anda.

Untuk informasi selengkapnya, lihat Konfigurasikan caching berdasarkan protokol permintaan.

Ya

CloudFront-Is-Desktop-Viewer

CloudFront tidak menambahkan header sebelum meneruskan permintaan ke asal Anda.

Untuk informasi selengkapnya, lihat Konfigurasikan caching berdasarkan jenis perangkat.

Ya

CloudFront-Is-Mobile-Viewer

CloudFront tidak menambahkan header sebelum meneruskan permintaan ke asal Anda.

Untuk informasi selengkapnya, lihat Konfigurasikan caching berdasarkan jenis perangkat.

Ya

CloudFront-Is-Tablet-Viewer

CloudFront tidak menambahkan header sebelum meneruskan permintaan ke asal Anda.

Untuk informasi selengkapnya, lihat Konfigurasikan caching berdasarkan jenis perangkat.

Ya

CloudFront-Viewer-Country

CloudFront tidak menambahkan header sebelum meneruskan permintaan ke asal Anda.

Ya

Connection

CloudFront menggantikan header ini dengan Connection: Keep-Alive sebelum meneruskan permintaan ke asal Anda.

Tidak

Content-Length

CloudFront meneruskan header ke asal Anda.

Tidak

Content-MD5

CloudFront meneruskan header ke asal Anda.

Ya

Content-Type

CloudFront meneruskan header ke asal Anda.

Ya

Cookie

Jika Anda mengonfigurasi CloudFront untuk meneruskan cookie, itu akan meneruskan bidang Cookie header ke asal Anda. Jika tidak, CloudFront hapus bidang Cookie header. Untuk informasi selengkapnya, lihat Konten cache berdasarkan cookie.

Tidak

Date

CloudFront meneruskan header ke asal Anda.

Ya, tetapi tidak disarankan

Expect

CloudFront menghapus header.

Ya

From

CloudFront meneruskan header ke asal Anda.

Ya

Host

CloudFront menetapkan nilai ke nama domain asal yang terkait dengan objek yang diminta.

Anda tidak dapat melakukan cache berdasarkan header Host untuk Amazon S3 atau MediaStore asal.

Ya (sesuai aturan)

Tidak (S3 dan MediaStore)

If-Match

CloudFront meneruskan header ke asal Anda.

Ya

If-Modified-Since

CloudFront meneruskan header ke asal Anda.

Ya

If-None-Match

CloudFront meneruskan header ke asal Anda.

Ya

If-Range

CloudFront meneruskan header ke asal Anda.

Ya

If-Unmodified-Since

CloudFront meneruskan header ke asal Anda.

Ya

Max-Forwards

CloudFront meneruskan header ke asal Anda.

Tidak

Origin

CloudFront meneruskan header ke asal Anda.

Ya

Pragma

CloudFront meneruskan header ke asal Anda.

Tidak

Proxy-Authenticate

CloudFront menghapus header.

Tidak

Proxy-Authorization

CloudFront menghapus header.

Tidak

Proxy-Connection

CloudFront menghapus header.

Tidak

Range

CloudFront meneruskan header ke asal Anda. Untuk informasi selengkapnya, lihat Bagaimana CloudFront memproses permintaan sebagian untuk suatu objek (rentangGETs).

Ya, secara default

Referer

CloudFront menghapus header.

Ya

Request-Range

CloudFront meneruskan header ke asal Anda.

Tidak

TE

CloudFront menghapus header.

Tidak

Trailer

CloudFront menghapus header.

Tidak

Transfer-Encoding

CloudFront meneruskan header ke asal Anda.

Tidak

Upgrade

CloudFront menghapus header, kecuali Anda telah membuat WebSocket koneksi.

Tidak (kecuali untuk WebSocket koneksi)

User-Agent

CloudFront menggantikan nilai bidang header ini denganAmazon CloudFront. Jika Anda CloudFront ingin menyimpan konten Anda berdasarkan perangkat yang digunakan pengguna, lihatKonfigurasikan caching berdasarkan jenis perangkat.

Ya, tetapi tidak disarankan

Via

CloudFront meneruskan header ke asal Anda.

Ya

Warning

CloudFront meneruskan header ke asal Anda.

Ya

X-Amz-Cf-Id

CloudFront menambahkan header ke permintaan penampil sebelum meneruskan permintaan ke asal Anda. Nilai header berisi string terenkripsi yang secara unik mengidentifikasi permintaan.

Tidak

X-Edge-*

CloudFront menghapus semua X-Edge-* header.

Tidak

X-Forwarded-For

CloudFront meneruskan header ke asal Anda. Untuk informasi selengkapnya, lihat Alamat IP Klien.

Ya

X-Forwarded-Proto

CloudFront menghapus header.

Tidak

X-HTTP-Method-Override

CloudFront menghapus header.

Ya

X-Real-IP

CloudFront menghapus header.

Tidak

HTTPversi

CloudFront meneruskan permintaan ke asal kustom Anda menggunakan /1.1. HTTP

Panjang maksimum permintaan dan panjang maksimum URL

Lama maksimum permintaan, termasuk alur, string query (jika ada), dan header, adalah 20.480 byte.

CloudFront membangun a URL dari permintaan. Panjang maksimum ini URL adalah 8192 byte.

Jika permintaan atau URL melebihi maksimum ini, CloudFront mengembalikan kode HTTP status 413, Permintaan Entitas Terlalu Besar, ke penampil, dan kemudian menghentikan TCP koneksi ke penampil.

OCSPmenjepit

Ketika penampil mengirimkan HTTPS permintaan untuk objek, salah satu CloudFront atau penampil harus mengonfirmasi dengan otoritas sertifikat (CA) bahwa SSL sertifikat untuk domain belum dicabut. OCSPstapling mempercepat validasi sertifikat dengan memungkinkan CloudFront untuk memvalidasi sertifikat dan menyimpan respons dari CA, sehingga klien tidak perlu memvalidasi sertifikat secara langsung dengan CA.

Peningkatan kinerja OCSP stapling lebih terasa ketika CloudFront menerima banyak HTTPS permintaan untuk objek dalam domain yang sama. Setiap server di lokasi CloudFront tepi harus mengirimkan permintaan validasi terpisah. Ketika CloudFront menerima banyak HTTPS permintaan untuk domain yang sama, setiap server di lokasi edge segera memiliki respons dari CA yang dapat “menjepit” ke paket dalam SSL jabat tangan; ketika pemirsa puas bahwa sertifikat valid, CloudFront dapat melayani objek yang diminta. Jika distribusi Anda tidak mendapatkan banyak lalu lintas di lokasi CloudFront tepi, permintaan baru lebih mungkin diarahkan ke server yang belum memvalidasi sertifikat dengan CA. Dalam hal ini, penampil secara terpisah melakukan langkah validasi dan CloudFront server melayani objek. CloudFront Server itu juga mengirimkan permintaan validasi ke CA, jadi lain kali menerima permintaan yang menyertakan nama domain yang sama, ia memiliki respons validasi dari CA.

Koneksi persisten

Ketika CloudFront mendapat respons dari asal Anda, ia mencoba mempertahankan koneksi selama beberapa detik jika permintaan lain tiba selama periode itu. Mempertahankan koneksi persisten menghemat waktu yang diperlukan untuk membangun kembali TCP koneksi dan melakukan TLS jabat tangan lain untuk permintaan berikutnya.

Untuk informasi lebih lanjut, termasuk cara mengonfigurasi durasi koneksi persisten, lihat Keep-alive timeout (hanya asal kustom) di bagian Referensi pengaturan distribusi.

Protokol

CloudFront meneruskan HTTP atau HTTPS meminta ke server asal berdasarkan hal berikut:

  • Protokol permintaan yang dikirimkan oleh pemirsa CloudFront, salah satu HTTP atauHTTPS.

  • Nilai bidang Kebijakan Protokol Asal di CloudFront konsol atau, jika Anda menggunakan CloudFront API, OriginProtocolPolicy elemen dalam tipe DistributionConfig kompleks. Di CloudFront konsol, opsinya adalah HTTPOnly, HTTPSOnly, dan Match Viewer.

Jika Anda menentukan HTTPHanya atau HTTPSHanya, CloudFront teruskan permintaan ke server asal menggunakan protokol yang ditentukan, terlepas dari protokol dalam permintaan penampil.

Jika Anda menentukan Penampil Pencocokan, CloudFront teruskan permintaan ke server asal menggunakan protokol dalam permintaan penampil. Perhatikan bahwa CloudFront cache objek hanya sekali meskipun pemirsa membuat permintaan menggunakan keduanya HTTP dan HTTPS protokol.

penting

Jika CloudFront meneruskan permintaan ke asal menggunakan HTTPS protokol, dan jika server asal mengembalikan sertifikat yang tidak valid atau sertifikat yang ditandatangani sendiri, CloudFront lepaskan koneksi. TCP

Untuk informasi tentang cara memperbarui distribusi menggunakan CloudFront konsol, lihatPerbarui distribusi. Untuk informasi tentang cara memperbarui distribusi menggunakan CloudFront API, buka UpdateDistributiondi CloudFront APIReferensi Amazon.

String pertanyaan

Anda dapat mengonfigurasi apakah CloudFront meneruskan parameter string kueri ke asal Anda. Untuk informasi selengkapnya, lihat Konten cache berdasarkan parameter string kueri.

Waktu habis dan upaya koneksi tempat asal

Batas waktu koneksi asal adalah jumlah detik yang CloudFront menunggu ketika mencoba membuat koneksi ke asal.

Upaya koneksi asal adalah berapa kali CloudFront upaya untuk terhubung ke asal.

Bersama-sama, pengaturan ini menentukan berapa lama CloudFront mencoba untuk terhubung ke asal sebelum gagal ke asal sekunder (dalam kasus grup asal) atau mengembalikan respons kesalahan ke penampil. Secara default, CloudFront tunggu selama 30 detik (3 upaya masing-masing 10 detik) sebelum mencoba terhubung ke asal sekunder atau mengembalikan respons kesalahan. Anda dapat mengurangi waktu ini dengan menentukan waktu koneksi yang lebih singkat, lebih sedikit percobaan, atau keduanya.

Untuk informasi selengkapnya, lihat Kontrol batas waktu dan upaya asal.

Waktu habis untuk respons asal

waktu habis respons asal, juga dikenal sebagai waktu habis baca asal atau waktu habis permintaan asal, berlaku untuk kedua hal berikut:

  • Jumlah waktu, dalam hitungan detik, yang CloudFront menunggu respons setelah meneruskan permintaan ke asal.

  • Jumlah waktu, dalam hitungan detik, yang CloudFront menunggu setelah menerima paket respons dari asal dan sebelum menerima paket berikutnya.

CloudFront perilaku tergantung pada HTTP metode permintaan pemirsa:

  • GETdan HEAD permintaan - Jika asal tidak merespons atau berhenti merespons dalam durasi waktu tunggu respons, hentikan CloudFront koneksi. Jika jumlah upaya koneksi asal yang ditentukan lebih dari 1, CloudFront coba lagi untuk mendapatkan respons lengkap. CloudFront mencoba hingga 3 kali, sebagaimana ditentukan oleh nilai pengaturan upaya koneksi asal. Jika asal tidak merespons selama upaya terakhir, CloudFront jangan coba lagi sampai menerima permintaan lain untuk konten pada asal yang sama.

  • DELETE,OPTIONS, PATCHPUT,, dan POST permintaan — Jika asal tidak merespons dalam 30 detik CloudFront , lepaskan koneksi dan tidak mencoba lagi untuk menghubungi asal. Klien dapat mengirim ulang permintaan bilamana perlu.

Untuk informasi lebih lanjut, termasuk cara mengonfigurasi waktu habis respons asal, lihat Batas waktu respons (hanya asal khusus).

Permintaan simultan untuk objek yang sama (permintaan runtuh)

Ketika lokasi CloudFront tepi menerima permintaan untuk objek dan objek tidak dalam cache atau objek yang di-cache kedaluwarsa, CloudFront segera kirim permintaan ke asal. Namun, jika ada permintaan simultan untuk objek yang sama—yaitu, jika permintaan tambahan untuk objek yang sama (dengan kunci cache yang sama) tiba di lokasi tepi sebelum CloudFront menerima respons terhadap permintaan pertama— CloudFront berhenti sebelum meneruskan permintaan tambahan ke asal. Jeda singkat ini membantu mengurangi beban pada titik asal. CloudFront mengirimkan respons dari permintaan asli ke semua permintaan yang diterimanya saat dijeda. Ini disebut permintaan runtuh. Dalam CloudFront log, permintaan pertama diidentifikasi sebagai Miss di x-edge-result-type bidang, dan permintaan yang diciutkan diidentifikasi sebagai aHit. Untuk informasi selengkapnya tentang CloudFront log, lihatCloudFront dan logging fungsi tepi.

CloudFront hanya menciutkan permintaan yang berbagi kunci cache. Jika permintaan tambahan tidak berbagi kunci cache yang sama karena, misalnya, Anda CloudFront mengonfigurasi cache berdasarkan header permintaan atau cookie atau string kueri, CloudFront teruskan semua permintaan dengan kunci cache unik ke asal Anda.

Jika Anda ingin mencegah semua permintaan runtuh, Anda dapat menggunakan kebijakan cache terkelolaCachingDisabled, yang juga mencegah caching. Untuk informasi selengkapnya, lihat Gunakan kebijakan cache terkelola.

Jika Anda ingin mencegah keruntuhan permintaan untuk objek tertentu, Anda dapat mengatur minimum TTL untuk perilaku cache ke 0 dan mengonfigurasi asal untuk mengirimCache-Control: private,,Cache-Control: no-store, Cache-Control: no-cacheCache-Control: max-age=0, atauCache-Control: s-maxage=0. Konfigurasi ini akan meningkatkan beban pada asal Anda dan memperkenalkan latensi tambahan untuk permintaan simultan yang dijeda sementara CloudFront menunggu respons terhadap permintaan pertama.

penting

Saat ini, CloudFront tidak mendukung keruntuhan permintaan jika Anda mengaktifkan penerusan cookie dalam kebijakan cache, kebijakan permintaan asal, atau pengaturan cache lama.

Header User-Agent

Jika Anda CloudFront ingin menyimpan versi objek yang berbeda berdasarkan perangkat yang digunakan pengguna untuk melihat konten Anda, kami sarankan Anda mengonfigurasi CloudFront untuk meneruskan satu atau beberapa header berikut ke asal kustom Anda:

  • CloudFront-Is-Desktop-Viewer

  • CloudFront-Is-Mobile-Viewer

  • CloudFront-Is-SmartTV-Viewer

  • CloudFront-Is-Tablet-Viewer

Berdasarkan nilai User-Agent header, CloudFront tetapkan nilai header ini ke true atau false sebelum meneruskan permintaan ke asal Anda. Jika perangkat termasuk dalam lebih dari satu kategori, lebih dari satu nilai mungkin true. Misalnya, untuk beberapa perangkat tablet, CloudFront mungkin mengatur keduanya CloudFront-Is-Mobile-Viewer dan CloudFront-Is-Tablet-Viewer ketrue. Untuk informasi selengkapnya tentang CloudFront mengonfigurasi cache berdasarkan header permintaan, lihat. Konten cache berdasarkan header permintaan

Anda dapat CloudFront mengonfigurasi objek cache berdasarkan nilai di User-Agent header, tetapi kami tidak merekomendasikannya. User-AgentHeader memiliki banyak nilai yang mungkin, dan caching berdasarkan nilai-nilai tersebut akan menyebabkan CloudFront untuk meneruskan lebih banyak permintaan secara signifikan ke asal Anda.

Jika Anda tidak CloudFront mengonfigurasi objek cache berdasarkan nilai di User-Agent header, CloudFront tambahkan User-Agent header dengan nilai berikut sebelum meneruskan permintaan ke asal Anda:

User-Agent = Amazon CloudFront

CloudFront menambahkan header ini terlepas dari apakah permintaan dari penampil menyertakan User-Agent header. Jika permintaan dari penampil menyertakan User-Agent header, CloudFront hapus itu.

Bagaimana CloudFront memproses tanggapan dari asal kustom Anda

Pelajari cara CloudFront memproses respons dari asal kustom Anda.

100 Continuetanggapan

Asal Anda tidak dapat mengirim lebih dari satu respons 100-Lanjutkan ke CloudFront. Setelah respons 100-Continue pertama, CloudFront mengharapkan respons HTTP 200 OK. Jika asal Anda mengirimkan respons 100-Lanjutkan lagi setelah yang pertama, CloudFront akan mengembalikan kesalahan.

Pembuatan cache

Permintaan dibatalkan

Jika suatu objek tidak berada di cache tepi, dan jika penampil mengakhiri sesi (misalnya, menutup browser) setelah CloudFront mendapatkan objek dari asal Anda tetapi sebelum dapat mengirimkan objek yang diminta, CloudFront tidak men-cache objek di lokasi tepi.

Negosiasi konten

Jika asal Anda kembali Vary:* dalam respons, dan jika nilai Minimum TTL untuk perilaku cache yang sesuai adalah 0, CloudFront cache objek tetapi masih meneruskan setiap permintaan berikutnya untuk objek ke asal untuk mengonfirmasi bahwa cache berisi versi terbaru dari objek. CloudFront tidak termasuk header bersyarat, seperti If-None-Match atau. If-Modified-Since Akibatnya, asal Anda mengembalikan objek sebagai CloudFront respons terhadap setiap permintaan.

Jika asal Anda kembali Vary:* dalam respons, dan jika nilai Minimum TTL untuk perilaku cache yang sesuai adalah nilai lainnya, CloudFront proses Vary header seperti yang dijelaskan dalamHTTPheader respon yang CloudFront menghapus atau menggantikan.

Cookie

Jika Anda mengaktifkan cookie untuk perilaku cache, dan jika asal mengembalikan cookie dengan objek, CloudFront cache objek dan cookie. Perhatikan bahwa ini mengurangi kemungkinan cache untuk sebuah objek. Untuk informasi selengkapnya, lihat Konten cache berdasarkan cookie.

TCPKoneksi terputus

Jika TCP koneksi antara CloudFront dan asal Anda turun saat asal Anda mengembalikan objek CloudFront, CloudFront perilaku tergantung pada apakah asal Anda menyertakan Content-Length header dalam respons:

  • Header Content-Length - CloudFront mengembalikan objek ke penampil karena mendapatkan objek dari asal Anda. Namun, jika nilai Content-Length header tidak sesuai dengan ukuran objek, objek CloudFront tidak disimpan dalam cache.

  • Transfer-Encoding: Chunked — CloudFront mengembalikan objek ke penampil karena mendapatkan objek dari asal Anda. Namun, jika respon chunked tidak lengkap, CloudFront tidak cache objek.

  • Tanpa header Content-Length — CloudFront mengembalikan objek ke penampil dan menyimpannya di cache, tetapi objek mungkin tidak lengkap. Tanpa Content-Length header, CloudFront tidak dapat menentukan apakah TCP koneksi terputus secara tidak sengaja atau sengaja.

Kami menyarankan Anda mengonfigurasi HTTP server Anda untuk menambahkan Content-Length header untuk CloudFront mencegah caching objek sebagian.

HTTPheader respon yang CloudFront menghapus atau menggantikan

CloudFront menghapus atau memperbarui bidang header berikut sebelum meneruskan respons dari asal Anda ke penampil:

  • Set-Cookie— Jika Anda mengonfigurasi CloudFront untuk meneruskan cookie, itu akan meneruskan bidang Set-Cookie header ke klien. Untuk informasi selengkapnya, lihat Konten cache berdasarkan cookie.

  • Trailer

  • Transfer-Encoding— Jika asal Anda mengembalikan bidang header ini, CloudFront tetapkan nilainya chunked sebelum mengembalikan respons ke penampil.

  • Upgrade

  • Vary – Catat hal berikut:

    • Jika Anda mengonfigurasi CloudFront untuk meneruskan header khusus perangkat ke origin (CloudFront-Is-Desktop-Viewer,,CloudFront-Is-Mobile-Viewer,CloudFront-Is-Tablet-Viewer) dan mengonfigurasi asal Anda untuk kembaliCloudFront-Is-SmartTV-Viewer, kembali Vary:User-Agent ke CloudFront penampil CloudFront. Vary:User-Agent Untuk informasi selengkapnya, lihat Konfigurasikan caching berdasarkan jenis perangkat.

    • Jika Anda mengonfigurasi asal Anda untuk menyertakan salah satu Accept-Encoding atau Cookie di Vary header, CloudFront sertakan nilai dalam respons terhadap penampil.

    • Jika Anda mengonfigurasi CloudFront untuk meneruskan header ke asal Anda, dan jika Anda mengonfigurasi asal Anda untuk mengembalikan nama header ke CloudFront Vary header (misalnya,Vary:Accept-Charset,Accept-Language), CloudFront mengembalikan Vary header dengan nilai-nilai tersebut ke penampil.

    • Untuk informasi tentang cara CloudFront memproses nilai * di Vary header, lihatNegosiasi konten.

    • Jika Anda mengonfigurasi asal Anda untuk menyertakan nilai lain di Vary header, CloudFront hapus nilai sebelum mengembalikan respons ke penampil.

  • Via— CloudFront menetapkan nilai sebagai berikut dalam respons terhadap penampil:

    Via: http-version alphanumeric-string.cloudfront.net (CloudFront)

    Misalnya, nilainya adalah seperti berikut:

    Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)

Ukuran file cache maksimum

Ukuran maksimum badan respons yang CloudFront menyimpan dalam cache-nya adalah 50 GB. Ini termasuk respons transfer yang dipotong yang tidak menyebutkan nilai header Content-Length.

Anda dapat CloudFront menggunakan cache objek yang lebih besar dari ukuran ini dengan menggunakan permintaan rentang untuk meminta objek di bagian yang masing-masing 50 GB atau lebih kecil. CloudFrontcache bagian-bagian ini karena masing-masing dari mereka adalah 50 GB atau lebih kecil. Setelah penampil mengambil semua bagian objek, ia dapat merekonstruksi objek asli yang lebih besar. Untuk informasi selengkapnya, lihat Gunakan permintaan rentang untuk menyimpan objek besar.

Tempat asal tidak tersedia

Jika server asal Anda tidak tersedia dan CloudFront mendapat permintaan untuk objek yang ada di cache tepi tetapi telah kedaluwarsa (misalnya, karena periode waktu yang ditentukan dalam Cache-Control max-age arahan telah berlalu), CloudFront baik menyajikan versi kedaluwarsa objek atau menyajikan halaman kesalahan khusus. Untuk informasi selengkapnya tentang CloudFront perilaku saat Anda mengonfigurasi halaman kesalahan kustom, lihatBagaimana CloudFront proses kesalahan ketika Anda telah mengkonfigurasi halaman kesalahan kustom.

Dalam beberapa kasus, objek yang jarang diminta diusir dan tidak lagi tersedia di cache tepi. CloudFront tidak dapat melayani objek yang telah diusir.

Mengalihkan

Jika Anda mengubah lokasi objek di server asal, Anda dapat mengonfigurasi server web Anda untuk mengalihkan permintaan ke lokasi baru. Setelah Anda mengonfigurasi pengalihan, pertama kali penampil mengirimkan permintaan untuk objek, CloudFront mengirim permintaan ke asal, dan asal merespons dengan pengalihan (misalnya,). 302 Moved Temporarily CloudFront cache pengalihan dan mengembalikannya ke penampil. CloudFront tidak mengikuti pengalihan.

Anda dapat mengonfigurasi server web untuk mengalihkan permintaan ke salah satu lokasi berikut:

  • URLObjek baru di server asal. Saat pemirsa mengikuti pengalihan ke yang baruURL, pemirsa mem-bypass CloudFront dan langsung menuju ke asal. Akibatnya, kami menyarankan Anda untuk tidak mengalihkan permintaan ke URL objek baru di asal.

  • Yang baru CloudFront URL untuk objek. Saat penampil mengirimkan permintaan yang berisi yang baru CloudFront URL, CloudFront dapatkan objek dari lokasi baru di asal Anda, menyimpannya di lokasi tepi, dan mengembalikan objek ke penampil. Permintaan berikutnya atas objek tersebut akan dilayani oleh lokasi edge. Ini menghindari latensi dan beban yang terkait dengan penampil yang meminta objek dari asal. Namun, setiap permintaan baru untuk objek akan dikenakan biaya untuk dua permintaan. CloudFront

Header Transfer-Encoding

CloudFront hanya mendukung chunked nilai Transfer-Encoding header. Jika asal Anda kembaliTransfer-Encoding: chunked, CloudFront mengembalikan objek ke klien sebagai objek diterima di lokasi tepi, dan cache objek dalam format chunked untuk permintaan berikutnya.

Jika penampil membuat Range GET permintaan dan asal kembaliTransfer-Encoding: chunked, CloudFront mengembalikan seluruh objek ke penampil, bukan rentang yang diminta.

Kami sarankan Anda menggunakan pengkodean bertahap jika panjang konten tanggapan Anda tidak dapat ditentukan sebelumnya. Untuk informasi selengkapnya, lihat TCPKoneksi terputus.