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 daripada batas yang diizinkan di Apigee Edge .

Berikut kemungkinan penyebab error 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 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 permintaan HTTP ke Apigee Edge lebih besar 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:

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

  2. Beralih ke organisasi tempat Anda ingin menyelidiki masalah

  3. Buka halaman Analyze > API Monitoring > Investigate.
  4. Pilih jangka waktu tertentu saat Anda mengamati error.
  5. Anda dapat memilih filter Proxy untuk mempersempit kode kesalahan.
  6. Petakan Kode Kesalahan terhadap Waktu.

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

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

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

    Tidak terkompresi

    Skenario #1: Payload Permintaan 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 Fault Source memiliki nilai proxy , Fault Code memiliki nilai protocol.http.TooBigBody, dan Request Length lebih dari 10 MB, berarti permintaan HTTP dari klien memiliki ukuran payload permintaan yang lebih besar daripada batas yang diizinkan di Apigee.

    Terkompresi

    Skenario #2: Payload Permintaan 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, maka 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.

Trace

Untuk mendiagnosis error menggunakan alat Trace:

  1. Aktifkan sesi rekaman aktivitas dan salah satu dari
    • Tunggu hingga terjadi error 413 Request Entity Too Large atau
    • Jika Anda dapat mereproduksi masalah, lakukan panggilan API dan reproduksi error 413 Request Entity Too Large

  2. Pastikan Show all Flow Infos diaktifkan.

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

    Tidak terkompresi

    Skenario #1: Payload Permintaan dikirim dalam bentuk tidak terkompresi

    Perhatikan informasi berikut:

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

    Terkompresi

    Skenario #2: Payload Permintaan dikirim dalam bentuk terkompresi

    Perhatikan informasi berikut:

    • Content-Encoding: gzip
    • Content-Length: 14969
    • Content-Type: application/x-gzip
  5. Telusuri berbagai fase rekaman aktivitas dan temukan tempat terjadinya kegagalan.

  6. Anda biasanya akan menemukan error dalam alur setelah fase Permintaan Diterima dari Klien seperti yang ditunjukkan di bawah:

  7. Perhatikan nilai error dari rekaman aktivitas. Rekaman aktivitas contoh 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 rekaman aktivitas. Contoh rekaman aktivitas di bawah 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 Direkam) dalam rekaman aktivitas, lalu klik.

  10. Di bagian Phase Details, scroll ke bawah ke Variables Read.

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

    Tidak terkompresi

    Skenario #1: Payload permintaan dalam bentuk tidak dikompresi

    Variabel client.received.content.length: 15360204

    Terkompresi

    Skenario #2: Payload permintaan dalam format terkompresi

    Variabel client.received.content.length: 10489856

  12. Tabel berikut menjelaskan alasan error 413 ditampilkan oleh Apigee dalam dua skenario berdasarkan nilai client.received.content.length variable:
    Skenario Nilai client.received.content.length Alasan kegagalan
    Payload Permintaan dalam format tidak dikompresi ~15 MB Ukuran > batas yang diizinkan sebesar 10 MB.
    Payload Permintaan 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 utama tentang error HTTP 413.

  2. Periksa log akses NGINX:

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

  3. Cari untuk melihat 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 X-Apigee-fault-source.

    Tidak terkompresi

    Skenario #1 : Ukuran payload permintaan dalam format tidak dikompresi

    Entri contoh 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

    Entri contoh 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 setelah dekompresi oleh Apigee Edge.

Penyebab: Ukuran Payload Permintaan lebih besar dari batas yang diizinkan

Diagnosis

  1. Tentukan Kode Kesalahan, Sumber Kesalahan, dan Ukuran Payload Permintaan untuk error yang diamati menggunakan Pemantauan API, Alat Perekaman Aktivitas, 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, maka hal ini menunjukkan bahwa ukuran payload permintaan yang dikirim oleh aplikasi klien ke Apigee lebih besar daripada batas yang diizinkan di Apigee Edge.
  3. Verifikasi Ukuran Payload Permintaan sebagaimana ditentukan dari langkah #1.
  4. Anda juga dapat memvalidasi apakah ukuran payload permintaan memang > batas yang diizinkan 10 MB dengan memeriksa permintaan sebenarnya menggunakan langkah-langkah berikut:
    1. Jika Anda tidak memiliki akses ke permintaan sebenarnya yang dibuat oleh aplikasi klien, buka Penyelesaian.
    2. Jika Anda memiliki akses ke permintaan sebenarnya yang dibuat oleh aplikasi klien, lakukan langkah-langkah berikut:
      1. Verifikasi ukuran payload yang diteruskan dalam permintaan.
      2. Jika Anda menemukan bahwa ukuran payload lebih besar dari 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 sekitar 15 MB. Jika Anda menggunakan klien lain, dapatkan log klien untuk mengetahui ukuran payload 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 ditetapkan ke gzip, , Apigee akan mendekompresi payload permintaan. Selama proses dekompresi, jika Apigee menemukan ukuran payload lebih besar dari 10 MB, batas yang diizinkan, maka 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 Kode Kesalahan, Sumber Kesalahan, dan Ukuran payload permintaan untuk error yang diamati menggunakan Pemantauan API, Alat Pelacakan, atau log Akses NGINX seperti yang dijelaskan dalam Langkah-langkah diagnosis umum dengan Skenario #2 (dikompresi).
  2. Jika Fault Source memiliki nilai policy atau proxy, maka hal ini menunjukkan bahwa ukuran payload permintaan yang dikirim oleh aplikasi klien ke Apigee lebih besar daripada batas yang diizinkan di Apigee Edge.
  3. Verifikasi Ukuran Payload Permintaan sebagaimana ditentukan dari langkah 1.
    • Jika ukuran payload > batas yang diizinkan 10 MB, maka itulah penyebab error.
    • Jika ukuran payload < batas yang diizinkan 10 MB, kemungkinan payload permintaan diteruskan dalam format terkompresi. Dalam hal ini, periksa ukuran payload permintaan terkompresi sebelum 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:

    Trace

    Untuk memvalidasi menggunakan alat Trace:

    1. Jika Anda telah merekam aktivitas untuk permintaan yang gagal, lihat langkah-langkah yang dijelaskan dalam Trace dan
      1. Menentukan 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 sebenarnya:

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

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

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

    Log Message Processor

    Untuk memvalidasi menggunakan log Message Processor:

    1. Jika Anda adalah pengguna Private Cloud, Anda dapat menggunakan log Message Processor untuk menentukan informasi utama tentang error HTTP 413.

    2. Periksa log Message Processor:

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

    3. Cari untuk melihat apakah ada error 413 selama durasi tertentu (jika masalah terjadi di masa lalu) atau apakah ada permintaan yang masih gagal dengan 413.

      Anda dapat menggunakan string penelusuran berikut:

      grep -ri "chunkCount"

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

      Hal ini menunjukkan bahwa Ukuran Payload Permintaan lebih dari 10 MB dan Apigee akan menampilkan error RequestTooLarge saat ukuran mulai melebihi batas 10 MB dengan kode error sebagai protocol.http.TooBigBody

Resolusi

Memperbaiki ukuran

Opsi #1 [Direkomendasikan]: Perbaiki aplikasi klien agar tidak mengirim ukuran payload yang lebih besar dari batas yang diizinkan

  1. Analisis alasan klien tertentu mengirim ukuran permintaan / payload lebih dari batas yang diizinkan seperti yang ditentukan dalam Limits.

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

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

    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, buka opsi berikutnya.

Pola URL bertanda tangan

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

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

Streaming

Opsi #3 : Menggunakan streaming

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

CwC

Opsi #4 : Menggunakan properti CwC untuk meningkatkan batas buffer

Opsi ini hanya boleh digunakan jika Anda tidak dapat menggunakan opsi yang direkomendasikan karena mungkin 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 mengharapkan aplikasi klien dan server backend tidak mengirimkan ukuran payload yang lebih besar dari batas yang diizinkan seperti yang didokumentasikan untuk Request/response size di Batas Apigee Edge.

  1. Jika Anda adalah pengguna Public Cloud, batas maksimum untuk ukuran payload permintaan dan respons adalah seperti yang didokumentasikan untuk Request/response size di Batas Apigee Edge.
  2. Jika Anda adalah pengguna Private Cloud, Anda mungkin telah mengubah batas default untuk 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.

  1. Di komputer Message Processor, cari properti HTTPRequest.body.buffer.limit di direktori /opt/apigee/edge-message- processor/conf dan periksa nilai 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. Dalam contoh output di atas, perhatikan bahwa properti HTTPRequest.body.buffer.limit telah ditetapkan dengan nilai 10m di 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 Must gather diagnostic information.

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 memunculkan kembali 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 memunculkan kembali 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 Message Processor /opt/apigee/var/log/edge-message-processor/logs/system.log