413 Entitas Permintaan Terlalu Besar - TooBigBody

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 oleh aplikasi klien ke Apigee Edge sebagai bagian dari permintaan HTTP lebih besar dari batas yang diizinkan di Apigee Edge .

Berikut kemungkinan penyebab kesalahan ini :

Penyebab Deskripsi Petunjuk pemecahan masalah yang berlaku untuk
Ukuran payload permintaan lebih besar dari batas yang diizinkan Ukuran payload yang dikirim oleh aplikasi klien sebagai bagian dari permintaan HTTP ke Apigee Edge melebihi batas yang diizinkan di Apigee Edge. Pengguna Edge Publik 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 permintaan HTTP ke Apigee Edge melebihi batas yang diizinkan saat didekompresi oleh Apigee Edge. Pengguna Edge Publik dan Private Cloud

Langkah-langkah diagnosis umum

Gunakan salah satu alat/teknik berikut untuk mendiagnosis error ini:

Pemantauan API

Untuk mendiagnosis error menggunakan API Monitoring:

  1. Login ke UI Apigee Edge sebagai pengguna dengan peran yang sesuai.

  2. Beralihlah ke organisasi tempat Anda ingin menyelidiki masalah

  3. Buka halaman Analyze > API Monitoring > Menyelidiki.
  4. Pilih jangka waktu spesifik saat Anda melihat error.
  5. Anda dapat memilih filter Proxy untuk mempersempit kode kesalahan.
  6. Tempatkan Kode Kesalahan terhadap Waktu.

  7. Pilih sel yang memiliki Kode Kesalahan protocol.http.TooBigBody dan Kode Status 413seperti yang ditunjukkan di bawah ini:

  8. Informasi tentang kode kesalahan protocol.http.TooBigBody ditampilkan seperti yang ditunjukkan di bawah ini:

  9. Klik Lihat log dan luaskan baris untuk permintaan yang gagal. Kemudian dari jendela Logs, perhatikan detail seperti yang ditunjukkan di bawah ini :

    Tidak terkompresi

    Skenario #1: Minta Payload yang dikirim dalam bentuk yang tidak dikompresi

    Dari jendela Log, perhatikan detail berikut:

    • Kode Status: 413
    • Sumber Kesalahan: proxy
    • Kode Kesalahan: protocol.http.TooBigBody.
    • Panjang Permintaan(byte): 15360440 (~15 MB)

    Jika Fault Source memiliki nilai proxy , Fault Code memiliki nilai protocol.http.TooBigBody, dan Request Length lebih dari 10 MB, hal ini menunjukkan bahwa permintaan HTTP dari klien memiliki ukuran payload permintaan yang lebih besar daripada batas yang diizinkan di Apigee.

    Terkompresi

    Skenario #2: Minta 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 Fault Source memiliki nilai proxy , Fault Code memiliki nilai protocol.http.TooBigBody, dan Request Length kurang dari 10 MB, hal ini menunjukkan bahwa permintaan HTTP dari klien memiliki ukuran payload permintaan yang lebih rendah dari batas yang diizinkan dalam format terkompresi, tetapi ukuran payload lebih besar dari batas yang diizinkan saat tidak dikompresi oleh Apigee.

Rekaman aktivitas

Untuk mendiagnosis error menggunakan alat Trace:

  1. Aktifkan sesi perekaman aktivitas dan
    • Tunggu hingga error 413 Request Entity Too Large terjadi atau
    • Jika Anda dapat merekonstruksi masalah, buat panggilan API dan rekonstruksi error 413 Request Entity Too Large

  2. Pastikan Tampilkan semua Info Alur diaktifkan.

  3. Pilih salah satu permintaan yang gagal dan periksa rekaman aktivitas.
  4. Buka fase Request Received from Client.

    Tidak terkompresi

    Skenario #1: Minta Payload yang dikirim dalam bentuk yang tidak dikompresi

    Perhatikan informasi berikut:

    • Content-Encoding: tidak ada
    • Content-Length: 15360204

    Terkompresi

    Skenario #2: Minta Payload yang dikirim dalam bentuk terkompresi

    Perhatikan informasi berikut:

    • Encoding Konten: gzip
    • Content-Length: 14969
    • Jenis Konten: application/x-gzip
  5. Jelajahi berbagai fase rekaman aktivitas dan temukan lokasi terjadinya kegagalan.

  6. Anda akan menemukan error biasanya dalam alur setelah fase Request Received from Client seperti yang ditunjukkan di bawah ini:

  7. Catat nilai error dari rekaman aktivitas. Contoh rekaman aktivitas di atas menunjukkan:
    • error: Body buffer overflow
    • error.class: com.apigee.errors.http.user.RequestTooLarge

  8. Buka Response Sent to Client dan catat nilai error dari trace. 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"}}}
  9. Buka Fase AX (Data Analytics Dicatat) di trace, lalu klik Fase tersebut.

  10. Di bagian Detail Fase, scroll ke bawah ke Pembacaan Variabel.

  11. Tentukan nilai variabel client.acceptd.content.length, yang menunjukkan:
    • Ukuran sebenarnya dari payload permintaan ketika dikirim dalam format yang tidak dikompresi dan
    • Ukuran payload permintaan setelah dekompresi oleh Apigee, saat payload dikirim dalam format terkompresi. Nilai ini akan selalu sama dengan nilai batas yang diizinkan (10 MB) dalam skenario ini.

    Tidak terkompresi

    Skenario #1: Meminta payload dalam bentuk yang tidak dikompresi

    Variabel client.acceptd.content.length: 15360204

    Terkompresi

    Skenario #2: Meminta payload dalam format terkompresi

    Variabel client.acceptd.content.length: 10489856

  12. Tabel berikut menjelaskan alasan error 413 ditampilkan oleh Apigee dalam dua skenario berdasarkan nilai variabel client.acceptd.content.length:
    Skenario Nilai client.acceptd.content.length Alasan kegagalan
    Minta Payload dalam format yang tidak dikompresi ~15 MB Ukuran > batas yang diizinkan sebesar 10 MB.
    Minta Payload dalam format terkompresi ~10 MB

    Batas ukuran terlampaui saat dekompresi

NGINX

Untuk mendiagnosis error menggunakan log akses NGINX:

  1. Jika Anda adalah pengguna Private Cloud, Anda dapat menggunakan log akses NGINX untuk menentukan informasi penting tentang error 413 HTTP.

  2. Periksa log akses NGINX:

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  3. Telusuri untuk mengetahui apakah ada error 413 selama durasi tertentu (jika masalah terjadi di masa lalu) atau apakah ada permintaan yang masih gagal dengan 413.
  4. Jika Anda menemukan error 413 dengan X-Apigee-fault-code yang cocok dengan nilai protocol.http.TooBigBody, tentukan nilai dari X-Apigee-fault-source.

    Tidak terkompresi

    Skenario #1 : Minta ukuran payload dalam format yang tidak dikompresi

    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-sourc policy

    Perhatikan Panjang Permintaan: 15360440 (14,6 MB > batas yang diizinkan)

    Terkompresi

    Skenario #2 : Ukuran payload permintaan 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

    Catat 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 dikirim dalam format terkompresi dan ukuran payload melebihi batas saat dekompresi oleh Apigee Edge.

Penyebab: Ukuran Payload Permintaan lebih besar dari batas yang diizinkan

Diagnosis

  1. Tentukan Fault Code, Fault Source, dan Request Payload Size untuk error yang diamati menggunakan API Monitoring, Trace Tool, atau log akses NGINX seperti yang dijelaskan dalam Langkah-langkah diagnosis umum dengan Skenario #1 (tidak dikompresi).
  2. Jika Fault Source memiliki nilai policy atau proxy, hal ini menunjukkan bahwa ukuran payload permintaan yang dikirim oleh aplikasi klien ke Apigee lebih besar dari batas yang diizinkan di Apigee Edge.
  3. Verifikasi Request Payload Size seperti yang ditentukan dari langkah #1.
  4. Anda juga dapat memvalidasi apakah ukuran payload permintaan memang > 10 MB batas yang diizinkan dengan memeriksa permintaan sebenarnya menggunakan langkah-langkah berikut:
    1. Jika Anda tidak memiliki akses ke permintaan aktual yang dibuat oleh aplikasi klien, buka Resolution.
    2. Jika Anda memiliki akses ke permintaan aktual yang dibuat oleh aplikasi klien, lakukan langkah-langkah berikut:
      1. Verifikasi ukuran payload yang diteruskan dalam permintaan.
      2. Jika Anda mendapati bahwa ukuran payload melebihi batas yang diizinkan di Apigee Edge, maka itulah penyebab masalahnya.

        3. Contoh Permintaan:

        curl http://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile -v

        Dalam kasus di atas, file test15mbfile berukuran ~15 MB. Jika Anda menggunakan beberapa klien lain, dapatkan log klien untuk mengetahui ukuran payload yang dikirim.

Resolusi

Buka Resolution.

Penyebab: Ukuran Payload Permintaan melebihi batas yang diizinkan setelah dekompresi

Jika payload permintaan dikirim dalam format terkompresi dan header permintaan Content-Encoding ditetapkan ke gzip, Apigee, payload akan mendekompresi payload permintaan. Selama proses dekompresi, jika Apigee menemukan ukuran payload lebih besar dari 10 MB, batas yang diizinkan, Apigee akan menghentikan dekompresi lebih lanjut, dan segera merespons kembali dengan 413 Request Entity Too Large dengan kode error protocol.http.TooBigBody.

Diagnosis

  1. Tentukan Fault Code, Fault Source, dan Request Payload size untuk error yang diamati menggunakan API Monitoring, Trace Tool, atau log NGINX Access seperti yang dijelaskan dalam Langkah-langkah diagnosis umum dengan Skenario #2 (dikompresi).
  2. Jika Fault Source memiliki nilai policy atau proxy, ini menunjukkan bahwa ukuran payload permintaan yang dikirim oleh aplikasi klien ke Apigee lebih besar daripada batas yang diizinkan di Apigee Edge.
  3. Verifikasi Request Payload Size seperti yang ditentukan dari langkah 1.
    • Jika ukuran payload > 10 MB batas yang diizinkan, itulah penyebab error.
    • Jika ukuran payload < 10 MB batas yang diizinkan, payload permintaan mungkin diteruskan dalam format terkompresi. Dalam hal ini, periksa ukuran payload permintaan terkompresi yang belum dikompresi.
  4. 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 berikut:

    Rekaman aktivitas

    Untuk melakukan validasi menggunakan alat Trace:

    1. Jika Anda telah merekam aktivitas untuk permintaan yang gagal, lihat langkah-langkah yang dijelaskan dalam Pelacakan dan
      1. Tentukan nilai variabel client.received.content.length
      2. Verifikasi apakah permintaan dari klien berisi header Content-Encoding: gzip
    2. Jika nilai variabel client.received.content.length lebih besar dari 10 MB, batas yang diizinkan, dan header permintaan Content-Encoding: gzip, maka itulah penyebab error ini.

    Permintaan sebenarnya

    Untuk memvalidasi menggunakan permintaan yang sebenarnya:

    1. Jika Anda tidak memiliki akses ke permintaan aktual yang dibuat oleh aplikasi klien, buka Resolution.
    2. Jika Anda memiliki akses ke permintaan aktual yang dibuat oleh aplikasi klien, lakukan langkah-langkah berikut:
      1. Verifikasi ukuran payload yang diteruskan dalam permintaan bersama dengan header Content-Encoding yang dikirim dalam permintaan.

      2. Periksa apakah ukuran payload yang tidak dikompresi lebih 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 kurang dari batas ukuran. Namun, ukuran file test15mbfile yang tidak dikompresi adalah ~15 MB dan header Content-Encoding adalah gzip.

        Jika Anda menggunakan beberapa klien lain, dapatkan log klien untuk mengetahui ukuran payload yang dikirim dan apakah header Content-Encoding ditetapkan ke gzip.

    Log Pemroses Pesan

    Untuk memvalidasi menggunakan log Pemroses Pesan:

    1. Jika Anda adalah pengguna Private Cloud, Anda dapat menggunakan log Pemroses Pesan untuk menentukan informasi penting tentang error 413 HTTP.

    2. Periksa log Message Processor:

      /opt/apigee/var/log/edge-message-processor/logs/system.log

    3. Telusuri untuk melihat apakah ada error 413 selama durasi tertentu (jika masalah terjadi sebelumnya) atau apakah ada permintaan yang masih gagal dengan 413.

      Anda dapat menggunakan string pencarian berikut:

      grep -ri "chunkCount"

      grep -ri "RequestTooLarge"
    4. Anda akan menemukan baris dari system.log yang mirip dengan yang berikut ini (TotalRead dan chunkCount dapat bervariasi 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
    5. Selama proses dekompresi, segera setelah Message Processor menentukan total byte baca adalah > 10 MB, Pemroses Pesan akan berhenti dan mencetak baris berikut: 
      Message is too large.  TotalRead 10489856 chunkCount 2570

      Ini menyiratkan bahwa Request Payload Size lebih dari 10 MB dan Apigee menampilkan error RequestTooLarge ketika ukuran mulai melebihi batas 10 MB dengan kode kesalahan sebagai protocol.http.TooBigBody

Resolusi

Ukuran tetap

Opsi #1 [Direkomendasikan]: Memperbaiki aplikasi klien agar ukuran payload tidak melebihi batas yang diizinkan

  1. Lakukan analisis alasan mengapa klien tersebut mengirim ukuran permintaan / payload melebihi batas yang diizinkan, sebagaimana ditetapkan dalam Batas.

  2. Jika tidak diinginkan, ubah aplikasi klien agar mengirimkan ukuran permintaan / payload kurang dari batas yang diizinkan.

    Pada contoh yang dibahas di atas, Anda dapat memperbaiki masalah dengan meneruskan file berukuran lebih kecil, misalnya test5mbfile (dengan ukuran 5 MB) payload seperti yang ditunjukkan di bawah ini: 

    curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v

  3. Jika diinginkan dan Anda ingin mengirim permintaan/payload lebih dari batas yang diizinkan, lanjutkan ke opsi berikutnya.

Pola URL yang Ditandatangani

Opsi #2 [Direkomendasikan]: Gunakan pola URL bertanda tangan dalam Apigee JavaCallout

Untuk payload yang lebih besar dari 10 MB, Apigee merekomendasikan penggunaan pola URL yang ditandatangani dalam Apigee JavaCallout, yang diilustrasikan dengan contoh Edge Callout: Signed URL Generator di GitHub.

Streaming

Opsi #3 : Menggunakan streaming

Jika proxy API perlu menangani permintaan dan/atau respons yang sangat besar, Anda dapat mengaktifkan streaming di Apigee.

CwC

Opsi no. 4 : Gunakan properti CwC untuk meningkatkan batas buffer

Opsi ini hanya boleh digunakan jika Anda tidak dapat menggunakan opsi yang direkomendasikan karena mungkin akan ada masalah performa jika ukuran default ditingkatkan.

Apigee menyediakan properti 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 memperkirakan aplikasi klien dan server backend tidak akan mengirim ukuran payload yang lebih besar dari batas yang diizinkan seperti yang didokumentasikan untuk Request/response size dalam Apigee Edge Limits.

  1. Jika Anda adalah pengguna Cloud Publik, batas maksimum untuk ukuran payload permintaan dan respons adalah seperti yang didokumentasikan untuk Request/response size di Apigee Edge Limits.
  2. Jika Anda adalah pengguna Private Cloud, Anda mungkin telah mengubah batas default untuk ukuran payload permintaan dan respons (meskipun ini bukan praktik yang direkomendasikan). Anda dapat menentukan batas ukuran payload permintaan maksimum dengan mengikuti petunjuk di bagian 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.

  1. Pada mesin Message Processor, telusuri properti HTTPRequest.body.buffer.limit dalam direktori /opt/apigee/edge-message- processor/conf dan periksa untuk melihat nilai apa yang telah ditetapkan menggunakan perintah berikut: 
    grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
  2. Contoh hasil dari perintah di atas adalah sebagai berikut: 
    /opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m

  3. Pada contoh output di atas, perhatikan bahwa properti HTTPRequest.body.buffer.limit telah ditetapkan dengan nilai 10m dalam http.properties.

    Hal ini menunjukkan bahwa batas ukuran payload permintaan yang dikonfigurasi di Apigee untuk Private Cloud adalah 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
  • Perintah curl lengkap 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 rekaman aktivitas untuk permintaan API yang gagal
  • Perintah curl lengkap yang digunakan untuk mereproduksi error 413

  • Log akses NGINX /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    Tempat: ORG, ENV, dan PORT# diganti dengan nilai sebenarnya.

  • Log sistem Pemroses Pesan /opt/apigee/var/log/edge-message-processor/logs/system.log