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:
**Topics**
+ [Cara CloudFront memproses dan meneruskan permintaan ke asal kustom Anda](#RequestBehaviorCustomOrigin)
+ [Bagaimana CloudFront memproses tanggapan dari asal kustom Anda](#ResponseBehaviorCustomOrigin)
## Cara CloudFront memproses dan meneruskan permintaan ke asal kustom Anda
Pelajari cara CloudFront memproses permintaan penampil dan meneruskan permintaan ke asal kustom Anda.
**Contents**
+ [Autentikasi](#RequestCustomClientAuth)
+ [Durasi caching dan TTL minimum](#RequestCustomCaching)
+ [Alamat IP Klien](#RequestCustomIPAddresses)
+ [Auntentikasi SSL sisi-klien](#RequestCustomClientSideSslAuth)
+ [Kompresi](#RequestCustomCompression)
+ [Permintaan bersyarat](#RequestCustomConditionalGETs)
+ [Cookie](#RequestCustomCookies)
+ [Berbagi sumber daya lintas asal (CORS)](#request-custom-cors)
+ [Enkripsi](#RequestCustomEncryption)
+ [Permintaan GET yang menyertakan tubuh](#RequestCustom-get-body)
+ [Metode HTTP](#RequestCustomHTTPMethods)
+ [Header dan CloudFront perilaku permintaan HTTP (asal kustom dan Amazon S3)](#request-custom-headers-behavior)
+ [Versi HTTP](#RequestCustomHTTPVersion)
+ [Lama maksimum panjang permintaan dan lama maksimum URL](#RequestCustomMaxRequestStringLength)
+ [Pemasangan OCSP](#request-custom-ocsp-stapling)
+ [Koneksi persisten](#request-custom-persistent-connections)
+ [Protokol](#RequestCustomProtocols)
+ [String pertanyaan](#RequestCustomQueryStrings)
+ [Waktu habis dan upaya koneksi tempat asal](#custom-origin-timeout-attempts)
+ [Waktu habis untuk respons asal](#request-custom-request-timeout)
+ [Permintaan simultan untuk objek yang sama (permintaan runtuh)](#request-custom-traffic-spikes)
+ [Header `User-Agent`](#request-custom-user-agent-header)
### 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](add-origin-custom-headers.md#add-origin-custom-headers-forward-authorization).
Anda dapat menggunakan HTTP atau HTTPS untuk meneruskan permintaan ke server asal Anda. Untuk informasi selengkapnya, lihat [Gunakan HTTPS dengan CloudFront](using-https.md).
### Durasi caching dan TTL minimum
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 TTL Minimum dalam perilaku CloudFront cache.
+ Gunakan nilai default selama 24 jam.
Untuk informasi selengkapnya, lihat [Mengelola berapa lama konten tetap dalam cache (kedaluwarsa)](Expiration.md).
### Alamat IP Klien
Jika penampil mengirim permintaan ke CloudFront dan tidak menyertakan header `X-Forwarded-For` permintaan, CloudFront mendapatkan alamat IP penampil dari koneksi TCP, menambahkan `X-Forwarded-For` header yang menyertakan alamat IP, dan meneruskan permintaan ke asal. Misalnya, jika CloudFront mendapatkan alamat IP `192.0.2.2` dari koneksi TCP, akan meneruskan header berikut ke asalnya:
`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 koneksi TCP, 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 koneksi TCP, 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, dan API Gateway, menambahkan CloudFront alamat IP server edge yang meneruskan permintaan 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 edge adalah 192.0.2.199, permintaan yang diterima instans EC2 Anda berisi header berikut:
`X-Forwarded-For: 192.0.2.2,192.0.2.199`
**catatan**
`X-Forwarded-For`Header 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 [RFC 7239](https://datatracker.ietf.org/doc/html/rfc7239). Anda juga dapat memodifikasi header menggunakan fungsi komputasi CloudFront tepi.
### Auntentikasi SSL sisi-klien
CloudFront mendukung otentikasi TLS (mTLS) timbal balik di mana klien dan server saling mengautentikasi menggunakan sertifikat. Dengan mTL yang dikonfigurasi, CloudFront dapat memvalidasi sertifikat klien selama jabat tangan TLS dan secara opsional menjalankan CloudFront Fungsi untuk mengimplementasikan logika validasi kustom.
Untuk asal yang meminta sertifikat sisi klien saat mTL tidak dikonfigurasi, hapus permintaanCloudFront .
Untuk informasi selengkapnya tentang mengonfigurasi mTL, lihat. [Kaitkan Fungsi CloudFront Koneksi](connection-functions.md)
CloudFront tidak mendukung otentikasi klien dengan sertifikat SSL sisi klien. Jika asal meminta sertifikat sisi klien, hapus CloudFront permintaan.
### Kompresi
Untuk informasi selengkapnya, lihat [Sajikan file terkompresi](ServingCompressedFiles.md).
### 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-Since`dan permintaan `If-None-Match` bersyarat tidak didukung ketika CloudFront dikonfigurasi untuk meneruskan cookie (semua atau subset).
Untuk informasi selengkapnya, lihat [Konten cache berdasarkan cookie](Cookies.md).
### Cookie
Anda dapat mengonfigurasi CloudFront untuk meneruskan cookie ke asal Anda. Untuk informasi selengkapnya, lihat [Konten cache berdasarkan cookie](Cookies.md).
### 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](header-caching.md).
### Enkripsi
Anda dapat meminta pemirsa untuk menggunakan HTTPS untuk mengirim permintaan CloudFront dan CloudFront harus meneruskan permintaan ke asal kustom Anda dengan menggunakan protokol yang digunakan oleh penampil. Untuk informasi lebih lanjut, lihat pengaturan distribusi berikut:
+ [Kebijakan protokol penampil](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy)
+ [Protokol (hanya asal kustom)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy)
CloudFront meneruskan permintaan HTTPS ke server asal menggunakan protokol SSLv3, TLSv1 .0, TLSv1 .1, TLSv1 .2, dan .3. TLSv1 Untuk asal kustom, Anda dapat memilih protokol SSL yang ingin Anda gunakan saat berkomunikasi CloudFront dengan asal Anda:
+ Jika Anda menggunakan CloudFront konsol, pilih protokol menggunakan kotak centang **Origin SSL Protocols**. Untuk informasi selengkapnya, lihat [Buat distribusi](distribution-web-creating-console.md).
+ Jika Anda menggunakan CloudFront API, tentukan protokol dengan menggunakan elemen. `OriginSslProtocols` Untuk informasi selengkapnya, lihat [OriginSslProtocols](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginSslProtocols.html)dan [DistributionConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DistributionConfig.html)di *Referensi Amazon CloudFront API*.
Jika asalnya adalah bucket Amazon S3, CloudFront akan default ke TLSv1 .3.
**penting**
Versi lain dari SSL dan TLS tidak didukung.
Untuk informasi selengkapnya tentang menggunakan HTTPS dengan CloudFront, lihat[Gunakan HTTPS dengan CloudFront](using-https.md). Untuk daftar sandi yang CloudFront mendukung komunikasi HTTPS antara pemirsa dan CloudFront, dan antara CloudFront dan asal Anda, lihat. [Protokol dan sandi yang didukung antara pemirsa dan CloudFront](secure-connections-supported-viewer-protocols-ciphers.md)
### Permintaan GET yang menyertakan tubuh
Jika `GET` permintaan penampil menyertakan isi, CloudFront mengembalikan kode status HTTP 403 (Terlarang) ke penampil.
### Metode HTTP
Jika Anda mengonfigurasi CloudFront untuk memproses semua metode HTTP 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 metode HTTP yang CloudFront mendukung, konfigurasikan server asal Anda untuk menangani semua metode. Misalnya, jika Anda mengonfigurasi CloudFront untuk menerima dan meneruskan metode ini karena ingin digunakan`POST`, 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 lebih lanjut, lihat dokumentasi untuk server HTTP Anda.
### Header dan CloudFront perilaku permintaan HTTP (asal kustom dan Amazon S3)
Tabel berikut mencantumkan header permintaan HTTP yang dapat Anda teruskan ke asal kustom dan juga 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-caching.md).
| 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` atau`br`, CloudFront teruskan `Accept-Encoding` header yang dinormalisasi ke asal Anda. Untuk informasi selengkapnya, lihat [Dukungan kompresi ](cache-key-understand-cache-policy.md#cache-policy-compressed-objects) dan [Sajikan file terkompresi](ServingCompressedFiles.md). | Ya |
| `Accept-Language` | CloudFront menghapus header. | Ya |
| `Authorization` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html) | 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](header-caching.md#header-caching-web-protocol). | Ya |
| `CloudFront-Is-Desktop-Viewer` | CloudFront tidak menambahkan header sebelum meneruskan permintaan ke asal Anda. Untuk informasi selengkapnya, lihat [Konfigurasikan caching berdasarkan jenis perangkat](header-caching.md#header-caching-web-device). | Ya |
| `CloudFront-Is-Mobile-Viewer` | CloudFront tidak menambahkan header sebelum meneruskan permintaan ke asal Anda. Untuk informasi selengkapnya, lihat [Konfigurasikan caching berdasarkan jenis perangkat](header-caching.md#header-caching-web-device). | Ya |
| `CloudFront-Is-Tablet-Viewer` | CloudFront tidak menambahkan header sebelum meneruskan permintaan ke asal Anda. Untuk informasi selengkapnya, lihat [Konfigurasikan caching berdasarkan jenis perangkat](header-caching.md#header-caching-web-device). | 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](Cookies.md). | 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 judul 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 (rentang GETs)](RangeGETs.md). | 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 dengan`Amazon CloudFront`. Jika Anda CloudFront ingin menyimpan konten Anda berdasarkan perangkat yang digunakan pengguna, lihat[Konfigurasikan caching berdasarkan jenis perangkat](header-caching.md#header-caching-web-device). | 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](#RequestCustomIPAddresses). | Ya |
| `X-Forwarded-Proto` | CloudFront menghapus header. | Tidak |
| `X-HTTP-Method-Override` | CloudFront menghapus header. | Ya |
| `X-Real-IP` | CloudFront menghapus header. | Tidak |
### Versi HTTP
CloudFront meneruskan permintaan ke asal kustom Anda menggunakan HTTP/1.1.
### Lama maksimum panjang permintaan dan lama maksimum URL
Panjang maksimum permintaan, termasuk jalur, string kueri (jika ada), dan header, adalah 32.768 byte.
CloudFront membangun URL dari permintaan. Panjang maksimal URL ini adalah 8192 byte.
Jika URL melebihi panjang maksimum, CloudFront mengembalikan kode status HTTP 414 (URI Terlalu Panjang) ke penampil. Jika permintaan melebihi panjang maksimum karena ukuran header terlampaui, CloudFront mengembalikan kode status HTTP 494 ke penampil. Dalam kedua kasus, CloudFront kemudian mengakhiri koneksi TCP ke penampil.
### Pemasangan OCSP
Saat penampil mengirimkan permintaan HTTPS untuk suatu objek, salah satu CloudFront atau penampil harus mengonfirmasi dengan otoritas sertifikat (CA) bahwa sertifikat SSL untuk domain tersebut belum dicabut. Stapling OCSP 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 performa stapling OCSP lebih jelas ketika CloudFront menerima banyak permintaan HTTPS untuk objek dalam domain yang sama. Setiap server di lokasi CloudFront tepi harus mengirimkan permintaan validasi terpisah. Saat CloudFront menerima banyak permintaan HTTPS untuk domain yang sama, setiap server di lokasi tepi segera memiliki respons dari CA yang dapat "menempatkan" ke paket dalam handshake SSL; ketika penampil 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 yang persisten menghemat waktu yang diperlukan untuk membangun kembali koneksi TCP dan melakukan handshake TLS lain untuk permintaan berikutnya.
Untuk informasi lebih lanjut, termasuk cara mengonfigurasi durasi koneksi persisten, lihat [Keep-alive timeout (khusus dan hanya asal VPC)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginKeepaliveTimeout) di bagian [Semua referensi pengaturan distribusi](distribution-web-values-specify.md).
### Protokol
CloudFront meneruskan permintaan HTTP atau HTTPS ke server asal berdasarkan hal berikut:
+ Protokol permintaan yang dikirimkan oleh penampil CloudFront, baik HTTP atau HTTPS.
+ 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 **HTTP Only, **HTTPS Only****, dan **Match Viewer**.
Jika Anda menentukan **HTTP Only** atau **HTTPS Only**, 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 menyimpan objek hanya sekali jika penampil membuat permintaan menggunakan protokol HTTP dan HTTPS.
**penting**
Jika CloudFront meneruskan permintaan ke asal menggunakan protokol HTTPS, dan jika server asal mengembalikan sertifikat yang tidak valid atau sertifikat yang ditandatangani sendiri, lepaskan koneksi TCP CloudFront .
Untuk informasi tentang cara memperbarui distribusi menggunakan CloudFront konsol, lihat[Perbarui distribusi](HowToUpdateDistribution.md). Untuk informasi tentang cara memperbarui distribusi menggunakan CloudFront API, buka *Referensi CloudFront API Amazon*. [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)
### String pertanyaan
Anda dapat mengonfigurasi apakah CloudFront meneruskan parameter string kueri ke asal Anda. Untuk informasi selengkapnya, lihat [Konten cache berdasarkan parameter string kueri](QueryStringParameters.md).
### 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](high_availability_origin_failover.md#controlling-attempts-and-timeouts).
### 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 metode HTTP dari permintaan penampil:
+ `GET`dan `HEAD` permintaan - Jika asal tidak merespons atau berhenti merespons dalam durasi waktu tunggu respons, hentikan CloudFront koneksi. Jika jumlah [upaya koneksi asal](DownloadDistValuesOrigin.md#origin-connection-attempts) 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 percobaan terakhir, CloudFront tidak mencoba lagi hingga menerima permintaan konten lain di tempat yang sama.
+ `DELETE`, `OPTIONS``PATCH`,`PUT`,, dan `POST` permintaan — Jika asal tidak merespons selama durasi batas waktu baca, CloudFront hentikan 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](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout).
### 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 *request collapsing*. Dalam CloudFront log, permintaan pertama diidentifikasi sebagai a `Miss` di `x-edge-result-type` bidang, dan permintaan yang diciutkan diidentifikasi sebagai a`Hit`. Untuk informasi selengkapnya tentang CloudFront log, lihat[CloudFront dan logging fungsi tepi](logging.md).
CloudFront hanya menciutkan permintaan yang berbagi [*kunci cache*](understanding-the-cache-key.md). 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 terkelola`CachingDisabled`, yang juga mencegah caching. Untuk informasi selengkapnya, lihat [Gunakan kebijakan cache terkelola](using-managed-cache-policies.md).
Jika Anda ingin mencegah keruntuhan permintaan untuk objek tertentu, Anda dapat mengatur TTL minimum untuk perilaku cache ke 0 *dan* mengonfigurasi asal untuk mengirim`Cache-Control: private`,,, `Cache-Control: no-store` `Cache-Control: no-cache``Cache-Control: max-age=0`, atau. `Cache-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](controlling-the-cache-key.md) [permintaan asal](controlling-origin-requests.md), 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` ke`true`. Untuk informasi selengkapnya tentang CloudFront mengonfigurasi cache berdasarkan header permintaan, lihat. [Konten cache berdasarkan header permintaan](header-caching.md)
Anda dapat CloudFront mengonfigurasi objek cache berdasarkan nilai di `User-Agent` header, tetapi kami tidak merekomendasikannya. `User-Agent`Header 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.
**Contents**
+ [`100 Continue`tanggapan](#Response100Continue)
+ [Pembuatan cache](#ResponseCustomCaching)
+ [Permintaan dibatalkan](#response-custom-canceled-requests)
+ [Negosiasi konten](#ResponseCustomContentNegotiation)
+ [Cookie](#ResponseCustomCookies)
+ [Koneksi TCP yang terhenti](#ResponseCustomDroppedTCPConnections)
+ [Header respons HTTP yang CloudFront menghapus atau menggantikan](#ResponseCustomRemovedHeaders)
+ [Ukuran file cache maksimum](#ResponseCustomMaxFileSize)
+ [Tempat asal tidak tersedia](#ResponseCustomOriginUnavailable)
+ [Mengalihkan](#ResponseCustomRedirects)
+ [Header `Transfer-Encoding`](#ResponseCustomTransferEncoding)
### `100 Continue`tanggapan
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
+ Pastikan server asal menetapkan nilai yang valid dan akurat untuk `Date` dan `Last-Modified` bidang header.
+ CloudFront biasanya menghormati `Cache-Control: no-cache` header dalam respons dari asal. Untuk pengecualian, lihat [Permintaan simultan untuk objek yang sama (permintaan runtuh)](#request-custom-traffic-spikes).
### 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 **TTL Minimum** 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 **TTL Minimum** untuk perilaku cache yang sesuai adalah nilai lainnya, CloudFront proses `Vary` header seperti yang dijelaskan dalam[Header respons HTTP yang CloudFront menghapus atau menggantikan](#ResponseCustomRemovedHeaders).
### 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](Cookies.md).
### Koneksi TCP yang terhenti
Jika koneksi TCP 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:
+ **Judul Panjang Konten** – CloudFront mengembalikan objek ke penampil saat objek berasal dari negara 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.
+ **Tidak ada header Panjang Konten** – CloudFront mengembalikan objek ke penampil dan menyimpannya dalam cache, tetapi objek mungkin tidak lengkap. Tanpa `Content-Length` header, CloudFront tidak dapat menentukan apakah koneksi TCP jatuh secara tidak sengaja atau dengan sengaja.
Kami menyarankan Anda mengonfigurasi server HTTP Anda untuk menambahkan `Content-Length` header untuk CloudFront mencegah caching objek sebagian.
### Header respons HTTP 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](Cookies.md).
+ `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 kembali`CloudFront-Is-SmartTV-Viewer`, kembali `Vary:User-Agent` ke CloudFront penampil CloudFront. `Vary:User-Agent` Untuk informasi selengkapnya, lihat [Konfigurasikan caching berdasarkan jenis perangkat](header-caching.md#header-caching-web-device).
+ 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, lihat[Negosiasi konten](#ResponseCustomContentNegotiation).
+ 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](RangeGETs.md#cache-large-objects-with-range-requests).
### 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, lihat[Bagaimana CloudFront proses kesalahan ketika Anda telah mengkonfigurasi halaman kesalahan kustom](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages).
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:
+ URL baru objek di server asal. Saat penampil mengikuti pengalihan ke URL baru, penampil mem-bypass CloudFront dan langsung menuju ke asal. Akibatnya, kami menyarankan agar Anda tidak mengalihkan permintaan ke URL baru objek pada asal.
+ CloudFront URL baru untuk objek. Saat penampil mengirimkan permintaan yang berisi CloudFront URL baru, 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 untuk CloudFront.
### Header `Transfer-Encoding`
CloudFront hanya mendukung `chunked` nilai `Transfer-Encoding` header. Jika asal Anda kembali`Transfer-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 kembali`Transfer-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 [Koneksi TCP yang terhenti](#ResponseCustomDroppedTCPConnections).