Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Perilaku permintaan dan respons
Topik berikut menjelaskan bagaimana CloudFront menangani permintaan dan tanggapan.
Anda dapat mempelajari cara CloudFront berinteraksi dengan Amazon S3 atau custom origin, menangani berbagai metode dan header HTTP, memproses kode status, dan mengelola caching dan respons kesalahan.
**Topics**
+ [Bagaimana CloudFront memproses permintaan HTTP dan HTTPS](HTTPandHTTPSRequests.md)
+ [Perilaku permintaan dan respons untuk asal Amazon S3](RequestAndResponseBehaviorS3Origin.md)
+ [Perilaku permintaan dan respons untuk asal kustom](RequestAndResponseBehaviorCustomOrigin.md)
+ [Perilaku permintaan dan respons untuk grup asal](RequestAndResponseBehaviorOriginGroups.md)
+ [Tambahkan header khusus ke permintaan asal](add-origin-custom-headers.md)
+ [Bagaimana CloudFront memproses permintaan sebagian untuk suatu objek (rentang GETs)](RangeGETs.md)
+ [Bagaimana CloudFront memproses kode status HTTP 3xx dari asal Anda](http-3xx-status-codes.md)
+ [Bagaimana CloudFront memproses kode status HTTP 4xx dan 5xx dari asal Anda](HTTPStatusCodes.md)
+ [Hasilkan respons kesalahan khusus](GeneratingCustomErrorResponses.md)
# Bagaimana CloudFront memproses permintaan HTTP dan HTTPS
Untuk asal Amazon S3, CloudFront menerima permintaan dalam protokol HTTP dan HTTPS untuk objek dalam distribusi secara default. CloudFront CloudFront kemudian meneruskan permintaan ke bucket Amazon S3 Anda menggunakan protokol yang sama di mana permintaan dibuat.
Untuk asal kustom, saat membuat distribusi, Anda dapat menentukan cara CloudFront mengakses origin Anda: hanya HTTP, atau mencocokkan protokol yang digunakan oleh penampil. Untuk informasi selengkapnya tentang cara CloudFront menangani permintaan HTTP dan HTTPS untuk asal kustom, lihat[Protokol](RequestAndResponseBehaviorCustomOrigin.md#RequestCustomProtocols).
Untuk informasi tentang cara membatasi distribusi Anda sehingga pengguna akhir hanya dapat mengakses objek menggunakan HTTPS, lihat [Gunakan HTTPS dengan CloudFront](using-https.md).
**catatan**
Biaya untuk permintaan HTTPS lebih tinggi daripada biaya untuk permintaan HTTP. Untuk informasi selengkapnya tentang tarif penagihan, lihat [CloudFront harga](https://aws.amazon.com/cloudfront/#pricing).
# Perilaku permintaan dan respons untuk asal Amazon S3
Untuk memahami cara CloudFront memproses permintaan dan tanggapan saat Anda menggunakan Amazon S3 sebagai asal, lihat bagian berikut:
**Topics**
+ [Cara CloudFront memproses dan meneruskan permintaan ke asal Amazon S3 Anda](#RequestBehaviorS3Origin)
+ [Bagaimana CloudFront memproses tanggapan dari asal Amazon S3 Anda](#ResponseBehaviorS3Origin)
## Cara CloudFront memproses dan meneruskan permintaan ke asal Amazon S3 Anda
Pelajari cara CloudFront memproses permintaan penampil dan meneruskan permintaan ke asal Amazon S3 Anda.
**Contents**
+ [Durasi caching dan TTL minimum](#RequestS3Caching)
+ [Alamat IP Klien](#RequestS3IPAddresses)
+ [Permintaan GET bersyarat](#RequestS3ConditionalGETs)
+ [Cookie](#RequestS3Cookies)
+ [Berbagi sumber daya lintas asal (CORS)](#RequestS3-cors)
+ [Permintaan GET yang menyertakan tubuh](#RequestS3-get-body)
+ [Metode HTTP](#RequestS3HTTPMethods)
+ [Header permintaan HTTP yang CloudFront menghapus atau memperbarui](#request-s3-removed-headers)
+ [Lama maksimum panjang permintaan dan lama maksimum URL](#RequestS3MaxRequestStringLength)
+ [Pemasangan OCSP](#request-s3-ocsp-stapling)
+ [Protokol](#RequestS3Protocol)
+ [String pertanyaan](#RequestS3QueryStrings)
+ [Waktu habis dan upaya koneksi tempat asal](#s3-origin-timeout-attempts)
+ [Waktu habis untuk respons asal](#RequestS3RequestTimeout)
+ [Permintaan simultan untuk objek yang sama (permintaan runtuh)](#request-s3-traffic-spikes)
### 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`
**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).
### Permintaan GET bersyarat
Ketika CloudFront menerima permintaan untuk objek yang telah kedaluwarsa dari cache tepi, ia meneruskan permintaan ke asal Amazon S3 untuk mendapatkan versi terbaru dari objek atau untuk mendapatkan konfirmasi dari Amazon S3 bahwa CloudFront cache edge sudah memiliki versi terbaru. Ketika Amazon S3 awalnya mengirim objek ke CloudFront, itu termasuk `ETag` nilai dan `LastModified` nilai dalam respons. Dalam permintaan baru yang CloudFront diteruskan ke Amazon S3 CloudFront , tambahkan satu atau kedua header 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.
Amazon S3 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).
### Cookie
Amazon S3 tidak memproses cookie. Jika Anda mengonfigurasi perilaku cache untuk meneruskan cookie ke asal Amazon S3, CloudFront teruskan cookie, tetapi Amazon S3 mengabaikannya. Semua permintaan di masa mendatang untuk objek yang sama, terlepas jika Anda mengubah cookie, dilayani dari objek yang ada di dalam cache.
### Berbagi sumber daya lintas asal (CORS)
Jika Anda CloudFront ingin menghormati setelan berbagi sumber daya lintas asal Amazon S3, konfigurasikan CloudFront untuk meneruskan header yang dipilih ke Amazon S3. Untuk informasi selengkapnya, lihat [Konten cache berdasarkan header permintaan](header-caching.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 Amazon S3 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.
Jika Anda ingin menggunakan unggahan multi-bagian untuk menambahkan objek ke bucket Amazon S3, Anda harus menambahkan CloudFront kontrol akses asal (OAC) ke distribusi Anda dan memberikan OAC izin yang diperlukan. Untuk informasi selengkapnya, lihat [Batasi akses ke asal Amazon S3](private-content-restricting-access-to-s3.md).
**penting**
Jika Anda mengonfigurasi CloudFront untuk menerima dan meneruskan ke Amazon S3 semua metode HTTP yang CloudFront mendukung, Anda harus membuat CloudFront OAC untuk membatasi akses ke konten Amazon S3 Anda dan memberikan OAC izin yang diperlukan. Misalnya, jika Anda mengonfigurasi CloudFront untuk menerima dan meneruskan metode ini karena Anda ingin menggunakan `PUT` metode ini, Anda harus mengonfigurasi kebijakan bucket Amazon S3 untuk menangani `DELETE` permintaan dengan tepat sehingga pemirsa tidak dapat menghapus sumber daya yang tidak Anda inginkan. Untuk informasi selengkapnya, lihat [Batasi akses ke asal Amazon S3](private-content-restricting-access-to-s3.md).
Untuk informasi tentang operasi yang didukung oleh Amazon S3, lihat [ Dokumentasi Amazon S3](https://docs.aws.amazon.com/s3/index.html).
### Header permintaan HTTP yang CloudFront menghapus atau memperbarui
CloudFront menghapus atau memperbarui beberapa header sebelum meneruskan permintaan ke asal Amazon S3 Anda. Untuk sebagian besar header, perilaku ini sama dengan untuk asal kustom. Untuk daftar lengkap header permintaan HTTP dan cara CloudFront memprosesnya, lihat[Header dan CloudFront perilaku permintaan HTTP (asal kustom dan Amazon S3)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior).
### 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, 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 kinerja stapling OCSP lebih terasa ketika CloudFront menerima banyak permintaan HTTPS untuk objek dalam domain yang sama. Setiap server di CloudFront lokasi edge harus menyerahkan permintaan validasi terpisah. Ketika CloudFront menerima banyak permintaan HTTPS untuk domain yang sama, setiap server di lokasi edge segera memiliki respons dari CA yang dapat dijadikan staple ke paket dalam jabat tangan SSL. Ketika pemirsa puas bahwa sertifikat valid, CloudFront dapat melayani objek yang diminta. Jika distribusi Anda tidak terlalu banyak CloudFront lokasi tepian, 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.
### Protokol
CloudFront meneruskan permintaan HTTP atau HTTPS ke server asal berdasarkan protokol permintaan penampil, baik HTTP atau HTTPS.
**penting**
Jika bucket Amazon S3 Anda dikonfigurasi sebagai titik akhir situs web, Anda tidak dapat mengonfigurasi CloudFront untuk menggunakan HTTPS untuk berkomunikasi dengan asal Anda karena Amazon S3 tidak mendukung koneksi HTTPS dalam konfigurasi tersebut.
### String pertanyaan
Anda dapat mengonfigurasi apakah CloudFront meneruskan parameter string kueri ke asal Amazon S3 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 dalam waktu 30 detik atau berhenti merespons selama 30 detik, CloudFront akan membuat koneksi terputus. 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 dalam 30 detik CloudFront , lepaskan koneksi dan tidak mencoba lagi untuk menghubungi asal. Klien dapat mengirim ulang permintaan jika perlu.
Anda tidak dapat mengubah waktu respons untuk asal Amazon S3 (wadah S3 yang *tidak* dikonfigurasi dengan hosting situs web statis).
### 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.
## Bagaimana CloudFront memproses tanggapan dari asal Amazon S3 Anda
Pelajari cara CloudFront memproses respons dari asal Amazon S3 Anda.
**Contents**
+ [Permintaan dibatalkan](#response-s3-canceled-requests)
+ [Header respons HTTP yang CloudFront menghapus atau memperbarui](#response-s3-removed-headers)
+ [Ukuran file cache maksimum](#ResponseS3MaxFileSize)
+ [Mengalihkan](#ResponseS3Redirects)
### 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.
### Header respons HTTP yang CloudFront menghapus atau memperbarui
CloudFront menghapus atau memperbarui bidang header berikut sebelum meneruskan respons dari asal Amazon S3 Anda ke penampil:
+ `X-Amz-Id-2`
+ `X-Amz-Request-Id`
+ `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 Amazon S3 Anda mengembalikan bidang header ini, CloudFront tetapkan nilainya `chunked` sebelum mengembalikan respons ke penampil.
+ `Upgrade`
+ `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).
### Mengalihkan
Anda dapat mengonfigurasi bucket Amazon S3 untuk mengalihkan semua permintaan ke nama host lain; ini dapat berupa bucket Amazon S3 lain atau server HTTP. Jika Anda mengonfigurasi bucket untuk mengalihkan semua permintaan dan jika bucket adalah asal untuk CloudFront distribusi, sebaiknya Anda mengonfigurasi bucket untuk mengalihkan semua permintaan ke distribusi menggunakan nama domain untuk CloudFront distribusi (misalnya, d111111abcdef8.cloudfront.net) atau nama domain alternatif (CNAME) yang dikaitkan dengan distribusi (misalnya, example.com). Jika tidak, pemirsa meminta bypass CloudFront, dan objek disajikan langsung dari asal baru.
**catatan**
Jika Anda mengarahkan permintaan ke nama domain alternatif, Anda juga harus memperbarui layanan DNS untuk domain Anda dengan menambahkan catatan CNAME. Untuk informasi selengkapnya, lihat [Gunakan kustom URLs dengan menambahkan nama domain alternatif (CNAMEs)](CNAMEs.md).
Inilah yang terjadi saat Anda mengonfigurasi keranjang untuk mengalihkan semua permintaan:
1. Penampil (misalnya, browser) meminta objek dari CloudFront.
1. CloudFront meneruskan permintaan ke bucket Amazon S3 yang merupakan asal distribusi Anda.
1. Amazon S3 mengembalikan kode status HTTP 301 (Moved Permanently) serta lokasi baru.
1. CloudFront cache kode status pengalihan dan lokasi baru, dan mengembalikan nilai ke penampil. CloudFront tidak mengikuti pengalihan untuk mendapatkan objek dari lokasi baru.
1. Penampil mengirimkan permintaan lain untuk objek tersebut, tetapi kali ini penampil menentukan lokasi baru yang CloudFront didapatnya:
+ Jika bucket Amazon S3 mengalihkan semua permintaan ke CloudFront distribusi, menggunakan nama domain untuk distribusi atau nama domain alternatif, CloudFront meminta objek dari bucket Amazon S3 atau server HTTP di lokasi baru. Saat lokasi baru mengembalikan objek, CloudFront mengembalikannya ke penampil dan menyimpannya di lokasi tepi.
+ Jika bucket Amazon S3 mengalihkan permintaan ke lokasi lain, permintaan kedua akan melewati. CloudFront Bucket Amazon S3 atau server HTTP di lokasi baru mengembalikan objek langsung ke penampil, sehingga objek tidak pernah di-cache di cache tepi. CloudFront
# 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).
# Perilaku permintaan dan respons untuk grup asal
Permintaan kepada kelompok asal bekerja sama dengan permintaan ke asal yang tidak diatur sebagai kelompok asal, kecuali saat ada failover asal. Seperti halnya asal lainnya, ketika CloudFront menerima permintaan dan konten sudah di-cache di lokasi tepi, konten disajikan kepada pemirsa dari cache. Ketika ada kesalahan cache dan asal adalah kelompok asal, permintaan penampil diteruskan ke asal utama dalam kelompok asal.
Permintaan dan perilaku respons untuk asal mula utama sama dengan untuk asal yang tidak berada dalam kelompok asal. Untuk informasi lebih lanjut, lihat [Perilaku permintaan dan respons untuk asal Amazon S3](RequestAndResponseBehaviorS3Origin.md) dan [Perilaku permintaan dan respons untuk asal kustom](RequestAndResponseBehaviorCustomOrigin.md).
Berikut ini menguraikan perilaku untuk failover asal ketika asal-usul utama mengembalikan kode status HTTP tertentu:
+ Kode status HTTP 2xx (sukses): CloudFront menyimpan file dan mengembalikannya ke penampil.
+ Kode status HTTP 3xx (pengalihan): CloudFront mengembalikan kode status ke penampil.
+ Kode status HTTP 4xx atau 5xx (kesalahan klien/server): Jika kode status yang dikembalikan telah dikonfigurasi untuk failover, CloudFront mengirimkan permintaan yang sama ke asal sekunder di grup asal.
+ Kode status HTTP 4xx atau 5xx (kesalahan klien/server): Jika kode status yang dikembalikan belum dikonfigurasi untuk failover, CloudFront mengembalikan kesalahan ke penampil.
CloudFront gagal ke asal sekunder hanya jika metode HTTP dari permintaan penampil adalah`GET`,`HEAD`, atau`OPTIONS`. CloudFront tidak gagal ketika penampil mengirim metode HTTP yang berbeda (misalnya`POST`,`PUT`, dan sebagainya).
Saat CloudFront mengirim permintaan ke asal sekunder, perilaku responsnya sama dengan CloudFront asal yang tidak ada dalam grup asal.
Untuk informasi selengkapnya tentang kelompok asal, lihat [Optimalkan ketersediaan tinggi dengan failover CloudFront asal](high_availability_origin_failover.md).
# Tambahkan header khusus ke permintaan asal
Anda dapat mengonfigurasi CloudFront untuk menambahkan header khusus ke permintaan yang dikirimkan ke asal Anda. Anda dapat menggunakan header khusus untuk mengirim dan mengumpulkan informasi dari asal Anda yang tidak Anda dapatkan dengan permintaan pemirsa biasa. Anda bahkan dapat menyesuaikan header untuk setiap asal. CloudFrontmendukung header khusus untuk asal kustom dan asal Amazon S3.
**Contents**
+ [Kasus penggunaan](#add-origin-custom-headers-use-cases)
+ [Konfigurasikan CloudFront untuk menambahkan header khusus ke permintaan asal](#add-origin-custom-headers-configure)
+ [Header khusus yang tidak CloudFront dapat ditambahkan ke permintaan asal](#add-origin-custom-headers-denylist)
+ [CloudFront Konfigurasikan untuk meneruskan `Authorization` header](#add-origin-custom-headers-forward-authorization)
## Kasus penggunaan
Anda dapat menggunakan header khusus, seperti contoh berikut:
**Mengidentifikasi permintaan dari CloudFront**
Anda dapat mengidentifikasi permintaan yang diterima asal Anda CloudFront. Ini dapat berguna jika Anda ingin tahu apakah pengguna melewati CloudFront, atau jika Anda menggunakan lebih dari satu CDN dan Anda menginginkan informasi tentang permintaan mana yang berasal dari setiap CDN.
Jika Anda menggunakan asal Amazon S3 dan Anda mengaktifkan [Pencatatan akses server Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html), log tidak menyertakan informasi header.
**Menentukan permintaan yang berasal dari distribusi tertentu**
Jika Anda mengonfigurasi lebih dari satu CloudFront distribusi untuk menggunakan asal yang sama, Anda dapat menambahkan header khusus yang berbeda di setiap distribusi. Anda lalu bisa menggunakan log dari tempat asal Anda untuk menentukan permintaan mana yang berasal distribusi CloudFront.
**Mengaktifkan pembagian sumber daya lintas-asal (CORS)**
Jika beberapa penonton tidak mendukung berbagi sumber daya lintas asal (CORS), Anda dapat mengonfigurasi CloudFront agar selalu menambahkan `Origin` header ke permintaan yang dikirimkan ke asal Anda. Lalu Anda bisa mengonfigurasi asal Anda untuk mengembalikan header `Access-Control-Allow-Origin` untuk setiap permintaan. Anda juga harus [mengonfigurasi CloudFront untuk mengikuti pengaturan CORS](header-caching.md#header-caching-web-cors).
**Mengendalikan akses ke konten**
Anda bisa menggunakan header kustom untuk mengontrol akses ke konten. Dengan mengonfigurasi asal Anda untuk menanggapi permintaan hanya ketika permintaan tersebut menyertakan header khusus yang ditambahkan CloudFront, Anda mencegah pengguna melewati CloudFront dan mengakses konten Anda langsung di asal. Untuk informasi selengkapnya, lihat [Batasi akses ke file pada asal kustom](private-content-overview.md#forward-custom-headers-restrict-access).
## Konfigurasikan CloudFront untuk menambahkan header khusus ke permintaan asal
Untuk mengonfigurasi distribusi guna menambahkan header kustom ke permintaan yang dikirim ke asal Anda, perbarui konfigurasi asal menggunakan salah satu metode berikut:
+ **CloudFront konsol** — Saat Anda membuat atau memperbarui distribusi, tentukan nama dan nilai header dalam pengaturan **Tambahkan header khusus**. Untuk informasi selengkapnya, lihat [Tambahkan header kustom](DownloadDistValuesOrigin.md#DownloadDistValuesOriginCustomHeaders).
+ **CloudFront API** - Untuk setiap asal yang ingin Anda tambahkan header khusus, tentukan nama dan nilai header di `CustomHeaders` bidang di dalamnya`Origin`. Untuk informasi selengkapnya, lihat [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)atau [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)di *Referensi Amazon CloudFront API*.
Jika nama header dan nilai yang Anda tentukan belum ada dalam permintaan penampil, CloudFront tambahkan ke permintaan asal. Jika ada header, CloudFront timpa nilai header sebelum meneruskan permintaan ke asal.
Untuk kuota yang berlaku untuk header kustom asal, lihat. [Kuota pada header](cloudfront-limits.md#limits-custom-headers)
## Header khusus yang tidak CloudFront dapat ditambahkan ke permintaan asal
Anda tidak dapat CloudFront mengonfigurasi untuk menambahkan header berikut ke permintaan yang dikirim ke asal Anda:
+ `Cache-Control`
+ `Connection`
+ `Content-Length`
+ `Cookie`
+ `Host`
+ `If-Match`
+ `If-Modified-Since`
+ `If-None-Match`
+ `If-Range`
+ `If-Unmodified-Since`
+ `Max-Forwards`
+ `Pragma`
+ `Proxy-Authenticate`
+ `Proxy-Authorization`
+ `Proxy-Connection`
+ `Range`
+ `Request-Range`
+ `TE`
+ `Trailer`
+ `Transfer-Encoding`
+ `Upgrade`
+ `Via`
+ Header yang dimulai dengan `X-Amz-`
+ Header yang dimulai dengan `X-Edge-`
+ `X-Real-Ip`
## CloudFront Konfigurasikan untuk meneruskan `Authorization` header
Saat CloudFront meneruskan permintaan penampil ke asal Anda, CloudFront hapus beberapa header penampil secara default, termasuk header. `Authorization` Untuk memastikan bahwa asal Anda selalu menerima header `Authorization` di permintaan asal, Anda memiliki opsi berikut:
+ Tambahkan header `Authorization` ke kunci cache menggunakan kebijakan cache. Semua header di kunci cache secara otomatis disertakan dalam permintaan asal. Untuk informasi selengkapnya, lihat [Mengontrol kunci cache dengan kebijakan](controlling-the-cache-key.md).
+ Gunakan kebijakan permintaan asal yang meneruskan semua header penampil ke asal. Anda tidak dapat meneruskan `Authorization` header satu per satu dalam kebijakan permintaan asal, tetapi ketika Anda meneruskan semua header penampil CloudFront menyertakan `Authorization` header dalam permintaan penampil. CloudFront menyediakan kebijakan permintaan asal terkelola untuk kasus penggunaan ini, yang disebut **Managed- AllViewer**. Lihat informasi yang lebih lengkap di [Gunakan kebijakan permintaan asal terkelola](using-managed-origin-request-policies.md).
# Bagaimana CloudFront memproses permintaan sebagian untuk suatu objek (rentang GETs)
Untuk objek besar, penampil (browser web atau klien lain) dapat membuat beberapa `GET` permintaan dan menggunakan header `Range` permintaan untuk mengunduh objek di bagian yang lebih kecil. Permintaan untuk rentang byte, terkadang disebut `Range GET` meminta, meningkatkan efisiensi unduhan sebagian, dan pemulihan dari transfer yang gagal sebagian.
Saat CloudFront menerima `Range GET` permintaan, ia memeriksa cache di lokasi tepi yang menerima permintaan. Jika cache di lokasi tepi itu sudah berisi seluruh objek atau bagian objek yang diminta, CloudFront segera layani rentang yang diminta dari cache.
Jika cache tidak berisi rentang yang diminta, CloudFront teruskan permintaan ke asal. (Untuk mengoptimalkan kinerja, CloudFront dapat meminta rentang yang lebih besar dari yang diminta klien di`Range GET`.) Apa yang terjadi selanjutnya tergantung pada apakah asal mendukung permintaan `Range GET`:
+ **Jika asal mendukung `Range GET` permintaan** — Ini mengembalikan rentang yang diminta. CloudFront melayani rentang yang diminta dan juga menyimpannya dalam cache untuk permintaan masa depan. (Amazon S3 mendukung `Range GET` permintaan, seperti halnya banyak server HTTP.)
+ **Jika asal tidak mendukung `Range GET` permintaan** - Ini mengembalikan seluruh objek. CloudFront melayani permintaan saat ini dengan mengirimkan seluruh objek sementara juga men-cache untuk permintaan future. Setelah CloudFront cache seluruh objek dalam cache tepi, ia merespons `Range GET` permintaan baru dengan menyajikan rentang yang diminta.
Dalam kedua kasus tersebut, CloudFront mulailah melayani rentang atau objek yang diminta ke pengguna akhir segera setelah byte pertama tiba dari asal.
**catatan**
Jika penampil membuat `Range GET` permintaan dan asal kembali`Transfer-Encoding: chunked`, CloudFront mengembalikan seluruh objek ke penampil, bukan rentang yang diminta.
CloudFront umumnya mengikuti spesifikasi RFC untuk `Range` header. Namun, jika `Range` header Anda tidak mematuhi persyaratan berikut, CloudFront mengembalikan kode status HTTP `200` dengan objek lengkap, bukan kode status `206` dengan rentang yang ditentukan:
+ Rentang harus terdaftar dalam urutan naik. Misalnya, `100-200,300-400` valid, `300-400,100-200` tidak valid.
+ Rentang tersebut tidak boleh tumpang tindih. Misalnya, `100-200,150-250` tidak valid.
+ Semua spesifikasi rentang harus valid. Misalnya, Anda tidak dapat menentukan nilai negatif sebagai bagian dari rentang.
Untuk informasi selengkapnya tentang header `Range` permintaan, lihat [Permintaan Rentang](https://httpwg.org/specs/rfc7233.html#range.requests) di RFC 7233, atau [Rentang di Dokumen](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range) Web MDN.
## Gunakan permintaan rentang untuk menyimpan objek besar
Ketika caching diaktifkan, CloudFront tidak mengambil atau cache objek yang lebih besar dari 50 GB. Ketika asal menunjukkan bahwa objek lebih besar dari ukuran ini (di header `Content-Length` respons), CloudFront menutup koneksi ke asal dan mengembalikan kesalahan ke penampil. (Dengan caching dinonaktifkan, CloudFront dapat mengambil objek yang lebih besar dari ukuran ini dari asal dan meneruskannya ke penampil. Namun, CloudFront tidak men-cache objek.)
Namun, dengan permintaan rentang, Anda dapat CloudFront menggunakan cache objek yang lebih besar dari ukuran [file cache maksimum](cloudfront-limits.md#limits-web-distributions).
**Example Contoh**
1. Pertimbangkan asal dengan objek 100 GB. Dengan caching diaktifkan, CloudFront tidak mengambil atau menyimpan objek sebesar ini. Namun, penampil dapat mengirim beberapa permintaan rentang untuk mengambil objek ini dalam beberapa bagian, dengan setiap bagian lebih kecil dari 50 GB.
1. Penampil dapat meminta objek dalam bagian 20 GB dengan mengirimkan permintaan dengan header `Range: bytes=0-21474836480` untuk mengambil bagian pertama, permintaan lain dengan header `Range: bytes=21474836481-42949672960` untuk mengambil bagian berikutnya, dan seterusnya.
1. Ketika pemirsa telah menerima semua bagian, itu dapat menggabungkannya untuk membangun objek 100 GB asli.
1. Dalam hal ini, CloudFront cache masing-masing bagian 20 GB dari objek dan dapat menanggapi permintaan berikutnya untuk bagian yang sama dari cache.
Untuk permintaan rentang untuk objek terkompresi, permintaan rentang byte didasarkan pada ukuran terkompresi, dan bukan ukuran asli objek. Untuk informasi selengkapnya tentang mengompresi file, lihat[Sajikan file terkompresi](ServingCompressedFiles.md).
# Bagaimana CloudFront memproses kode status HTTP 3xx dari asal Anda
Saat CloudFront meminta objek dari bucket Amazon S3 atau server asal khusus, asal Anda terkadang menampilkan kode status HTTP 3xx. Ini biasanya menunjukkan salah satu hal berikut:
+ URL objek telah berubah (misalnya, kode status 301, 302, 307, atau 308)
+ Objek tidak berubah sejak terakhir kali CloudFront memintanya (kode status 304)
CloudFront cache tanggapan 3xx sesuai dengan pengaturan dalam CloudFront distribusi Anda dan header dalam respons. CloudFront cache 307 dan 308 tanggapan hanya ketika Anda menyertakan `Cache-Control` header dalam tanggapan dari asal. Untuk informasi selengkapnya, lihat [Mengelola berapa lama konten tetap dalam cache (kedaluwarsa)](Expiration.md).
Jika asal Anda mengembalikan kode status pengalihan (misalnya, 301 atau 307), CloudFront tidak mengikuti pengalihan. CloudFront meneruskan respons 301 atau 307 kepada pemirsa, yang dapat mengikuti pengalihan dengan mengirimkan permintaan baru.
# Bagaimana CloudFront memproses kode status HTTP 4xx dan 5xx dari asal Anda
Saat CloudFront meminta objek dari bucket Amazon S3 atau server asal kustom, asal Anda terkadang menampilkan kode status HTTP 4xx atau 5xx, yang menunjukkan bahwa telah terjadi kesalahan. CloudFront perilaku tergantung pada:
+ Apakah Anda telah mengkonfigurasi halaman kesalahan kustom
+ Apakah Anda telah mengonfigurasi berapa lama Anda CloudFront ingin menyimpan respons kesalahan cache dari asal Anda (kesalahan caching minimum TTL)
+ Kode status
+ Untuk kode status 5xx, apakah objek yang diminta saat ini berada di cache CloudFront tepi
+ Untuk beberapa kode status 4xx, apakah asal mengembalikan header `Cache-Control max-age` atau `Cache-Control s-maxage`
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.
Jika asal tidak merespons, CloudFront permintaan ke waktu asal habis yang dianggap sebagai kesalahan HTTP 5xx dari asal, meskipun asal tidak merespons dengan kesalahan itu. Dalam skenario itu, CloudFront terus menyajikan konten yang di-cache. Untuk informasi selengkapnya, lihat [Tempat asal tidak tersedia](RequestAndResponseBehaviorCustomOrigin.md#ResponseCustomOriginUnavailable).
Jika Anda telah mengaktifkan logging, CloudFront tulis hasilnya ke log terlepas dari kode status HTTP.
Untuk informasi selengkapnya tentang fitur dan opsi yang terkait dengan pesan galat yang dikembalikan CloudFront, lihat berikut ini:
+ Untuk informasi tentang pengaturan untuk halaman kesalahan kustom di CloudFront konsol, lihat[Halaman kesalahan kustom dan caching kesalahan](DownloadDistValuesErrorPages.md).
+ Untuk informasi tentang kesalahan cache TTL minimum di CloudFront konsol, lihat. [Kesalahan caching minimum TTL (detik)](DownloadDistValuesErrorPages.md#DownloadDistValuesErrorCachingMinTTL)
+ Untuk daftar kode status HTTP yang CloudFront di-cache, lihat[Kode status HTTP 4xx dan 5xx yang di-cache CloudFront](#HTTPStatusCodes-cached-errors).
**Topics**
+ [Bagaimana CloudFront proses kesalahan ketika Anda telah mengkonfigurasi halaman kesalahan kustom](#HTTPStatusCodes-custom-error-pages)
+ [Cara CloudFront memproses kesalahan jika Anda belum mengonfigurasi halaman kesalahan kustom](#HTTPStatusCodes-no-custom-error-pages)
+ [Kode status HTTP 4xx dan 5xx yang di-cache CloudFront](#HTTPStatusCodes-cached-errors)
## Bagaimana CloudFront proses kesalahan ketika Anda telah mengkonfigurasi halaman kesalahan kustom
Jika Anda telah mengonfigurasi halaman kesalahan kustom, CloudFront perilaku tergantung pada apakah objek yang diminta ada di cache tepi.
### Objek yang diminta tidak ada di cache tepi
CloudFront terus mencoba untuk mendapatkan objek yang diminta dari asal Anda ketika semua hal berikut benar:
+ Penampil meminta sebuah objek.
+ Objek tidak berada dalam cache tepi.
+ Asal Anda mengembalikan kode status HTTP 4xx atau 5xx dan salah satu dari yang berikut adalah benar:
+ Asal Anda mengembalikan kode status HTTP 5xx, bukan mengembalikan kode status 304 (Not Modified) atau versi terbaru dari objek.
+ Kota asal Anda mengembalikan kode status HTTP 4xx yang tidak dibatasi oleh header kontrol cache dan termasuk dalam daftar kode status berikut: [Kode status HTTP 4xx dan 5xx yang di-cache CloudFront](#HTTPStatusCodes-cached-errors).
+ Asal Anda mengembalikan kode status HTTP 4xx dengan `Cache-Control max-age` header atau `Cache-Control s-maxage` header, dan kode status disertakan dalam daftar kode status berikut: Kontrol[Kode status HTTP 4xx yang CloudFront di-cache berdasarkan header `Cache-Control`](#HTTPStatusCodes-cached-errors-with-cache-control).
**CloudFront melakukan hal berikut:**
1. Di cache CloudFront tepi yang menerima permintaan penampil, CloudFront periksa konfigurasi distribusi Anda dan dapatkan jalur halaman kesalahan kustom yang sesuai dengan kode status yang dikembalikan asal Anda.
1. CloudFront menemukan perilaku cache pertama dalam distribusi Anda yang memiliki pola jalur yang cocok dengan jalur halaman kesalahan kustom.
1. Lokasi CloudFront tepi mengirimkan permintaan untuk halaman kesalahan kustom ke asal yang ditentukan dalam perilaku cache.
1. Kota asal mengembalikan halaman kesalahan kustom ke lokasi tepi.
1. CloudFront mengembalikan halaman kesalahan kustom ke penampil yang membuat permintaan, dan juga cache halaman kesalahan kustom untuk maksimum berikut ini:
+ Jumlah waktu yang ditentukan oleh kesalahan caching minimum TTL (10 detik secara default)
+ Jumlah waktu yang ditentukan oleh `Cache-Control max-age` header atau `Cache-Control s-maxage` header yang dikembalikan oleh asal ketika permintaan pertama menghasilkan kesalahan
1. Setelah waktu caching (ditentukan pada Langkah 5) telah berlalu, CloudFront coba lagi untuk mendapatkan objek yang diminta dengan meneruskan permintaan lain ke asal Anda. CloudFront terus mencoba lagi pada interval yang ditentukan oleh kesalahan caching minimum TTL.
**catatan**
Jika Anda juga mengonfigurasi perilaku cache untuk halaman kesalahan kustom yang sama, CloudFront gunakan perilaku cache TTL sebagai gantinya. Dalam hal ini, CloudFront akan melakukan hal berikut untuk langkah 5 dan 6:
Setelah CloudFront mengembalikan halaman kesalahan kustom ke penampil yang membuat permintaan, CloudFront memeriksa perilaku cache TTL (misalnya, Anda mengatur TTL default ke 5 detik). CloudFront kemudian cache halaman kesalahan kustom hingga maksimum itu.
Setelah 5 detik berlalu, CloudFront ambil halaman kesalahan kustom dari asal lagi. CloudFront akan terus mencoba lagi pada interval yang ditentukan oleh perilaku cache TTL.
Untuk informasi selengkapnya, lihat [pengaturan TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL) perilaku cache.
### Objek yang diminta ada di cache tepi
CloudFront terus melayani objek yang saat ini berada di cache tepi ketika semua hal berikut benar:
+ Penampil meminta sebuah objek.
+ Objek berada dalam cache tepi namun telah kedaluwarsa.
+ Asal Anda mengembalikan kode status HTTP 5xx, bukan mengembalikan kode status 304 (Not Modified) atau versi terbaru dari objek.
**CloudFront melakukan hal berikut:**
1. Jika asal Anda mengembalikan kode status 5xx, CloudFront melayani objek meskipun telah kedaluwarsa. Selama durasi kesalahan cache TTL minimum, CloudFront terus menanggapi permintaan penampil dengan menyajikan objek dari cache tepi.
Jika asal Anda mengembalikan kode status 4xx, CloudFront mengembalikan kode status, bukan objek yang diminta, ke penampil.
1. Setelah kesalahan caching minimum TTL telah berlalu, CloudFront coba lagi untuk mendapatkan objek yang diminta dengan meneruskan permintaan lain ke asal Anda. Perhatikan bahwa jika objek tidak sering diminta, CloudFront mungkin mengeluarkannya dari cache tepi saat server asal Anda masih mengembalikan respons 5xx. Untuk informasi tentang berapa lama objek berada di cache CloudFront tepi, lihat[Mengelola berapa lama konten tetap dalam cache (kedaluwarsa)](Expiration.md).
## Cara CloudFront memproses kesalahan jika Anda belum mengonfigurasi halaman kesalahan kustom
Jika Anda belum mengonfigurasi halaman kesalahan kustom, CloudFront perilaku tergantung pada apakah objek yang diminta ada di cache tepi.
**Topics**
+ [Objek yang diminta tidak ada di cache tepi](#HTTPStatusCodes-no-custom-error-pages-not-in-cache)
+ [Objek yang diminta ada di cache tepi](#HTTPStatusCodes-no-custom-error-pages-in-cache)
### Objek yang diminta tidak ada di cache tepi
CloudFront terus mencoba untuk mendapatkan objek yang diminta dari asal Anda ketika semua hal berikut benar:
+ Penampil meminta sebuah objek.
+ Objek tidak berada dalam cache tepi.
+ Asal Anda mengembalikan kode status HTTP 4xx atau 5xx dan salah satu dari yang berikut adalah benar:
+ Asal Anda mengembalikan kode status HTTP 5xx, bukan mengembalikan kode status 304 (Not Modified) atau versi terbaru dari objek.
+ Kota asal Anda mengembalikan kode status HTTP 4xx yang tidak dibatasi oleh header kontrol cache dan termasuk dalam daftar kode status berikut: [Kode status HTTP 4xx dan 5xx yang di-cache CloudFront](#HTTPStatusCodes-cached-errors)
+ Asal Anda mengembalikan kode status HTTP 4xx dengan `Cache-Control max-age` header atau `Cache-Control s-maxage` header dan kode status disertakan dalam daftar kode status berikut: Kontrol[Kode status HTTP 4xx yang CloudFront di-cache berdasarkan header `Cache-Control`](#HTTPStatusCodes-cached-errors-with-cache-control).
CloudFront melakukan hal berikut:
1. CloudFront mengembalikan kode status 4xx atau 5xx ke penampil, dan juga cache kode status di cache tepi yang menerima permintaan untuk maksimum berikut ini:
+ Jumlah waktu yang ditentukan oleh kesalahan caching minimum TTL (10 detik secara default)
+ Jumlah waktu yang ditentukan oleh `Cache-Control max-age` header atau `Cache-Control s-maxage` header yang dikembalikan oleh asal ketika permintaan pertama menghasilkan kesalahan
1. Selama durasi waktu caching (ditentukan di Langkah 1), CloudFront merespons permintaan penampil berikutnya untuk objek yang sama dengan kode status 4xx atau 5xx cache.
1. Setelah waktu caching (ditentukan pada Langkah 1) telah berlalu, CloudFront coba lagi untuk mendapatkan objek yang diminta dengan meneruskan permintaan lain ke asal Anda. CloudFront terus mencoba lagi pada interval yang ditentukan oleh kesalahan caching minimum TTL.
### Objek yang diminta ada di cache tepi
CloudFront terus melayani objek yang saat ini berada di cache tepi ketika semua hal berikut benar:
+ Penampil meminta sebuah objek.
+ Objek berada dalam cache tepi namun telah kedaluwarsa. Ini berarti objek itu *basi*.
+ Asal Anda mengembalikan kode status HTTP 5xx, bukan mengembalikan kode status 304 (Not Modified) atau versi terbaru dari objek.
CloudFront melakukan hal berikut:
1. Jika asal Anda mengembalikan kode kesalahan 5xx, CloudFront melayani objek meskipun telah kedaluwarsa. Untuk durasi kesalahan caching minimum TTL (10 detik secara default), CloudFront terus menanggapi permintaan penampil dengan menyajikan objek dari cache tepi.
Jika asal Anda mengembalikan kode status 4xx, CloudFront mengembalikan kode status, bukan objek yang diminta, ke penampil.
1. Setelah kesalahan caching minimum TTL telah berlalu, CloudFront coba lagi untuk mendapatkan objek yang diminta dengan meneruskan permintaan lain ke asal Anda. Jika objek tidak sering diminta, CloudFront mungkin mengeluarkannya dari cache tepi saat server asal Anda masih mengembalikan respons 5xx. Untuk informasi selengkapnya, lihat [Mengelola berapa lama konten tetap dalam cache (kedaluwarsa)](Expiration.md).
**Tip**
Jika Anda mengonfigurasi `stale-if-error` atau `Stale-While-Revalidate` direktif, Anda dapat menentukan berapa lama objek basi tersedia di cache tepi. Ini memungkinkan Anda untuk terus menayangkan konten untuk pemirsa Anda bahkan ketika asal Anda tidak tersedia. Untuk informasi, lihat [Sajikan konten basi (kedaluwarsa)](Expiration.md#stale-content).
CloudFront hanya akan melayani objek yang basi hingga nilai [TTL maksimum](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) yang ditentukan. Setelah durasi ini, objek tidak akan tersedia dari cache tepi.
## Kode status HTTP 4xx dan 5xx yang di-cache CloudFront
CloudFront cache kode status HTTP 4xx dan 5xx yang dikembalikan oleh asal Anda, tergantung pada kode status tertentu yang dikembalikan dan apakah asal Anda mengembalikan header tertentu dalam respons.
CloudFront cache kode status HTTP 4xx dan 5xx berikut yang dikembalikan oleh asal Anda. Jika Anda mengonfigurasi halaman kesalahan kustom untuk kode status HTTP, CloudFront cache halaman kesalahan kustom.
**catatan**
Jika Anda menggunakan kebijakan cache [CachingDisabled](using-managed-cache-policies.md#managed-cache-policy-caching-disabled) terkelola, CloudFront tidak akan menyimpan kode status atau halaman kesalahan khusus ini.
| | |
| --- |--- |
| 404 | Tidak Ditemukan |
| 414 | Permintaan-URI Terlalu Besar |
| 500 | Kesalahan Server Internal |
| 501 | Tidak Diterapkan |
| 502 | Gateway Buruk |
| 503 | Layanan Tidak Tersedia |
| 504 | Waktu Habis Gateway |
### Kode status HTTP 4xx yang CloudFront di-cache berdasarkan header `Cache-Control`
CloudFront hanya menyimpan kode status HTTP 4xx berikut yang dikembalikan oleh asal Anda jika asal Anda mengembalikan header `Cache-Control max-age` atau`Cache-Control s-maxage`. Jika Anda telah mengonfigurasi halaman kesalahan kustom untuk salah satu kode status HTTP ini - dan asal Anda mengembalikan salah satu header kontrol cache - CloudFront cache halaman kesalahan kustom.
| | |
| --- |--- |
| 400 | Permintaan Buruk |
| 403 | Dilarang |
| 405 | Metode Tidak Diizinkan |
| 412¹ | Prakondisi Gagal |
| 415¹ | Jenis Media Tidak Didukung |
¹ CloudFront tidak mendukung pembuatan halaman kesalahan khusus untuk kode status HTTP ini.
# Hasilkan respons kesalahan khusus
Jika objek yang Anda layani tidak CloudFront tersedia karena alasan tertentu, server web Anda biasanya mengembalikan kode status HTTP yang relevan CloudFront untuk menunjukkan ini. Misalnya, jika penampil meminta URL yang tidak valid, server web Anda mengembalikan kode status HTTP 404 (Tidak Ditemukan) ke CloudFront, dan kemudian CloudFront mengembalikan kode status tersebut ke penampil. Alih-alih menggunakan respons kesalahan default ini, Anda dapat membuat respons khusus yang CloudFront kembali ke penampil.
Jika Anda mengonfigurasi CloudFront untuk mengembalikan halaman kesalahan kustom untuk kode status HTTP tetapi halaman kesalahan kustom tidak tersedia, CloudFront mengembalikan ke penampil kode status yang CloudFront diterima dari asal yang berisi halaman kesalahan kustom. Misalnya, asal kustom Anda mengembalikan kode status 500 dan Anda telah mengonfigurasi CloudFront untuk mendapatkan halaman kesalahan kustom untuk kode status 500 dari bucket Amazon S3. Namun, seseorang secara tidak sengaja menghapus halaman kesalahan khusus dari bucket Amazon S3 Anda. CloudFront mengembalikan kode status HTTP 404 (Tidak Ditemukan) ke penampil yang meminta objek.
Saat CloudFront mengembalikan halaman kesalahan kustom ke penampil, Anda membayar CloudFront biaya standar untuk halaman kesalahan kustom, bukan biaya untuk objek yang diminta. Untuk informasi selengkapnya tentang CloudFront tagihan, lihat [ CloudFrontHarga Amazon](https://aws.amazon.com/cloudfront/pricing/).
**Topics**
+ [Konfigurasikan perilaku respons kesalahan](custom-error-pages-procedure.md)
+ [Buat halaman kesalahan khusus untuk kode status HTTP tertentu](creating-custom-error-pages.md)
+ [Menyimpan objek dan halaman kesalahan kustom di lokasi yang berbeda](custom-error-pages-different-locations.md)
+ [Ubah kode respons yang dikembalikan oleh CloudFront](custom-error-pages-response-code.md)
+ [Kontrol berapa lama CloudFront kesalahan cache](custom-error-pages-expiration.md)
# Konfigurasikan perilaku respons kesalahan
Anda memiliki beberapa opsi untuk mengelola bagaimana CloudFront merespons ketika ada kesalahan. Untuk mengonfigurasi respons kesalahan kustom, Anda dapat menggunakan CloudFront konsol, CloudFront API, atau CloudFormation. Terlepas dari bagaimana Anda memilih untuk memperbarui konfigurasi, pertimbangkan tip dan rekomendasi berikut ini:
+ Simpan halaman kesalahan kustom Anda di lokasi yang dapat diakses CloudFront. Kami menyarankan agar Anda menyimpannya di bucket Amazon S3, dan bahwa Anda[jangan menyimpannya di tempat yang sama dengan situs web atau konten aplikasi lainnya](custom-error-pages-different-locations.md). Jika Anda menyimpan halaman kesalahan kustom pada asal yang sama dengan situs web atau aplikasi Anda, dan asal mulai mengembalikan kesalahan 5xx, tidak CloudFront bisa mendapatkan halaman kesalahan kustom karena server asal tidak tersedia. Untuk informasi selengkapnya, lihat [Menyimpan objek dan halaman kesalahan kustom di lokasi yang berbeda](custom-error-pages-different-locations.md).
+ Pastikan bahwa CloudFront memiliki izin untuk mendapatkan halaman kesalahan kustom Anda. Jika halaman kesalahan kustom disimpan di Amazon S3, halaman harus dapat diakses publik atau Anda harus mengonfigurasi [kontrol akses CloudFront asal (](private-content-restricting-access-to-s3.md)OAC). Jika halaman kesalahan kustom disimpan dalam asal kustom, halaman harus dapat diakses publik.
+ (Opsional) Konfigurasi asal Anda untuk menambahkan `Cache-Control` atau `Expires` bersama dengan halaman kesalahan kustom, jika Anda ingin. Anda juga dapat menggunakan pengaturan **Error Caching Minimum TTL** untuk mengontrol berapa lama CloudFront cache halaman kesalahan kustom. Untuk informasi selengkapnya, lihat [Kontrol berapa lama CloudFront kesalahan cache](custom-error-pages-expiration.md).
## Konfigurasikan respons kesalahan khusus
Untuk mengonfigurasi respons kesalahan khusus di CloudFront konsol, Anda harus memiliki CloudFront distribusi. Di konsol, pengaturan konfigurasi untuk respons kesalahan kustom hanya tersedia untuk distribusi yang ada. Untuk mempelajari cara membuat distribusi, lihat [Memulai dengan distribusi CloudFront standar](GettingStarted.SimpleDistribution.md).
------
#### [ Console ]
**Untuk mengonfigurasi respons kesalahan kustom (konsol)**
1. Masuk ke Konsol Manajemen AWS dan buka halaman **Distribusi** di CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home#distributions](https://console.aws.amazon.com/cloudfront/v4/home#distributions).
1. Pada daftar distribusi, pilih distribusi yang akan diperbarui.
1. Pilih tab **Halaman Kesalahan**, lalu pilih **Membuat Respons Kesalahan Kustom**.
1. Masukkan nilai yang berlaku. Untuk informasi selengkapnya, lihat [Halaman kesalahan kustom dan caching kesalahan](DownloadDistValuesErrorPages.md).
1. Setelah memasukkan nilai yang diinginkan, pilih **Buat**.
------
#### [ CloudFront API or CloudFormation ]
Untuk mengonfigurasi respons kesalahan kustom dengan CloudFront API atau CloudFormation, gunakan `CustomErrorResponse` tipe dalam distribusi. Untuk informasi selengkapnya, lihat berikut ini:
+ [AWS::CloudFront::Distribution CustomErrorResponse](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-customerrorresponse.html) di *Panduan Pengguna AWS CloudFormation *
+ [CustomErrorResponse](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CustomErrorResponse.html)di *Referensi CloudFront API Amazon*
------
# Buat halaman kesalahan khusus untuk kode status HTTP tertentu
Jika Anda lebih suka menampilkan pesan kesalahan kustom daripada pesan default—misalnya, halaman yang menggunakan format yang sama dengan situs web lainnya—Anda dapat CloudFront mengembalikan objek ke penampil (seperti file HTML) yang berisi pesan kesalahan kustom Anda.
Untuk menentukan file yang ingin Anda kembalikan dan kesalahan yang harus dikembalikan file, Anda memperbarui CloudFront distribusi Anda untuk menentukan nilai-nilai tersebut. Untuk informasi selengkapnya, lihat [Konfigurasikan perilaku respons kesalahan](custom-error-pages-procedure.md).
Misalnya, berikut ini adalah pesan kesalahan kustom:
![\[Screenshot dari contoh halaman AWS 404 kustom.\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/images/custom-error-page-aws-404-example.png)
Anda dapat menentukan objek yang berbeda untuk setiap kode status HTTP yang didukung, atau Anda dapat menggunakan objek yang sama untuk semua kode status yang didukung. Anda dapat memilih untuk menentukan halaman kesalahan kustom untuk beberapa kode status dan tidak untuk yang lainnya.
Objek yang Anda layani CloudFront bisa tidak tersedia karena berbagai alasan. Hal ini dibagi ke dalam dua kategori luas:
+ *Kesalahan klien* menunjukkan masalah dengan permintaan. Misalnya, objek dengan nama yang ditentukan tidak tersedia, atau pengguna tidak memiliki izin yang diperlukan untuk mendapatkan objek di bucket Amazon S3. Ketika kesalahan klien terjadi, asal mengembalikan kode status HTTP dalam rentang 4xx ke CloudFront.
+ *Kesalahan server* menunjukkan masalah dengan server asal. Misalnya, server HTTP sibuk atau tidak tersedia. Ketika kesalahan server terjadi, server asal Anda mengembalikan kode status HTTP dalam rentang 5xx ke CloudFront, atau CloudFront tidak mendapatkan respons dari server asal Anda untuk jangka waktu tertentu dan mengasumsikan kode status 504 (Gateway Timeout).
Kode status HTTP yang CloudFront dapat mengembalikan halaman kesalahan kustom meliputi yang berikut:
+ 400, 403, 404, 405, 414, 416
+ 500, 501, 502, 503, 504
**Catatan**
Jika CloudFront mendeteksi bahwa permintaan mungkin tidak aman, CloudFront mengembalikan kesalahan 400 (Permintaan Buruk) alih-alih halaman kesalahan khusus.
Anda dapat membuat halaman kesalahan kustom untuk kode status HTTP 416 (Rentang yang Diminta Tidak Memuaskan), dan Anda dapat mengubah kode status HTTP yang CloudFront kembali ke pemirsa saat asal Anda mengembalikan kode status 416 ke. CloudFront Untuk informasi selengkapnya, lihat [Ubah kode respons yang dikembalikan oleh CloudFront](custom-error-pages-response-code.md). Namun, CloudFront tidak menyimpan kode status 416 respons, jadi meskipun Anda menentukan nilai untuk **Error Caching Minimum TTL** untuk kode status 416, CloudFront tidak menggunakannya.
Dalam beberapa kasus, CloudFront tidak mengembalikan halaman kesalahan khusus untuk kode status HTTP 503 bahkan jika Anda mengonfigurasi CloudFront untuk melakukannya. Jika kode CloudFront kesalahan `Capacity Exceeded` atau`Limit Exceeded`, CloudFront mengembalikan kode status 503 ke penampil tanpa menggunakan halaman kesalahan kustom Anda.
Jika Anda membuat halaman kesalahan kustom, CloudFront akan kembali `Connection: close` atau `Connection: keep-alive` untuk kode respons berikut:
CloudFront pengembalian `Connection: close` untuk kode status: 400, 405, 414, 416, 500, 501
CloudFront pengembalian `Connection: keep-alive` untuk kode status: 403, 404, 502, 503, 504
Untuk penjelasan rinci tentang cara CloudFront menangani respons kesalahan dari asal Anda, lihat[Bagaimana CloudFront memproses kode status HTTP 4xx dan 5xx dari asal Anda](HTTPStatusCodes.md).
# Menyimpan objek dan halaman kesalahan kustom di lokasi yang berbeda
Jika Anda ingin menyimpan objek Anda dan halaman kesalahan kustom Anda di lokasi yang berbeda, distribusi Anda harus menyertakan perilaku cache yang menyatakan hal berikut benar:
+ Nilai dari **Pola Jalan** sesuai dengan jalur ke pesan kesalahan khusus Anda. Misalnya, Anda menyimpan halaman kesalahan kustom untuk 4xx kesalahan dalam bucket Amazon S3 di direktori bernama `/4xx-errors`. Distribusi Anda harus menyertakan perilaku cache yang pola jalurnya merutekan permintaan untuk halaman kesalahan kustom Anda ke lokasi tersebut, misalnya, `/4xx-errors/*`.
+ Nilai dari **Asal** menentukan nilai dari **ID Asal** untuk asal yang berisi halaman kesalahan kustom Anda.
Untuk informasi selengkapnya, lihat [Pengaturan perilaku cache](DownloadDistValuesCacheBehavior.md).
# Ubah kode respons yang dikembalikan oleh CloudFront
Anda dapat mengonfigurasi CloudFront untuk mengembalikan kode status HTTP yang berbeda ke penampil daripada yang CloudFront diterima dari asal. Misalnya, jika asal Anda mengembalikan kode status 500CloudFront, Anda mungkin CloudFront ingin mengembalikan halaman kesalahan kustom dan kode status 200 (OK) ke penampil. Ada berbagai alasan mengapa Anda mungkin ingin CloudFront mengembalikan kode status ke penampil yang berbeda dari yang asal Anda kembalikanCloudFront:
+ Beberapa perangkat internet (beberapa firewall dan proksi korporat, misalnya) menangkap kode status HTTP 4xx dan 5xx dan mencegah respons kembali ke penampil. Dalam skenario ini, jika Anda mengganti `200`, respon tidak dicegat.
+ Jika Anda tidak peduli tentang membedakan antara kesalahan klien atau kesalahan server yang berbeda, Anda dapat menentukan `400` atau `500` sebagai nilai yang CloudFront mengembalikan semua kode status 4xx atau 5xx.
+ Anda mungkin ingin mengembalikan kode status `200` (OK) dan situs web statis sehingga pelanggan Anda tidak tahu bahwa situbgs web Anda sedang tidak aktif.
Jika Anda mengaktifkan [log CloudFront standar](AccessLogs.md) dan Anda mengonfigurasi CloudFront untuk mengubah kode status HTTP dalam respons, nilai `sc-status` kolom di log berisi kode status yang Anda tentukan. Namun, nilai kolom `x-edge-result-type` tidak terpengaruh. Ini berisi jenis hasil respons dari asal. Misalnya, Anda mengonfigurasi CloudFront untuk mengembalikan kode status `200` ke penampil saat asal kembali `404` (Tidak Ditemukan) ke CloudFront. Ketika asal merespon permintaan dengan kode status `404`, nilai dalam kolom `sc-status` di log menjadi `200`, tetapi nilai dalam kolom `x-edge-result-type` menjadi `Error`.
Anda dapat mengonfigurasi CloudFront untuk mengembalikan salah satu kode status HTTP berikut bersama dengan halaman kesalahan kustom:
+ 200
+ 400, 403, 404, 405, 414, 416
+ 500, 501, 502, 503, 504
# Kontrol berapa lama CloudFront kesalahan cache
CloudFront cache respons kesalahan untuk durasi default 10 detik. CloudFront kemudian mengirimkan permintaan berikutnya untuk objek ke asal Anda untuk melihat apakah masalah yang menyebabkan kesalahan telah diselesaikan dan objek yang diminta tersedia.
Anda dapat menentukan durasi error caching — **Error Caching Minimum TTL — untuk setiap kode status** 4xx dan 5xx yang di-cache. CloudFront (Untuk informasi selengkapnya, lihat [Kode status HTTP 4xx dan 5xx yang di-cache CloudFront](HTTPStatusCodes.md#HTTPStatusCodes-cached-errors).) Saat Anda menentukan durasi, perhatikan hal berikut:
+ Jika Anda menentukan durasi caching kesalahan singkat, CloudFront teruskan lebih banyak permintaan ke asal Anda daripada jika Anda menentukan durasi yang lebih lama. Untuk 5xx kesalahan, ini dapat memperparah masalah yang awalnya menyebabkan asal Anda mengembalikan kesalahan.
+ Saat asal Anda mengembalikan kesalahan untuk suatu objek, CloudFront merespons permintaan objek baik dengan respons kesalahan atau dengan halaman kesalahan kustom Anda hingga durasi caching kesalahan berlalu. Jika Anda menentukan durasi caching kesalahan yang lama, CloudFront mungkin terus menanggapi permintaan dengan respons kesalahan atau halaman kesalahan kustom Anda untuk waktu yang lama setelah objek tersedia kembali.
**catatan**
Anda dapat membuat halaman kesalahan kustom untuk kode status HTTP 416 (Rentang yang Diminta Tidak Memuaskan), dan Anda dapat mengubah kode status HTTP yang CloudFront kembali ke pemirsa saat asal Anda mengembalikan kode status 416 ke. CloudFront (Untuk informasi selengkapnya, lihat [Ubah kode respons yang dikembalikan oleh CloudFront](custom-error-pages-response-code.md).) Namun, CloudFront tidak menyimpan kode status 416 respons, jadi meskipun Anda menentukan nilai untuk **Error Caching Minimum TTL** untuk kode status 416, CloudFront tidak menggunakannya.
Jika Anda ingin mengontrol berapa lama kesalahan CloudFront cache untuk objek individual, Anda dapat mengonfigurasi server asal Anda untuk menambahkan header yang berlaku ke respons kesalahan untuk objek tersebut.
Jika asal menambahkan `Cache-Control: max-age` atau `Cache-Control: s-maxage` direktif, atau `Expires` header, CloudFront cache respons kesalahan untuk nilai yang lebih besar di header atau **Error Caching** Minimum TTL.
**catatan**
`Cache-Control: s-maxage`Nilai `Cache-Control: max-age` dan tidak boleh lebih besar dari nilai **TTL Maksimum** yang ditetapkan untuk perilaku cache yang halaman kesalahan diambil.
Jika asal menambahkan`Cache-Control: no-store`,`Cache-Control: no-cache`, atau `Cache-Control: private` direktif untuk kode kesalahan 404, 410, 414, atau 501, CloudFront tidak men-cache respons kesalahan. **Untuk semua kode kesalahan lainnya, CloudFront abaikan `private` arahan`no-store`,`no-cache`, dan cache respons kesalahan untuk nilai Error Caching Minimum TTL.**
**Jika asal menambahkan `Cache-Control` arahan lain atau tidak menambahkan header, CloudFront cache respons kesalahan untuk nilai Error Caching Minimum TTL.**
Jika waktu kedaluwarsa untuk kode status 4xx atau 5xx untuk objek lebih lama dari yang Anda inginkan, dan objek tersedia lagi, Anda dapat membatalkan kode galat cache dengan menggunakan URL objek yang diminta. Jika asal Anda mengembalikan respons kesalahan untuk beberapa objek, Anda perlu menggugurkan setiap objek secara terpisah. Untuk informasi lebih lanjut tentang objek yang tidak valid, lihat [Membatalkan file untuk menghapus konten](Invalidation.md).
Jika Anda mengaktifkan caching untuk asal bucket S3, dan Anda mengonfigurasi kesalahan caching TTL minimum 0 detik dalam CloudFront distribusi Anda, Anda masih akan melihat kesalahan caching TTL minimum 1 detik untuk kesalahan asal S3. CloudFront melakukan ini untuk melindungi asal Anda dari serangan DDo S. Ini tidak berlaku untuk jenis asal lainnya.