Anda sedang melihat dokumentasi Apigee Edge.
Buka
Dokumentasi Apigee X. info
Gejala
Aplikasi klien mendapatkan kode status HTTP 413 Request Entity Too Large
dengan kode error protocol.http.TooBigBody
sebagai respons untuk panggilan API.
Pesan Error
Aplikasi klien mendapatkan kode respons berikut:
HTTP/1.1 413 Request Entity Too Large
Selain itu, Anda mungkin melihat pesan error berikut:
{ "fault":{ "faultstring":"Body buffer overflow", "detail":{ "errorcode":"protocol.http.TooBigBody" } } }
Kemungkinan penyebab
Error ini terjadi jika ukuran payload yang dikirim aplikasi klien ke Apigee Edge sebagai bagian dari Permintaan HTTP lebih besar dari batas yang diizinkan di Apigee Edge .
Berikut adalah kemungkinan penyebab error ini :
Penyebab | Deskripsi | Petunjuk pemecahan masalah berlaku untuk |
---|---|---|
Ukuran payload permintaan melebihi batas yang diizinkan | Ukuran payload yang dikirim aplikasi klien sebagai bagian dari permintaan HTTP ke Apigee Edge adalah melebihi batas yang diizinkan di Apigee Edge. | Pengguna Edge Public dan Private Cloud |
Ukuran payload permintaan melebihi batas yang diizinkan setelah dekompresi | Ukuran payload yang dikirim dalam format terkompresi oleh aplikasi klien sebagai bagian dari HTTP ke Apigee Edge lebih dari batas yang diizinkan saat didekompresi oleh Apigee Edge. | Pengguna Edge Public dan Private Cloud |
Langkah-langkah diagnosis umum
Gunakan salah satu alat/teknik berikut untuk mendiagnosis error ini:
Pemantauan API
Untuk mendiagnosis error menggunakan Pemantauan API:
- Login ke UI Apigee Edge sebagai pengguna dengan peran yang sesuai.
Beralihlah ke organisasi tempat Anda ingin menyelidiki masalah ini
- Buka Analyze > Pemantauan API > Investigasi.
- Pilih jangka waktu tertentu saat Anda melihat error.
- Anda dapat memilih filter Proxy untuk mempersempit kode kesalahan.
- Gambarkan Kode Kesalahan terhadap Waktu.
Pilih sel yang berisi Kode Kesalahan
protocol.http.TooBigBody
dan Kode Status413
seperti yang ditunjukkan di bawah ini:Informasi tentang kode kesalahan
protocol.http.TooBigBody
ditampilkan sebagai yang ditampilkan di bawah ini:- Klik View logs, lalu luaskan baris untuk permintaan yang gagal. Kemudian dari
Logs, perhatikan detailnya seperti yang ditunjukkan di bawah ini :
Tidak terkompresi
Skenario #1: Payload Permintaan yang dikirim dalam bentuk tidak terkompresi
Dari jendela Logs, perhatikan detail berikut:
- Kode Status:
413
- Sumber Kesalahan:
proxy
- Kode Kesalahan:
protocol.http.TooBigBody
. - Panjang Permintaan(byte):
15360440
(~15 MB)
Jika Sumber Kesalahan memiliki nilai
proxy
, Kode Kesalahan memiliki nilaiprotocol.http.TooBigBody
, dan Panjang Permintaan lebih dari 10 MB, hal ini mengindikasikan bahwa permintaan HTTP dari klien memiliki ukuran payload permintaan lebih besar dari batas yang diizinkan di Apigee.Terkompresi
Skenario #2: Meminta Payload yang dikirim dalam bentuk terkompresi
Dari jendela Logs, perhatikan detail berikut:
- Kode Status:
413
- Sumber Kesalahan:
proxy
- Kode Kesalahan:
protocol.http.TooBigBody
. - Panjang Permintaan(byte):
15264
(~15 kB)
Jika Sumber Kesalahan memiliki nilai
proxy
, Kode Kesalahan memiliki nilaiprotocol.http.TooBigBody
, dan Panjang Permintaan adalah kurang dari 10 MB, hal ini menunjukkan bahwa permintaan HTTP dari klien memiliki ukuran payload permintaan lebih rendah dari batas yang diizinkan dalam format terkompresi, tetapi ukuran payload lebih besar dari batas yang diizinkan saat tidak dikompresi oleh Apigee. - Kode Status:
Trace
Untuk mendiagnosis error menggunakan alat Trace:
- Aktifkan sesi rekaman aktivitas dan
- Tunggu hingga error
413 Request Entity Too Large
terjadi atau - Jika Anda dapat mereproduksi masalah, lakukan panggilan API dan rekonstruksi
413 Request Entity Too Large
error
- Tunggu hingga error
Pastikan Tampilkan semua Info Alur diaktifkan.
- Pilih salah satu permintaan yang gagal dan periksa rekaman aktivitasnya.
- Buka fase Permintaan Diterima dari Klien.
Tidak terkompresi
Skenario #1: Payload Permintaan yang dikirim dalam bentuk tidak terkompresi
Perhatikan informasi berikut:
- Content-Encoding: tidak ada
- Durasi Konten:
15360204
Terkompresi
Skenario #2: Meminta Payload yang dikirim dalam bentuk terkompresi
Perhatikan informasi berikut:
- Encoding Konten:
gzip
- Durasi Konten:
14969
- Jenis Konten:
application/x-gzip
- Menavigasi melalui berbagai fase pelacakan dan menemukan tempat terjadinya kegagalan.
Anda akan menemukan error ini biasanya dalam alur setelah Permintaan Diterima dari Klien seperti yang ditunjukkan di bawah ini:
- Perhatikan nilai error dari trace. Contoh rekaman aktivitas di atas menunjukkan:
- error:
Body buffer overflow
- error.class:
com.apigee.errors.http.user.RequestTooLarge
- error:
Buka Response Sent to Client dan catat nilai error dari rekaman aktivitas. Contoh rekaman aktivitas di bawah ini menunjukkan:
- error:
413 Request Entity Too Large
- Konten Error:
{"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
- error:
- Buka Fase AX (Data Analytics Dicatat) di rekaman aktivitas, lalu klik Fase tersebut.
Di bagian Detail Fase, scroll ke bawah ke bagian Pembacaan Variabel.
- Tentukan nilai variabel client.received.content.length, yang menunjukkan:
- Ukuran sebenarnya dari payload permintaan saat dikirim dalam format yang tidak terkompresi dan
- Ukuran payload permintaan setelah dekompresi oleh Apigee, saat payload dikirim dalam format terkompresi. Ini akan selalu sama dengan nilai parameter yang diizinkan maksimum (10 MB) dalam skenario ini.
Tidak terkompresi
Skenario #1: Meminta payload dalam format yang tidak dikompresi
variabel client.received.content.length:
15360204
Terkompresi
Skenario #2: Meminta payload dalam format terkompresi
variabel client.received.content.length:
10489856
- Tabel berikut menjelaskan mengapa error
413
ditampilkan oleh Apigee dalam dua skenario berdasarkan nilai variabel client.received.content.length:Skenario Nilai client.received.content.length Alasan kegagalan Meminta Payload dalam format tidak terkompresi ~15 MB Ukuran > batas yang diizinkan sebesar 10 MB. Meminta Payload dalam format terkompresi ~10 MB Batas ukuran terlampaui setelah dekompresi
NGINX
Untuk mendiagnosis error menggunakan log akses NGINX:
- Jika Anda adalah pengguna Private Cloud, Anda dapat menggunakan log akses NGINX untuk menentukan
informasi penting tentang error
413
HTTP. Periksa log akses NGINX:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
- Telusuri apakah terdapat error
413
selama durasi tertentu (jika masalah terjadi di masa lalu) atau jika ada permintaan yang masih gagal dengan413
. - Jika Anda menemukan error
413
dengan pencocokan X-Apigee-fault-code nilaiprotocol.http.TooBigBody
, lalu tentukan nilai atribut X-Apigee-fault-source.Tidak terkompresi
Skenario #1 : Meminta ukuran payload dalam format tidak terkompresi
Contoh entri dari log akses NGINX di atas memiliki nilai berikut untuk X-Apigee-fault-code dan X-Apigee-fault-source:
Header respons Nilai X-Apigee-fault-code protocol.http.TooBigBody
X-Apigee-fault-sourc policy
Perhatikan Panjang Permintaan:
15360440
(14,6 MB > batas yang diizinkan)Terkompresi
Skenario #2 : Meminta ukuran payload dalam format terkompresi
Contoh entri di atas dari log akses NGINX memiliki nilai berikut untuk X-Apigee-fault-code dan X-Apigee-fault-source:
Header Respons Nilai X-Apigee-fault-code protocol.http.TooBigBody
X-Apigee-fault-source policy
Perhatikan Panjang Permintaan:
15264
(14,9 K < batas yang diizinkan)Dalam skenario ini, Apigee Edge menampilkan
413
meskipun Panjang Permintaan lebih rendah dari batas yang diizinkan karena permintaan mungkin telah dikirim dalam format terkompresi dan ukuran payload melebihi batas dekompresi oleh Apigee Edge.
Penyebab: Ukuran Payload Permintaan melebihi batas yang diizinkan
Diagnosis
- Tentukan Fault Code, Fault Source, dan Request Payload Size untuk error yang diamati menggunakan log akses Pemantauan API, Alat Pelacak, atau NGINX seperti yang dijelaskan dalam Langkah-langkah diagnosis umum dengan Skenario #1 (tidak dikompresi).
- Jika Sumber Kesalahan memiliki nilai
policy
atauproxy
, menunjukkan bahwa ukuran payload permintaan yang dikirim aplikasi klien ke Apigee lebih besar dari batas yang diizinkan di Apigee Edge. - Periksa Request Payload Size seperti yang ditentukan di langkah #1.
- Jika ukuran payload > Batas maksimum 10 MB, maka itulah penyebab error ini.
- Jika ukuran payload < batas 10 MB yang diizinkan, maka permintaan mungkin saja payload diteruskan dalam format terkompresi. Buka Penyebab: Ukuran payload permintaan melebihi batas yang diizinkan setelah dekompresi
- Anda juga dapat memvalidasi jika ukuran payload permintaan memang > Batas 10 MB yang diizinkan oleh
memeriksa permintaan yang sebenarnya menggunakan langkah-langkah berikut:
- Jika Anda tidak memiliki akses ke permintaan sebenarnya yang dibuat oleh aplikasi klien, buka Resolusi.
- Jika Anda memiliki akses ke permintaan sebenarnya yang dibuat oleh aplikasi klien, lakukan
langkah-langkah berikut:
- Verifikasi ukuran payload yang diteruskan dalam permintaan.
- Jika Anda menemukan bahwa ukuran muatan lebih dari batas yang diizinkan di Apigee Edge, maka itulah yang menjadi penyebab masalah.
Contoh Permintaan:
curl http://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile -v
Dalam kasus di atas, ukuran file
test15mbfile
~15 MB. Jika Anda menggunakan beberapa klien lain, minta log klien untuk mengetahui ukuran {i>payload<i} yang dikirim.
Resolusi
Buka Resolusi.
Penyebab: Ukuran Payload Permintaan melebihi batas yang diizinkan setelah dekompresi
Jika payload permintaan dikirim dalam format terkompresi dan header permintaan
Content-Encoding
disetel ke gzip,
Apigee mendekompresi permintaan
payload. Selama proses dekompresi, jika Apigee mendapati ukuran payload lebih besar
dari 10 MB,
batas yang diizinkan, aplikasi akan menghentikan dekompresi lebih lanjut, dan merespons kembali
langsung dengan 413 Request Entity Too Large
disertai kode error
protocol.http.TooBigBody
.
Diagnosis
- Tentukan Kode Kesalahan, Sumber Kesalahan, dan Ukuran Payload Permintaan untuk error yang diamati menggunakan log Pemantauan API, Alat Pelacak, atau Akses NGINX seperti yang dijelaskan dalam Langkah-langkah diagnosis umum dengan Skenario #2 (dikompresi).
- Jika Fault Source memiliki nilai
policy
atauproxy
, hal ini menunjukkan bahwa ukuran payload permintaan yang dikirim aplikasi klien ke Apigee lebih besar daripada batas yang diizinkan di Apigee Edge. - Verifikasi Request Payload Size seperti yang ditentukan di langkah 1.
- Jika ukuran payload > Batas maksimum 10 MB, maka itulah penyebab error ini.
- Jika ukuran payload < batas 10 MB yang diizinkan, maka permintaan mungkin saja payload diteruskan dalam format terkompresi. Dalam hal ini, periksa ukuran file yang tidak dikompresi payload permintaan terkompresi.
- Anda dapat memvalidasi apakah permintaan dari klien dikirim dalam format terkompresi dan
ukuran yang tidak dikompresi lebih besar dari batas yang diizinkan menggunakan salah satu
metode:
Trace
Untuk memvalidasi menggunakan alat Trace:
- Jika Anda telah merekam pelacakan permintaan yang gagal, lihat langkah-langkah yang dijelaskan di
Trace dan
- Tentukan nilai variabel client.received.content.length
- Verifikasi apakah permintaan dari klien berisi Content-Encoding:
Header
gzip
- Jika nilai variabel client.received.content.length lebih besar dari
10 MB,
batas yang diizinkan, dan header permintaan Content-Encoding:
gzip
, itulah penyebab error ini.
Permintaan sebenarnya
Untuk memvalidasi menggunakan permintaan yang sebenarnya:
- Jika Anda tidak memiliki akses ke permintaan sebenarnya yang dibuat oleh aplikasi klien, buka Resolusi.
- Jika Anda memiliki akses ke permintaan sebenarnya yang dibuat oleh aplikasi klien, lakukan
langkah-langkah berikut:
- Verifikasi ukuran payload yang diteruskan dalam permintaan beserta
Header
Content-Encoding
dikirim dalam permintaan. Periksa untuk melihat apakah ukuran payload yang tidak dikompresi lebih besar dari batas yang diizinkan di Apigee Edge
Contoh permintaan:
curl https://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile.gz -H "Content-Encoding: gzip" -v
Dalam kasus di atas, file
test15mbfile.gz
lebih kecil dari batas ukuran; namun, ukuran filetest15mbfile
yang tidak dikompresi adalah ~15 MB dan headerContent-Encoding
adalahgzip
.Jika Anda menggunakan beberapa klien lain, dapatkan log klien untuk mengetahui ukuran payload dikirim dan jika header
Content-Encoding
disetel kegzip
.
- Verifikasi ukuran payload yang diteruskan dalam permintaan beserta
Header
Log Pemroses Pesan
Untuk memvalidasi menggunakan log Pemroses Pesan:
- Jika Anda pengguna Private Cloud, Anda dapat menggunakan log Pemroses Pesan untuk menentukan
informasi penting tentang error
413
HTTP. Periksa log Pemroses Pesan:
/opt/apigee/var/log/edge-message-processor/logs/system.log
Telusuri untuk mengetahui apakah terdapat error
413
selama durasi tertentu (jika masalah terjadi sebelumnya) atau jika ada permintaan yang masih gagal dengan413
.Anda dapat menggunakan string penelusuran berikut:
grep -ri "chunkCount"
grep -ri "RequestTooLarge"
- Anda akan menemukan baris dari
system.log
yang mirip dengan berikut ini (TotalRead
danchunkCount
dapat berbeda dalam kasus Anda):2021-07-06 13:29:57,544 NIOThread@1 ERROR HTTP.SERVICE - TrackingInputChannel.checkMessageBodyTooLarge() : Message is too large. TotalRead 10489856 chunkCount 2570 2021-07-06 13:29:57,545 NIOThread@1 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace: com.apigee.errors.http.user.RequestTooLarge : Body buffer overflow
- Selama proses dekompresi, segera setelah Pemroses Pesan menentukan total
byte yang dibaca adalah > 10 MB, akan menghentikan dan mencetak baris berikut:
Message is too large. TotalRead 10489856 chunkCount 2570
Hal ini menyiratkan bahwa Request Payload Size berukuran lebih dari 10 MB dan Apigee menampilkan error
RequestTooLarge
saat ukuran mulai melebihi batas 10 MB dengan kode kesalahanprotocol.http.TooBigBody
- Jika Anda telah merekam pelacakan permintaan yang gagal, lihat langkah-langkah yang dijelaskan di
Trace dan
Resolusi
Perbaiki ukuran
Opsi #1 [Direkomendasikan]: Perbaiki aplikasi klien agar tidak mengirim ukuran payload lebih besar dari batas yang diizinkan
- Menganalisis alasan klien tertentu mengirim ukuran permintaan / payload lebih dari yang diizinkan seperti yang ditetapkan dalam Batas.
Jika tidak diinginkan, ubah aplikasi klien Anda agar mengirimkan permintaan / payload kurang dari batas yang diizinkan.
Dalam contoh yang dibahas di atas, Anda dapat memperbaiki masalah dengan meneruskan file berukuran lebih kecil, misalkan payload
test5mbfile
(dengan ukuran 5 MB) seperti yang ditunjukkan di bawah ini:curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
- Jika Anda menginginkannya dan Anda ingin mengirimkan permintaan/payload melebihi batas yang diperbolehkan, buka opsi berikutnya.
Pola URL Bertanda Tangan
Opsi #2 [Direkomendasikan]: Gunakan pola URL yang ditandatangani dalam JavaInfo Apigee
Untuk payload yang lebih besar dari 10 MB, Apigee merekomendasikan penggunaan pola URL yang ditandatangani dalam Info Java Apigee, yang diilustrasikan oleh Edge Keterangan: Contoh Generator URL Bertanda Tangan di GitHub.
Streaming
Opsi no. 3 : Gunakan streaming
Jika proxy API perlu menangani permintaan dan/atau respons yang sangat besar, Anda dapat mengaktifkan streaming di Apigee.
CwC
Opsi #4 : Gunakan properti CwC untuk meningkatkan batas buffer
Opsi ini harus digunakan hanya ketika Anda tidak dapat menggunakan opsi yang direkomendasikan karena mungkin menjadi masalah kinerja jika ukuran {i>default<i} diperbesar.
Apigee menyediakan CwC yang memungkinkannya meningkatkan batas ukuran payload permintaan dan respons. Untuk mengetahui detailnya, lihat Menetapkan batas ukuran pesan di Router atau Pemroses Pesan
Batas
Apigee mengharapkan aplikasi klien dan server backend tidak mengirim ukuran payload lebih besar dari
batas yang diizinkan seperti yang didokumentasikan untuk Request/response size
di
Batas Apigee Edge.
- Jika Anda adalah pengguna Cloud Publik, batas maksimum untuk permintaan dan respons
ukuran payload seperti yang didokumentasikan untuk
Request/response size
di Batas Apigee Edge. - Jika Anda adalah pengguna Private Cloud , Anda mungkin telah mengubah setelan default batas ukuran payload permintaan dan respons (meskipun bukan praktik yang direkomendasikan). Anda dapat menentukan batas ukuran payload permintaan maksimum dengan mengikuti petunjuk di Cara memeriksa batas saat ini.
Bagaimana cara memeriksa batas saat ini?
Bagian ini menjelaskan cara memverifikasi bahwa properti HTTPRequest.body.buffer.limit
telah diperbarui dengan nilai baru di Pemroses Pesan.
- Di mesin Pemroses Pesan, telusuri properti
HTTPRequest.body.buffer.limit
di direktori/opt/apigee/edge-message- processor/conf
dan periksa untuk melihat nilai yang telah ditetapkan menggunakan berikut:grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
- Contoh hasil dari perintah di atas adalah sebagai berikut:
/opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m
Pada contoh {i>output<i} di atas, perhatikan bahwa properti
HTTPRequest.body.buffer.limit
telah ditetapkan dengan nilai10m
dihttp.properties
.Hal ini menunjukkan bahwa batas ukuran payload permintaan yang dikonfigurasi di Apigee untuk Pribadi Cloud sebesar 10 MB.
Jika Anda masih memerlukan bantuan dari Dukungan Apigee, buka Harus mengumpulkan informasi diagnostik.
Harus mengumpulkan informasi diagnostik
Kumpulkan informasi diagnostik berikut, lalu hubungi Dukungan Apigee Edge:
Jika Anda adalah pengguna Cloud Publik, berikan informasi berikut:
- Nama organisasi
- Nama lingkungan
- Nama Proxy API
- Menyelesaikan perintah curl yang digunakan untuk mereproduksi error
413
- File rekaman aktivitas untuk permintaan API
Jika Anda adalah pengguna Private Cloud, berikan informasi berikut:
- Pesan error lengkap yang diamati untuk permintaan yang gagal
- Nama organisasi
- Nama lingkungan
- Paket Proxy API
- File pelacakan untuk permintaan API yang gagal
- Menyelesaikan perintah curl yang digunakan untuk mereproduksi error
413
Log akses NGINX
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
Di mana: ORG, ENV, dan PORT# diganti dengan nilai aktual.
- Log sistem Pemroses Pesan
/opt/apigee/var/log/edge-message-processor/logs/system.log